- From: <fd@w3.org>
- Date: Tue, 06 Oct 2009 15:34:20 +0000
- To: casays <casays@yahoo.com>
- Cc: public-bpwg-comments@w3.org
Dear casays , The Mobile Web Best Practices Working Group has reviewed the comments you sent [1] on the Last Call Working Draft [2] of the Content Transformation Guidelines 1.0 published on 1 Aug 2008. Thank you for having taken the time to review the document and to send us comments! The Working Group's response to your comment is included below, and has been implemented in the new version of the document available at: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/. Please review it carefully and let us know by email at public-bpwg-comments@w3.org if you agree with it or not before 6 November 2009. In case of disagreement, you are requested to provide a specific solution for or a path to a consensus with the Working Group. If such a consensus cannot be achieved, you will be given the opportunity to raise a formal objection which will then be reviewed by the Director during the transition of this document to the next stage in the W3C Recommendation Track. Thanks, For the Mobile Web Best Practices Working Group, Dominique Hazaël-Massieux François Daoust W3C Staff Contacts 1. http://www.w3.org/mid/g7q5u2+r9mq@eGroups.com 2. http://www.w3.org/TR/2008/WD-ct-guidelines-20080801/ ===== Your comment on 2.2 Types of Transformation: > 1) Section 2.2.1: > > The CTG distinguishes between retructuring, recoding and > optimization. This is a useful approach, and the distinction > could be used more systematically across the document. However, > without a formal definition of these terms, various parties > are left with too much leeway when classifying some operations > one or the other of the categories. This may entail inconsistencies > regarding the interpretation of the guidelines. > > The guidelines should: > a) Define formally each of the three categories, possibly on > the basis of language theory. As an example, optimization seems > to be related to equivalent token streams (for textual content), > whereas recoding seems to deal with equivalent parse trees. Some > operations are reversible, others are not. The W3C is home to > technologies such as XSLT, so there should be competence there > to help ground definitions on solid formal concepts. Basing such > definitions on formal language theory is a suggestion, not a > requirement; other formally grounded definitions are possible. > b) Define exactly how to classify an operation that spans several > categories. As an example, converting HTML to XHTML while at the > same time eliminating comments and redundant white space should > amount to a recoding. Working Group Resolution (LC-2050): Final resolutions: - Re LC-2050 move definitions to scope to clarify that we are talking only about restructuring - re LC-2050 we don't intend to define these concepts any more formally than we do now ---- Your comment on 4.1.5 Alteration of HTTP Header Values: > 5) Section 4.1.5. > > Statement to be added: > > "In so far as the transformation carried out by the proxies is > to make content intended for a certain class A of devices > available to devices of another class B, then requests MUST NOT > be modified whenever a client of a certain class is accessing > content intended for its class. > > If the class of request (either mobile-optimized or full-Web) is > not unambiguously determined from the URI pattern, the proxy > MUST take into account the original user-agent to avoid > unnecessary transformations." > > Rationale: It is obviously pointless to transform full-Web > content accessed by full-Web capable devices (or vice-versa, > transforming mobile-optimized content for devices with mobile > browsers). Two cases illustrate the situation. > a) When full-Web devices such as advanced HTC PDAs, iPhones > or tablets access the Web, there is no guarantee that an > established server will include a no-transform directive; in > fact, it might explicitly leave it out to allow transformation > to cater for non-full-Web capable devices. Further, the > proposed heuristics will not work: the MIME types of returned > content will indicate full-Web content (e.g. text/html), as > well as the DOCTYPE (e.g. -//W3C//DTD HTML 4.01//EN). > b) When i-Mode terminal accessing i-Mode applications, there is > no guarantee that the corresponding servers return a no-transform > directive (since it is irrelevant for i-Mode applications). > Heuristics may not work either, since content is largely returned > as text/html, and without any DOCTYPE declaration. Working Group Resolution (LC-2053): Ref LC-2053, resolve partial and respond that we hope the current version of the document addresses this ---- Your comment on 4.3.6 Proxy Decision to Transform: > 3) Section 4.3.6 > > The third bullet under "examples of heuristics" is to be split > into two points: > > "the Content-Type of the response are known to be specific to the > device or class of device. At a minimum, the following MIME types > intended for mobile Web browsers MUST represent mobile-optimized > content: > > Browsing XHTML-related > application/vnd.wap.xhtml+xml > application/xhtml+xml > Browsing WML-related > text/vnd.wap.wml > application/vnd.wap.wmlc > text/vnd.wap.wml+xml > text/vnd.wap.wmlscript > application/vnd.wap.wmlscriptc > image/vnd.wap.wbmp > application/vnd.wap.wbxml > Browsing and downloading > application/vnd.wap.multipart.mixed > application/vnd.wap.multipart.related > application/vnd.wap.multipart.alternative > application/vnd.wap.multipart.form-data > > In addition, the following MIME types of the form */x-up-* > SHOULD be considered as representing mobile-optimized > content, at a minimum: > > Legacy Openwave > image/x-up-wpng > image/x-up-bmp > > The range of MIME types is intended to cover typical mobile > browsing applications. > > Transformations specified by the relevant standards are allowed > (WAP-236 WAE specifications 19.12.2001, WAP-192 WBXML specifications > 25.7.2001, WAP-191 WML specifications 19.2.2000 and predecessors, > WAP-193 WMLScript specifications 25.10.2000). > > In accordance with Internet standards and practices, a proxy > SHOULD determine whether a content is mobile-optimized FIRST by > examining the HTTP header field content-type, before inspecting > the XML declaration and its associated DOCTYPE." > > Rationale: Inspection of the HTTP field Content-type is an > usual mode of operation amongst transcoders. It is also simpler > and safer than applying heuristics on DOCTYPE, because inspecting > the content of a body requires one to deal with character encoding > issues (see RFC3023, XML 1.1 sections 4.3.3 and E), or parsing > multipart-structured content; these are unnecessary when handling > HTTP fields. Finally, specifying a minimum set of required MIME > types to take into account helps ensure that proxies will exhibit a > standard behaviour, and that non-textual content types for which > there is no DOCTYPE (notably mobile-specific image formats) are > properly dealt with. A normative document cannot leave full freedom > to implementors to select whichever subset of content types are to > be considered mobile-optimized or not. > > 4) Section 4.3.6 > > The second part of the bullet split as described in (b) is to contain > the following: > > "other aspects of the response such as the DOCTYPE are known to be > specific to the device or class of device. > > At a minimum, the following DOCTYPEs MUST be considered as > mobile-specific: > > XHTML mobile profile > -//OMA//DTD XHTML Mobile 1.2//EN > -//WAPFORUM//DTD XHTML Mobile 1.1//EN > -//WAPFORUM//DTD XHTML Mobile 1.0//EN > XHTML basic > -//W3C//DTD XHTML Basic 1.1//EN > -//W3C//DTD XHTML Basic 1.0//EN > -//OPENWAVE//DTD XHTML 1.0//EN > -//OPENWAVE//DTD XHTML Mobile 1.0//EN > XHTML i-Mode > -//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/1.0) 1.0//EN > -//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/1.1) 1.0//EN > -//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/2.0) 1.0//EN > -//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/2.1) 1.0//EN > -//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/2.2) 1.0//EN > [list completed in > http://lists.w3.org/Archives/Public/public-bpwg-comments/2008JulSep/0150.html > with: > -//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/2.3) > 1.0//EN] > Compact HTML > -//W3C//DTD Compact HTML 1.0 Draft//EN > -//BBSW//DTD Compact HTML 2.0//EN > > The following DOCTYPEs MUST be considered as mobile-specific. > Transformations explicitly provided for by the relevant standards > are allowed (WAP-192 WBXML specifications 25.7.2001, WAP-236 WAE > specifications 19.12.2001, WAP-191 WML specifications 19.2.2000 > and predecessors, WAP-193 WMLScript specifications 25.10.2000). > > WML > -//WAPFORUM//DTD WML 1.0//EN > -//WAPFORUM//DTD WML 1.1//EN > -//WAPFORUM//DTD WML 1.2//EN > -//WAPFORUM//DTD WML 1.3//EN > -//WAPFORUM//DTD WML 2.0//EN > -//PHONE.COM//DTD WML 1.1//EN > -//OPENWAVE.COM//DTD WML 1.3//EN > > The range of MIME types is intended to cover typical mobile > browsing applications." > > Rationale: A normative document cannot leave full freedom to > implementors to select whichever subset of DOCTYPEs are > considered mobile-optimized or not. This helps ensure that > transformation proxies exhibit a standard behaviour. Working Group Resolution (LC-2052): The list of Internet content types associated with mobile content is to be found in Appendix C, referenced by the third bullet in 4.2.9 Proxy Decision to Transform. It contains all the requested content types, except "application/xhtml+xml" as this content type cannot be unambiguously associated with mobile content. The appendix is available at: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-Mobile-Content-Types ---- Your comment on A References: > 2) Sections A and D > > Since 2005, the Open Mobile Alliance has been working on a > Standard Transcoding Interface, and has published specifications > for it. The usage scenario is different: the STI is meant for > servers offering transformation services on demand via a Web > services interface, whereas the usage scenario of the CTG is > for proxies that intercept all HTTP flows between clients and > servers. However, there are several aspects that may overlap > -- in the requirements or the definition of the acceptable > limits during transcoding (e.g. content size). A reference > to this standard, and a discussion of the relation between > the CTG and the OMA specification is in order. Working Group Resolution (LC-2051): We have reviewed the specification and think there is insufficient overlap with this work. ----
Received on Tuesday, 6 October 2009 15:49:32 UTC