index.html
56 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Device Description Landscape 1.0</title><style type="text/css">
code { font-family: monospace; }
div.constraint, div.issue, div.note, div.notice { margin-left: 2em; }
li p { margin-top: 0.3em; margin-bottom: 0.3em; }
.boxedtext {
border: solid #bebebe 1px;
margin: 2em 1em 1em 2em;
padding: 0 0 10px 0;
}
div.principle, div.practice, div.constraint, div.property, div.story {
margin: -0.8em 0.5em 1em 1em;
}
.principlelab, .constraintlab,
.propertylab, .practicelab,
.storylab {
margin: -0.8em 0.5em 1em 1em;
font-weight: bold;
font-style: italic;
}
p.principlelab span { background: #f7ebd7 }
p.constraintlab span { background: #becece }
p.propertylab span { background: #f7ebd7 }
p.practicelab span { background: #dfffff }
p.storylab span { background: #005a9c; color: #fff; }
div.exampleInner pre { margin-left: 1em;
margin-top: 0em; margin-bottom: 0em}
div.exampleOuter {border: 4px double gray;
margin: 0em; padding: 0em}
div.exampleInner { background-color: #d5dee3;
border-top-width: 4px;
border-top-style: double;
border-top-color: #d3d3d3;
border-bottom-width: 4px;
border-bottom-style: double;
border-bottom-color: #d3d3d3;
padding: 4px; margin: 0em }
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
margin: 4px}
</style><link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE.css" /><link rel="contents" href="#contents" /></head><body><div class="head"><p><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72" /></a></p>
<h1 id="title">Device Description Landscape 1.0</h1>
<h2 id="w3c-doctype">W3C Working Group Note 31 October 2007</h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2007/NOTE-dd-landscape-20071031/">http://www.w3.org/TR/2007/NOTE-dd-landscape-20071031/</a></dd><dt>Latest version:</dt><dd><a href="http://www.w3.org/TR/dd-landscape/">http://www.w3.org/TR/dd-landscape/</a></dd><dt>Previous version:</dt><dd><a href="http://www.w3.org/TR/2006/WD-dd-landscape-20060210/">http://www.w3.org/TR/2006/WD-dd-landscape-20060210/</a></dd><dt>Editors:</dt><dd>Eman Nkeze (editor of this draft), The Boeing Company</dd><dd>James Pearce (editor of first draft), Argogroup (at the time of participation)</dd><dd>Matt Womer (editor of first draft), France Telecom (at the time of participation)</dd></dl>
<p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2007 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p>
</div><hr /><div>
<h2 id="abstract">Abstract</h2><p>Developing Web content for mobile devices is more challenging than developing for the desktop Web. Compared to desktop Web clients, mobile Web devices come in a much wider range of shapes, sizes and capabilities. The mobile Web developer relies upon accurate device descriptions in order to dynamically adapt content to suit the client.</p><p>This Note describes what efforts the W3C and other organizations are doing in order to provide accurate device descriptions. This Note should be read in conjunction with the DDWG Ecosystem <a href="#ref-DDWG-Ecosystem">[DDWG-Ecosystem]</a> document.</p><p>This Note, together with the Ecosystem document, provides input to the proposed DDWG Requirements document as described in the DDWG Charter <a href="#ref-DDWG-Charter">[DDWG-Charter]</a></p></div><div>
<h2 id="status">Status of this Document</h2>
<p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/">W3C technical reports index</a> at http://www.w3.org/TR/.</em></p>
<p>Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p>
<p>This document is a Public Working Draft of a future Working Group Note. It has been produced as part of the <a href="http://www.w3.org/2005/MWI/DDWG/">W3C Mobile Web Initiative Device Description Working Group</a>, following the procedures set out for the W3C Process. This Working Group is part of the Mobile Web Initiative. The authors of this document are members of the W3C Mobile Web Initiative, Device Description Working Group. Feedback can be directed to the <a href="mailto:public-ddwg@w3.org">DDWG Public Mailing List</a>, which is also <a href="http://lists.w3.org/Archives/Public/public-ddwg/">archived</a>.</p>
<p> This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C Patent Policy</a>. W3C maintains a <a href="http://www.w3.org/2004/01/pp-impl/37583/status">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the W3C Patent Policy</a>. </p>
</div><div class="toc">
<h2 id="contents">Table of Contents</h2><p class="toc">1 <a href="#sec-introduction">Introduction</a><br />
1.1 <a href="#sec-objectivescope">Objective & Scope</a><br />
1.2 <a href="#sec-audience">Audience</a><br />
1.3 <a href="#sec-relatedgroups">Related groups and organizations</a><br />
1.4 <a href="#sec-definitions">Definitions</a><br />
1.4.1 <a href="#sec-browser">Browser</a><br />
1.4.2 <a href="#sec-contentadaptation">Content adaptation</a><br />
1.4.3 <a href="#sec-device">Device</a><br />
1.4.4 <a href="#sec-devicedescription">Device Description</a><br />
1.4.5 <a href="#sec-mobiledevice">Mobile device</a><br />
2 <a href="#sec-motivations">Motivations</a><br />
2.1 <a href="#sec-theneedfordevicedescriptions">The need for Device Descriptions</a><br />
2.2 <a href="#sec-ddforca">Device Descriptions for content adaptation</a><br />
2.2.1 <a href="#sec-originserver">Origin-server adaptation</a><br />
2.2.2 <a href="#sec-deliveryinfrastructure">Delivery infrastructure</a><br />
2.2.3 <a href="#sec-clientside">Client-side adaptation</a><br />
2.2.4 <a href="#sec-designtime">Design-time</a><br />
2.3 <a href="#sec-usersofdd">The users and providers of Device Descriptions</a><br />
2.3.1 <a href="#sec-contentauthors">Content Authors</a><br />
2.3.2 <a href="#sec-webappdevelopers">Web Developers</a><br />
2.3.3 <a href="#sec-aggregators">Aggregators</a><br />
2.3.4 <a href="#sec-syndicators">Syndicators</a><br />
2.3.5 <a href="#sec-networkoperators">Network Operators & Carriers</a><br />
2.3.6 <a href="#sec-contentadaptors">Infrastructure Vendors</a><br />
2.3.7 <a href="#sec-bandcswmanf">Browser Manufacturers</a><br />
2.3.8 <a href="#sec-devicemanufacturers">Device Manufacturers</a><br />
2.3.9 <a href="#sec-osframeworkproviders">Device Description Providers</a><br />
2.3.10 <a href="#sec-standardsorgs">Relevant Standards Organizations</a><br />
2.3.11 <a href="#sec-devicevalidators">Device Quality Assurance</a><br />
2.3.12 <a href="#sec-qualityassurance">Content Quality Assurance</a><br />
3 <a href="#sec-currenttechnologies">Review of current technologies</a><br />
3.1 <a href="#sec-methodology">Methodology</a><br />
3.2 <a href="#sec-questionnaire">Questionnaire</a><br />
3.3 <a href="#sec-featurematrix">Feature matrix</a><br />
3.3.1 <a href="#sec-datamodel">Data model</a><br />
3.3.2 <a href="#sec-simplicity">Simplicity</a><br />
3.3.3 <a href="#sec-essentialproperties">Essential device attributes</a><br />
3.3.3.1 <a href="#sec_essscreen">Screen dimensions</a><br />
3.3.3.2 <a href="#sec_essprefmarkup">Supported & preferred markup</a><br />
3.3.3.3 <a href="#sec_esspreimages">Supported & preferred image formats</a><br />
3.3.3.4 <a href="#sec_esssize">Size limitations</a><br />
3.3.3.5 <a href="#sec_esscolor">Color support</a><br />
3.3.3.6 <a href="#sec_essbrowserfeatures">Other browser features</a><br />
3.3.3.7 <a href="#sec_essobjects">Non-markup object support</a><br />
3.3.4 <a href="#sec-extensibility">Extensibility</a><br />
3.3.5 <a href="#sec-querymechanism">Query Mechanism</a><br />
4 <a href="#sec-findings">Recommendations</a><br />
4.1 <a href="#sec-datastructures">Data structures</a><br />
4.2 <a href="#sec-dataintegrityandcapture">Data integrity and capture</a><br />
4.3 <a href="#sec-queryandaccess">Query and access</a><br />
5 <a href="#sec-conclusion">Conclusion</a><br />
</p>
<h3 id="appendices">Appendices</h3><p class="toc">A <a href="#sec-references">References</a><br />
B <a href="#sec-acknowledgements">Acknowledgments</a><br />
</p></div><hr /><div class="body"><div class="div1">
<h2 id="sec-introduction">1 Introduction</h2><p>Web access from mobile devices suffers from problems that make the Web unattractive for most mobile users. W3C's Mobile Web Initiative (MWI) proposes to address these issues through a concerted effort of key players in the mobile value chain, including authoring tool vendors, content providers, handset manufacturers, browser vendors and mobile operators. </p><p>The objective of the W3C Mobile Web Initiative is to enable access to the Web from mobile devices. It is recognized that this will generally require adaptation of web content and therefore an understanding of the different characteristics, features, behaviors and limitations of mobile handsets.</p><p>Within the MWI, the mission of the Device Description Working Group (DDWG) is to foster the provision of, and access to, these consistent and reliable, Device Descriptions that can be used to help develop and deliver high-quality mobile web applications to the world's mobile devices.</p><div class="div2">
<h3 id="sec-objectivescope">1.1 Objective & Scope</h3><p>This "Landscape document" is designed to describe the current state of the various options that exist for providing Device Descriptions to enable device-aware applications. </p><p>It articulates what the W3C and other organizations are doing, or have already done, in this space, and identifies various ways in which those Device Descriptions are being used.</p><p>Note that this group recognizes that there are many other use cases for Device Descriptions, and other areas within the mobile industry where they can be applied.</p><p>This document does not seek to strongly define how such Device Descriptions should be provided in the future. It lays out descriptions of the technologies and standards that are available today.</p></div><div class="div2">
<h3 id="sec-audience">1.2 Audience</h3><p>This document is to be read by a generally technical audience. In particular, we expect that readers are familiar both with Web and existing mobile technologies. Since the document relates to the use of mobile Device Descriptions for content adaptation, an appreciation of the diversity present in mobile handsets - and the techniques used for adapting content to them - is assumed. More information on this diversity can be found in the archives of the Device Independence Working Group <a href="#ref-DIWG">[DIWG]</a> and in the ongoing work of the Ubiquitous Web Applications Working Group <a href="#ref-UWA">[UWA]</a>.</p></div><div class="div2">
<h3 id="sec-relatedgroups">1.3 Related groups and organizations</h3><p>The DDWG coordinates their work with the related efforts within the W3C, including:</p><ul><li><p>Web Accessibility Initiative (<a href="#ref-WAI">[WAI]</a>)</p></li><li><p>Ubiquitous Web Applications Working Group (<a href="#ref-UWA">[UWA]</a>)</p></li><li><p>MWI Best Practices Working Group (<a href="#ref-MWBP">[MWBP]</a>)</p></li></ul><p>The DDWG is establishing working relationships - based on formal liaisons, if and where appropriate - with certain organizations outside of the W3C, whose activities might impact the Mobile Web Initiative and/or be influenced by it, including: </p><ul><li><p>GSM Association (<a href="#ref-GSMA">[GSMA]</a>)</p></li><li><p>Open Mobile Terminal Platform (<a href="#ref-OMTP">[OMTP]</a>)</p></li><li><p>Open Mobile Alliance (<a href="#ref-OMA">[OMA]</a>)</p></li><li><p>Wireless Universal Resource File (<a href="#ref-WURFL">[WURFL]</a>)</p></li></ul><p>Many of the above groups (or their members) either provide, specify, or have a need to consume mobile-focused Device Descriptions.</p></div><div class="div2">
<h3 id="sec-definitions">1.4 Definitions</h3><p>Readers should also refer to the Device Independence Glossary, <a href="#ref-DIG">[DIG]</a>, which is also relevant to this document.</p><div class="div3">
<h4 id="sec-browser">1.4.1 Browser</h4><p>A user agent that allows a user to perceive and interact with information on the Web.</p><p>See "<a href="http://www.w3.org/TR/di-gloss/#def-browser">Browser</a>" in <a href="#ref-DIG">[DIG]</a></p></div><div class="div3">
<h4 id="sec-contentadaptation">1.4.2 Content adaptation</h4><p>A process of selection, generation or modification that produces content in response to a requested URI in a given delivery context. This context includes the capabilities of the device, as well as a set of attributes that characterizes the capabilities of the access mechanism, and the preferences of the user.</p><p>Content adaptation is used in order to ensure that the application will render and operate as optimally as possible on a range of difference device clients.</p><p>Definition: a process of selection, generation or modification that produces one or more perceivable units in response to a requested uniform resource identifier in a given delivery context. See "Adaptation" in <a href="#ref-DIG">[DIG]</a>.</p></div><div class="div3">
<h4 id="sec-device">1.4.3 Device</h4><p>An apparatus through which a user can perceive and interact with the Web.</p><p>See "<a href="http://www.w3.org/TR/di-gloss/#def-device">Device</a>" in <a href="#ref-DIG">[DIG]</a>.</p></div><div class="div3">
<h4 id="sec-devicedescription">1.4.4 Device Description</h4><p>A data structure that describes the characteristics and behaviors of a device. Conceptually, a Device Description provides both knowledge to be able to identify a device from its requests for content, and data about the devices attributes so that content adaptation can be effectively performed.</p></div><div class="div3">
<h4 id="sec-mobiledevice">1.4.5 Mobile device</h4><p>A mobile device is taken to be a device that is portable, that can access the Web and that is intended for use while in motion. To be clear, this is a subset of the category of 'wireless devices' which also includes devices used while stationary, but without physical connections, such as Wifi-enabled laptops.</p><p>For most purposes, the 'mobile device' term is used to imply web-enabled cellular terminals or phones, and personal digital assistants.</p></div></div></div><div class="div1">
<h2 id="sec-motivations">2 Motivations</h2><div class="div2">
<h3 id="sec-theneedfordevicedescriptions">2.1 The need for Device Descriptions</h3><p>Development of applications, content, and web-based services for mobile devices is more challenging than development for desktop devices. This is because they come in a much wider range of shapes, sizes and capabilities, and because they have a much wider range of browser implementations. All of these factors can affect the way in which the application behaves, quite possibly as an impact to what the developer intended.</p><p>In order to cope with this complex user-agent audience, content authors and run-time systems need to dynamically adapt their applications to behave in different ways for different devices. Clearly, the success of this dynamic behavior depends greatly on the quality of knowledge that such individuals or systems have about those devices.</p></div><div class="div2">
<h3 id="sec-ddforca">2.2 Device Descriptions for content adaptation</h3><p>Although there are a number of clear benefits for the use of Device Descriptions in other use cases, and in other parts of the mobile industry, this Landscape Document primarily focuses on their use for content adaptation.</p><p>Content adaptation can be provided in a number of ways. The following four sections detail the common options and techniques, and how Device Descriptions are valuable in enabling these techniques.</p><div class="div3">
<h4 id="sec-originserver">2.2.1 Origin-server adaptation</h4><p>If a web server or an application server is able to identify a mobile device sufficiently, it can draw on Device Description information to make decisions about how the content should be generated.</p><p>Content adaptation at the primary origin server is a very common technique, simply because it is at this end of the delivery chain that the degree of control over the content is at its greatest.</p><p>The need for Device Descriptions in the technique is significant. There must be an ability to be able to recognize the class of device from its request, and sufficient knowledge about that device's attributes to be able to perform appropriate, and valuable adaptation.</p><p>In the content server environment, it is often the case that a large, and unconstrained portfolio of devices will be accessing the content, with requests being relayed from a wide range of mobile networks.</p><p>This puts a particular demand on the ability of the server to recognize (and have Device Descriptions for) hundreds, if not thousands, of accessing device types. Alternatively there should be an ability for the recognition process to generalize and 'fallback' to the most similar device class for which it does have such Device Descriptions.</p><p>With correct and appropriate Device Description information, an origin server can potentially make radical decisions about the content, whilst easily retaining the application's integrity. For example, a server could choose to make whole sections of a site or application inaccessible if a Device Description asserted that those sections were beyond the capabilities of a client.</p><p>More refined decisions might include changes to the markup or binary structures of the content dispatched. For example, an origin server could easily switch between WML, CHTML or XHTML according to browser's known behavior. Different object formats can also be easily adapted at the origin server. For example, a server may decide to use images of different resolution or color-depth in a page if the handset's screen limitations are known.</p><p>Additionally, a significant amount of 'fine-tuning' of content can also be performed by a content server with a relatively low overhead. Cosmetic formatting, form layout, and other subtle markup attributes can easily be changed according to Device Description information.</p><p>One disadvantage of origin-server adaptation, on the other hand, is the complexity of setting up such dynamic behavior on the server. This approach is clearly not appropriate for static web content. </p></div><div class="div3">
<h4 id="sec-deliveryinfrastructure">2.2.2 Delivery infrastructure</h4><p>Content adaptation is also possible at points along the delivery chain between the origin server and the client. Many entities may be involved in delivering content across a mobile network in particular, and some of those, notably those in the IP-context, can perform on-the-fly adaptation of both the requests for the documents from, and the documents being returned to, the client through. These entities include WAP gateways, web proxies and dedicated transcoding platforms.</p><p>This 'smart proxy' approach to adaptation can be powerful, and can theoretically perform adaptation in as rich a way as can occur at the origin server. However, this comes at a performance cost, since the content may have to undergo a decompilation (or parse) and recompilation (or serialization) in order to be examined and adapted.</p><p>More importantly, there is an additional challenge to ensure that the context of the content is understood, so that the adaptation is relevant, and any changes made still reflect the origin server's intent. This may require a statefulness within the proxy which can be architecturally challenging. (For example, if a proxy provides large-page fragmentation for a device with memory constraints, any load-balancing techniques would need to ensure that successive requests for page fragments are serviced by a proxy that is aware of the device's previous page state).</p><p>The author's desire to be able to employ contextual information (e.g. descriptions of devices) is being addressed by new technical proposals such as DISelect <a href="#ref-DISelect">[DISelect]</a></p><p>However, a real advantage of in-delivery adaptation is the fact that it allows the improvement, or device-awareness, of content that was statically hosted on its origin server, and which was not provided in a device-aware context.</p><p>The need for Device Descriptions for adapting content in the delivery chain is similar to the need within the origin server. A wide range of attributes about a device can be used effectively by the proxy, and, similarly to the content server, suitable adaptation relies heavily on the ability to recognize the device type.</p><p>In this regard, adaptation in the delivery infrastructure may benefit from the fact that a smaller range of device types are being serviced. A transcoding platform in a mobile operator's network will be able to assume, for most requests, that the device is one supported and provisioned on that network.</p></div><div class="div3">
<h4 id="sec-clientside">2.2.3 Client-side adaptation</h4><p>Some device clients are capable of adaptive rendering. This technique involves the browser using information about its host device to decide how to best layout and display the content.</p><p>Whilst this is an approach that has real benefits for enabling the mobile web as a whole, a given browser installation, by definition, does not need to rely on multiple Device Descriptions. The browser only requires knowledge about the host device in order to perform client-side adaptation, although this can be either determined by the browser at run time or have been provisioned at design time by the browser manufacturer.</p><p>The scope of Device Description information required in this technique is likely to be a subset of that needed by server- or infrastructure-side adaptation. Naturally, the need to identify the device is reduced since it is the browser's host.</p><p>It should also be clear that the ability to perform structural adaptation of the content and application is reduced. The client can only adapt and render the content that has reached the device. It cannot augment that content, nor be aware of content that has not been yet retrieved, such as documents that the current page links to.</p><p>As a result, many Device Description attributes may be impotent in the client-side adaptation context. For example, although a content server is able to remove or rewrite links to unsupported document or object types, a client is unlikely to be even aware of the target document's or object's type. Device Description knowledge about which types are or are not supported is therefore less actionable.</p></div><div class="div3">
<h4 id="sec-designtime">2.2.4 Design-time</h4><p>If Device Descriptions are provided in a sufficiently human- readable form, there is no reason why they could not be used for creating device-specific content in a design-time context.</p><p>For example, if a content developer is made aware of the differences between handsets when developing an application, it may be possible to integrate that knowledge directly into the content itself, and allow that human being to make sensible decisions about the nature of the adaptation required.</p><p>At the most basic level, this could involve creating two or more sets of parallel content for each group or genre of device. A single dynamic 'doorstep' page can redirect the handset to the correct content when the device first accesses the content. (Note that DDWG does not necessarily recommend this technique, since it has many disadvantages).</p><p>A slightly more scalable approach is to use Device Description information to create stylesheets of some kind (for example XSL) for each class of handset at design-time. This allows a better separation of content and its adaptation. </p><p>Regardless of the approach, the need for Device Description data is still significant at design-time. While it is less essential to articulate recognition knowledge to the designer, most other Device Description attributes can be utilized at this stage, particularly 'macro-attributes' which relate to devices' significant characteristics, features and document type support. </p></div></div><div class="div2">
<h3 id="sec-usersofdd">2.3 The users and providers of Device Descriptions</h3><p>A broad range of organizations and individuals have a stakeholding in successful mobile web content delivery, and participate in the consumption and provision of Device Descriptions. This section details some of these parties and contributions, and should be read in conjunction with the Ecosystem Document sections on their roles.</p><div class="div3">
<h4 id="sec-contentauthors">2.3.1 Content Authors</h4><p>Content authors are responsible for the primary authorship, development, or editorship of mobile content and applications. Authors are concerned that the content they create is properly represented to the user, regardless of device.</p><p>Even at the earliest stages of content origination, Device Description knowledge can be valuable. A journalist, for example, may even make editorial changes to mobile-destined content (such as front loading a news article) if aware of devices' limited screen or page sizes.</p></div><div class="div3">
<h4 id="sec-webappdevelopers">2.3.2 Web Developers</h4><p>Web developers are responsible for integrating content into a web site or application so that it can be navigated and accessed. Their desire is to ensure structural integrity, navigational ease, and cosmetic consistency within a site, regardless of accessing device.</p><p>They use Device Description information both at design- and run-time to determine the amount, type and variations of content to provide. </p><p>For example, a developer can influence which links, navigational structures, and documents are provided on a device-by-device basis.</p><p>As a more superficial example, it is common for logos and icon be available in a number of different formats and sizes at design-time. Device Descriptions can be used to choose which images to use at run-time.</p></div><div class="div3">
<h4 id="sec-aggregators">2.3.3 Aggregators</h4><p>Aggregators gather content and applications from multiple developers or authors and present them to the user in a consistent and structured way. Many mobile operator portals for example, provide directory services linking to hosted, and external, content from a variety of sources.</p><p>Aggregators require Device Descriptions in the same way that web developers do, since the aggregator will typically be providing a site structure in which to place the aggregated links and content, and which should be successful regardless of the accessing device.</p><p>In particular, some aggregators choose to group together the content according to accessing device type. It is possible to find directories of content designed for one manufacturer's devices, or even for particular extraordinary devices. In these cases, Device Description knowledge may be required even when the choice of aggregated source is made.</p></div><div class="div3">
<h4 id="sec-syndicators">2.3.4 Syndicators</h4><p>Like aggregators, syndicators gather content from a variety of sources. However, that content is not necessarily ready for device consumption, having perhaps been syndicated in some machine-readable format.</p><p>Therefore Device Descriptions are required by the syndicator to be able to transform the machine-readable content into final device-ready markup.</p></div><div class="div3">
<h4 id="sec-networkoperators">2.3.5 Network Operators & Carriers</h4><p>Operators provide the base IP infrastructure and cellular backbone for delivering content and applications to mobile devices. As the key provider of the mobility and telephony services for the mobile user, the operator has a great desire to ensure the quality of the overall user experience.</p><p>Operators commonly provide portals and content services of their own (which often both syndicate and rival products from the content providers described above), as well as much of the delivery infrastructure. Additionally, they often run third party developer and partner provider programs to encourage the authorship of mobile content for their users. </p><p>They are therefore important consumers of Device Descriptions for both origin server and proxy-based content adaptation.</p><p>In addition, most network operators have a high degree of control over which mobile device types (and subrevisions) are recommended for use on their networks, and generally type-approve and certify handsets beforehand. Many operators use this process as a way of obtaining their own Device Descriptions for use in various forms of content adaptation.</p></div><div class="div3">
<h4 id="sec-contentadaptors">2.3.6 Infrastructure Vendors</h4><p>A number of software vendors provide platforms designed to ease the process of adapting content for a variety of devices. These platforms often reside in the application-server (as an adaptation plug-in or transcoding layer), or in the delivery infrastructure (as a 'smart' proxy).</p><p>In both cases, a rich understanding of client capabilities is required, and many of these vendors provide Device Descriptions as part of their products.</p></div><div class="div3">
<h4 id="sec-bandcswmanf">2.3.7 Browser Manufacturers</h4><p>A mobile handset device typically comprises a large number of software components, many of which are provided to the device manufacturers by third-party OEMs. These components might include operating systems, messaging clients, and, most importantly for this document, mobile web browsers. Some device manufacturers also develop their own client software.</p><p>These parties are important providers of Device Descriptions more than they are consumers, except in the case of client-side adaptation, where the browser itself will behave based on information about the host device.</p></div><div class="div3">
<h4 id="sec-devicemanufacturers">2.3.8 Device Manufacturers</h4><p>Manufacturers and vendors of handsets are typically well- known consumer brands, although some network operators offer branded handsets, which are often significantly different (at both a hardware and software level) from the base, non-customized model they derive from.</p><p>The device manufacturers are clearly responsible for the physical attributes and behaviors of the device, and are generally also responsible for the choice of browser that will run on the device.</p><p>They are therefore important providers of Device Descriptions.</p></div><div class="div3">
<h4 id="sec-osframeworkproviders">2.3.9 Device Description Providers</h4><p>Such is the importance of Device Descriptions to enable mobile data applications, that many commercial and open-source providers exist. These providers are not necessarily the manufacturers of the devices they describe.</p><p>These are primarily designed to offer Device Description data to content providers, web developers, and in some cases, infrastructure providers.</p><p>Notable examples in the open-source realm include WURFL (which provides standalone Device Descriptions, but also delivers a set of programmatic APIs for server-side content adaptation), and DELI, which assists in the usage of UAProf Device Descriptions.</p></div><div class="div3">
<h4 id="sec-standardsorgs">2.3.10 Relevant Standards Organizations</h4><p>The industry has already recognized that the need for Device Descriptions is an important one. Notably, W3C's CC/PP <a href="#ref-CCPP">[CCPP]</a> and OMA's UAProf <a href="#ref-UAProf">[UAProf]</a> standards are particularly relevant to this landscape.</p></div><div class="div3">
<h4 id="sec-devicevalidators">2.3.11 Device Quality Assurance</h4><p>As we have mentioned, network operators have an imperative to approve the quality of the devices that are launched onto their network.</p><p>In this realm, there are vendors of test and measurement equipment who assist in the generation of Device Descriptions from this process.</p></div><div class="div3">
<h4 id="sec-qualityassurance">2.3.12 Content Quality Assurance</h4><p>Both operators and content providers perform testing and quality assurance on the services they provide to end consumers, and a wide range of techniques and tools exist to do this.</p><p>In particular, some of these tools use Device Descriptions directly in order to simulate accessing devices, and to identify if the content response is compatible with those devices.</p></div></div></div><div class="div1">
<h2 id="sec-currenttechnologies">3 Review of current technologies</h2><div class="div2">
<h3 id="sec-methodology">3.1 Methodology</h3><p>In order to reflect the state of Device Description and content adaptation technologies the MWI issued a public questionnaire <a href="#ref-DD-Survey">[DD-Survey]</a>. The results of this questionnaire combined with the feedback from the MWI membership and the public DDWG mailing list have been used as the basis for this section.</p><p>All identifying information from the questionnaire has been removed prior to being included here.</p></div><div class="div2">
<h3 id="sec-questionnaire">3.2 Questionnaire</h3><p>The questionnaire was published in August of 2005, and received 17 responses. It contains 13 questions specifically about the collection, storage, and usage of Device Descriptions.</p><p>The questionnaire was designed to establish how Device Descriptions are being created and consumed, and to identify the scope of the way in which they are being used.</p><p>Amongst the respondents were browser developers, content adaptation solution providers, and other standards bodies. 12 of the 17 responses were from content adaptation providers, and thus this section is biased towards content adaptors.</p></div><div class="div2">
<h3 id="sec-featurematrix">3.3 Feature matrix</h3><p>In this section, we review the findings of the questionnaire.</p><p>The results of the survey indicate that the majority of content adaptation and Device Description solutions:</p><ul><li><p>are relevant to a wide variety of markup languages, the most common being HTML and WML variations</p></li><li><p>provide or consume extensible Device Description vocabularies</p></li><li><p>provide or consume Device Descriptions either programmatically or through database queries</p></li><li><p>use the OMA UAProf standard in some fashion; for example to seed the description database</p></li><li><p>provide a vocabulary for device attributes</p></li><li><p>utilize XML for storage or transmission of Device Descriptions in some capacity</p></li><li><p>are relevant to mobile devices with text and graphic screens, with touch screen, keyboard, and joystick inputs</p></li></ul><p>All responders expressing an opinion believe that device descriptions should be publicly available in some form, representing an appreciation of the importance of their role in assisting the success of the mobile web. </p><div class="div3">
<h4 id="sec-datamodel">3.3.1 Data model</h4><p>The data models used for Device Descriptions, according to respondents, vary from simple flat XML files with no inheritance to full relational databases. </p><p>A number of the data models used include a way to inherit from another Device Description. For example, if a new device is introduced that is similar to an existing device, a Device Description may only include the information that is different between the two, and rely on a logical reference to the description of the existing device to complete the description. UAProfile and CC/PP both provide a defaults mechanism that could be viewed as a limited form of inheritance.</p><p>Other data models described are more complex and include concepts similar to multiple inheritance, where a Device Description may extend other descriptions, or abstract classes of generic device.</p><p>Similar to inheritance is the technique of 'fallback', which is particularly relevant during the device recognition process prior to content adaptation. Fallback allows the matching of an unknown device with a 'best fit' device description. This allows for new devices that do not have a description available to still be used. For example, if an unknown device's manufacturer can at least be determined from say, the user-agent, it may be possible to utilize Device Description attributes which are known to be common to all of that manufacturer's devices.</p><p>Respondent's opinions vary on the techniques of fallback and inheritance. The more complex data models that makes use of inheritance and fallback result in a smaller Device Description repositories, as redundant descriptions are 'factored out'. On the other hand, a simpler data model without inheritance can help avoid quality control issues that can occur in a complex data model. For example, when inheritance is used, a change in a base device description may adversely effect multiple Device Descriptions, perhaps unintentionally.</p></div><div class="div3">
<h4 id="sec-simplicity">3.3.2 Simplicity</h4><p>The questionnaire included a question about the number of properties required for acceptable adaptation. From the responses, it is believed that acceptable adaptation can be achieved through a relatively small number of device properties, although radically different attributes are valuable in particular content adaptation contexts, or for particular applications.</p><p>(As a simple example, the attributes needed by a mobile photo download site would mostly refer to the devices' abilities to support graphics formats, whereas a text-based news site might rather benefit from attributes concerning page size and navigation behavior.)</p><p>In any case, certain properties are absolutely required, and are critical for the author or adaptor, while a larger number of properties are required to perform more accurate adaptation. The presence of hundreds to thousands of properties in some of the surveyed solutions indicates that further properties are needed for complex tasks, or where a range of different applications or contexts are being serviced.</p></div><div class="div3">
<h4 id="sec-essentialproperties">3.3.3 Essential device attributes</h4><p>As a result of this questionnaire, the DDWG conducted a follow-up member poll, to develop a list of 'core attributes', that are deemed essential for content adaptation. While some of these items represent relatively broad functionality of mobile devices, and aren't yet necessarily defined unambiguously, this list does serve to illustrate the areas of diversity in mobile devices that cause challenges when developing for the mobile web. </p><p>The following sections describe these attributes and property groups in more detail.</p><div class="div4">
<h5 id="sec_essscreen">3.3.3.1 Screen dimensions</h5><p>As it is generally the primary output paradigm for a mobile devices, knowledge about the characteristics of the screen were deemed to be essential for content adaptation. Screen size is important since it constrains the amount of web content that can be displayed at one time.</p><p>It is also important because devices exhibit a range of ways in which content that exceeds the screen size is rendered and navigated, including image rescaling, cropping, text wrapping, truncation and auto-scrolling. An understanding of the screen size itself reduces the need to understand the subtleties of these complex behaviors in a given device.</p><p>At the same time, it should be appreciated that there are many ways of defining screen dimensions. Which units of measure are required (pixels, centimeters, etc) and which object measure is required for (physical screen(s), browser canvas, scrollable view-port, etc) will vary depending on many contextual factors.</p></div><div class="div4">
<h5 id="sec_essprefmarkup">3.3.3.2 Supported & preferred markup</h5><p>Since a major branching point in many content adaptation processes is the choice of which markup to provide to a device, a rich understanding of what content it supports and prefers is essential for those processes.</p><p>Many mobile devices are capable of displaying only one type of markup. However, others support multiple web (and legacy) markups, often interchangeably. In addition, many devices are lax at parsing markup and can often perform surprisingly well at rendering types for which they do not claim support.</p><p>All of these factors drive the need for attributes to capture this behavior. Required knowledge certainly includes which markup is most preferred, but also which are claimed to be supported - and how they correlates to the 'accepted' MIME-types in the device's requests.</p></div><div class="div4">
<h5 id="sec_esspreimages">3.3.3.3 Supported & preferred image formats</h5><p>In a similar way to markup, devices support and prefer a range of different image formats. and knowledge about this behavior is essential for content adaptation of any rich content.</p><p>Describing image support is also a relatively complex task, since most major image formats have optional features or variants that a device may or may not separately support. Image support also needs to be correlated with the 'accepted' MIME-types in the device's request. However, at the very least, knowing which major formats are supported is essential.</p></div><div class="div4">
<h5 id="sec_esssize">3.3.3.4 Size limitations</h5><p>As most mobile devices are of limited dimension and form-factor, the memory constraints of the device's software are often significant when delivering mobile web content to them.</p><p>In particular, the maximum page markup size, image size, and overall page weight are device attributes that are of value to a content adaptation process.</p><p>Detailed knowledge about these behaviors may become less necessary in the future as device memory sizes inexorably rise.</p></div><div class="div4">
<h5 id="sec_esscolor">3.3.3.5 Color support</h5><p>Whether a device supports color content, to what color-depth, and how it behaves when the content's color-depth is higher (dithering or grey-scaling, for example) is value knowledge for a content adaptation system.</p><p>However, many modern mobile devices now support color well, and over time, it is likely that these attributes decrease in value.</p></div><div class="div4">
<h5 id="sec_essbrowserfeatures">3.3.3.6 Other browser features</h5><p>There are many mobile web markup features, rendering behaviors, and auxiliary techniques that certain devices support well, whilst others do not. It is clear that some degree of knowledge for these subtleties of browser behavior is required in a Device Description.</p><p>Examples provided include table support (including maximum column and row sizes, support for merged cells, and so on), multi-part-MIME support (for amalgamated page delivery), and Digital Rights Management adherence.</p><p>Reference was also made by respondents to general browser faults or bugs. It is valuable for a content adaptation system to be aware of unsatisfactory behavior of device browsers under certain conditions, so that those conditions can be avoided.</p></div><div class="div4">
<h5 id="sec_essobjects">3.3.3.7 Non-markup object support</h5><p>Finally, in responses to this poll, many attached value to understanding device support for non-markup objects that are either embedded in a page or linked to from a page.</p><p>These types include video (both embedded and streamed), J2ME (or other applications) ringtones, and other audio types.</p><p>While some of these can be deemed to be beyond the scope of the mobile web per se, it should be appreciated that these types of content are popular amongst mobile device users. It is for the download of video clips, ringtones, and games to their devices that many users will interact with mobile web technologies at all.</p></div></div><div class="div3">
<h4 id="sec-extensibility">3.3.4 Extensibility</h4><p>All of the content adaptation technologies surveyed provide a mechanism for extending the Device Description. There is a wide appreciation that the areas of diversity between mobile devices is a moving target and that any technology that describes devices needs to be adaptable and extensible. Similarly, it is essential that a Device Description repository itself be extensible in order to accommodate new devices, device attributes, and use cases.</p><p>When discussing a publicly available shared Device Description repository, extensibility is even more relevant, as a public repository may be used in any number of ways, and should be as accommodating as possible.</p></div><div class="div3">
<h4 id="sec-querymechanism">3.3.5 Query Mechanism</h4><p>All of the content adaptation technologies surveyed allow for querying the Device Descriptions, either through a programmatic interface or via database queries.</p><p>There are a number of ways in which queries are used. Obviously, it is essential that the Device Descriptions be available at adaptation time. It is also important that authors be able to query descriptions at design-time in order to determine which properties may be available and what general trends of device support exist. The Device Description repository may also be queried for statistical or analytical usage, such as determining the number of devices that support a particular markup language.</p></div></div></div><div class="div1">
<h2 id="sec-findings">4 Recommendations</h2><p>In the review of Device Description technologies, we have identified a number of common trends, and 'best practices' in the storage and usage of Device Descriptions. This section is designed to articulate some of the high level recommendations that should be considered when creating Device Description repository requirements. The following recommendations will be used as a basis for the DDWG Repository Requirements document.</p><div class="div2">
<h3 id="sec-datastructures">4.1 Data structures</h3><p>A successful Device Description technology will have many of the following characteristics with respect to its data structure:</p><ul><li><p>Capacity - the ability to store descriptions for at least thousands of devices and hundreds of attributes </p></li><li><p>Extensibility - the ability to add new attributes to the Device Description, including attributes related to non-Web features</p></li><li><p>Programmability - the ability to have data inserted, extracted, and queried through one or many interfaces</p></li><li><p>Fallback on recognition - the ability to provide, or reference, alternative Device Descriptions when an exact match is not available</p></li><li><p>Strong Data Typing - the ability to constrain the Device Description data to particular data types with unambiguous units</p></li></ul></div><div class="div2">
<h3 id="sec-dataintegrityandcapture">4.2 Data integrity and capture</h3><p>A successful Device Description technology will generally have the following characteristics with respect to the integrity and recording of device description information into its repository:</p><ul><li><p>Strong Data Typing - the ability to constrain the input data to particular data types and unambiguous units</p></li><li><p>Accuracy - a process or methodology that ensures the recording of reproducible device description data</p></li><li><p>Precision - the ability to capture and record data precise enough to be useful for content adaptation</p></li><li><p>Auditability - the ability to record the origin of, and subsequent changes to, device description data</p></li></ul></div><div class="div2">
<h3 id="sec-queryandaccess">4.3 Query and access</h3><p>A successful Device Description technology will generally have the following characteristics with respect to the ability to query or access data from its repository:</p><ul><li><p>Strong Data Typing - the ability to constrain the input data to particular data types and unambiguous units</p></li><li><p>Readability - data formatting (or reporting) that allows human-readership of device description data. (not mandatory)</p></li><li><p>Header keying - the ability to provide a Device Description in response to a query comprising the device user agent or other other information included in the request from the client</p></li><li><p>Inheritance on query - the ability to logically associate a device with a similar device's description, or to be able to cascade attributes from parent device classes</p></li><li><p>Auditability - the ability to trace and track the origin of, and subsequent changes to, device description data</p></li></ul></div></div><div class="div1">
<h2 id="sec-conclusion">5 Conclusion</h2><p>The evidence gathered and summarized in this document demonstrates that there is a strong, yet inconsistent, role for device descriptions in a number of usage domains. There is no single agreed representation of device properties, or common means of conveying such data to services that can make best use of them. A number of competing and proprietary solutions exist. A single technology that could encompass all of the identified solutions, to provide a common representation and programmatic interface for device descriptions would be beneficial to the many constituents of the device description landscape. Interoperability will create new opportunities to extend the Web to diverse clients, particularly in the growing mobile market. The DDWG is encouraged to pursue this goal.</p></div></div><div class="back"><div class="div1">
<h2 id="sec-references">A References</h2><dl><dt class="label"><a name="ref-CCPP" id="ref-CCPP"></a>CCPP</dt><dd><a href="http://www.w3.org/TR/2004/REC-CCPP-struct-vocab-20040115/">
<em><a href="http://www.w3.org/TR/2004/REC-CCPP-struct-vocab-20040115/">"Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies 1.0"</a></em>, Graham Klyne, Franklin Reynolds, Chris Woodrow, Hidetaka Ohto, Johan Hjelm, Mark H. Butler, Luu Tran, Editors, revised 15 January 2004.
</a> (See http://www.w3.org/TR/2004/REC-CCPP-struct-vocab-20040115/.)</dd><dt class="label"><a name="ref-DD-Survey" id="ref-DD-Survey"></a>DD-Survey</dt><dd><a href="http://www.w3.org/2005/MWI/DDWG/questionnaire.html">
<em><a href="http://www.w3.org/2005/MWI/DDWG/questionnaire.html">"Device Description Technologies Survey"</a>, conducted by DDWG</em>
</a> (See http://www.w3.org/2005/MWI/DDWG/questionnaire.html.)</dd><dt class="label"><a name="ref-DDWG-Ecosystem" id="ref-DDWG-Ecosystem"></a>DDWG-Ecosystem</dt><dd><a href="http://www.w3.org/TR/dd-ecosystem/">
<em><a href="http://www.w3.org/TR/dd-ecosystem/">"Device Description Ecosystem"</a></em>, Rotan Hanrahan, Editor, revised 21 November 2005.
</a> (See http://www.w3.org/TR/dd-ecosystem/.)</dd><dt class="label"><a name="ref-DDWG-Charter" id="ref-DDWG-Charter"></a>DDWG-Charter</dt><dd><a href="http://www.w3.org/2005/01/DDWGCharter/">
<em><a href="http://www.w3.org/2005/01/DDWGCharter/">"W3C MWI Device Description Working Group Charter"</a></em>, Rotan Hanrahan, Stephane Boyera, revised 20 June 2005.
</a> (See http://www.w3.org/2005/01/DDWGCharter/.)</dd><dt class="label"><a name="ref-DIG" id="ref-DIG"></a>DIG</dt><dd><a href="http://www.w3.org/TR/di-gloss/">
<em><a href="http://www.w3.org/TR/di-gloss/">"Glossary of Terms for Device Independence"</a></em>, Rhys Lewis, Editor.
</a> (See http://www.w3.org/TR/di-gloss/.)</dd><dt class="label"><a name="ref-DISelect" id="ref-DISelect"></a>DISelect</dt><dd><a href="http://www.w3.org/TR/cselection/">
<em><a href="http://www.w3.org/TR/cselection/">"Content Selection for Device Independence (DISelect) 1.0"</a></em>, Rhys Lewis, Roland Merrick, Editors, revised 02 May 2005.
</a> (See http://www.w3.org/TR/cselection/.)</dd><dt class="label"><a name="ref-DIWG" id="ref-DIWG"></a>DIWG</dt><dd><a href="http://www.w3.org/2001/di/ ">
<em><a href="http://www.w3.org/2001/di/">"Device Independence Working Group"</a></em>
</a> (See http://www.w3.org/2001/di/ .)</dd><dt class="label"><a name="ref-GSMA" id="ref-GSMA"></a>GSMA</dt><dd><a href="http://www.gsmworld.com">
<em><a href="http://www.gsmworld.com">"GSM Association"</a></em>.
</a> (See http://www.gsmworld.com.)</dd><dt class="label"><a name="ref-MWBP" id="ref-MWBP"></a>MWBP</dt><dd><a href="http://www.w3.org/2005/MWI/BPWG/ ">
<em><a href="http://www.w3.org/2005/MWI/BPWG/">"W3C MWI Mobile Web Best Practices Working Group"</a></em>
</a> (See http://www.w3.org/2005/MWI/BPWG/ .)</dd><dt class="label"><a name="ref-OMA" id="ref-OMA"></a>OMA</dt><dd><a href="http://www.openmobilealliance.org">
<em><a href="http://www.openmobilealliance.org">"Open Mobile Alliance"</a></em>.
</a> (See http://www.openmobilealliance.org.)</dd><dt class="label"><a name="ref-OMTP" id="ref-OMTP"></a>OMTP</dt><dd><a href="http://www.omtp.org/">
<em><a href="http://www.omtp.org/">"Open Mobile Terminal Platform"</a></em>.
</a> (See http://www.omtp.org/.)</dd><dt class="label"><a name="ref-UAProf" id="ref-UAProf"></a>UAProf</dt><dd><a href="http://www.wapforum.org/what/technical/SPEC-UAProf-19991110.pdf">
<em><a href="http://www.wapforum.org/what/technical/SPEC-UAProf-19991110.pdf">"Wireless Application Group User Agent Profile Specification"</a></em>, Wireless Application Group, revised 10 November 1999.
</a> (See http://www.wapforum.org/what/technical/SPEC-UAProf-19991110.pdf.)</dd><dt class="label"><a name="ref-UWA" id="ref-UWA"></a>UWA</dt><dd><a href="http://www.w3.org/2007/uwa/">
<em><a href="http://www.w3.org/2007/uwa/">"W3C Ubiquitous Web Applications Working Group"</a></em>
</a> (See http://www.w3.org/2007/uwa/.)</dd><dt class="label"><a name="ref-WAI" id="ref-WAI"></a>WAI</dt><dd><a href="http://www.w3.org/WAI/">
<em><a href="http://www.w3.org/WAI/">"W3C Web Accessibility Initiative"</a></em>.
</a> (See http://www.w3.org/WAI/.)</dd><dt class="label"><a name="ref-WURFL" id="ref-WURFL"></a>WURFL</dt><dd><a href="http://wurfl.sourceforge.net">
<em><a href="http://wurfl.sourceforge.net">"Wireless Universal Resource File"</a></em>, Luca Passani and Andrea Trasatti, Creators.
</a> (See http://wurfl.sourceforge.net.)</dd></dl></div><div class="div1">
<h2 id="sec-acknowledgements">B Acknowledgments</h2><p>In addition to acknowledging the contributors to the previous draft, the editor also acknowledges the support of the active DDWG members during the group's second charter.</p></div></div></body></html>