mobileOK comments

Here are some comments I would make on the mobileOK Basic Tests 1.0
http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070130/


3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE

The DDC is defined to support only UTF-8 encoding, and hence this test fails if a resource cannot be delivered in UTF-8. The test does not require that resource always be encoded in UTF-8; the test merely checks that the resource is available in UTF-8 encoding, if requested. Resources may be delivered to devices in other encodings where appropriate. This test verifies that a DDC-like device which only accepts UTF-8 encoding may access the resource in UTF-8 encoding.

This requirement, UTF-8 support, has been extensively debated and the group solicits feedback on it.

Determine the character encoding specified by the following, if present:

    *  Content-Type header (e.g. "application/xhtml+xml;charset=UTF-8")
    *  XML declaration (e.g. "<?xml encoding="UTF-8"?>")
    *  meta element that is the first child of the document's head element, and whose http-equiv attribute is "Content-Type", and whose content attribute specifies a character encoding as above (e.g. "<meta http-equiv="Content-Type" content="application/xhtml+xml;charset=UTF-8"/>)

[RI]  Since this test is testing for UTF-8 support, it should be made clearer that the reason 'e.g.' is used rather than 'i.e.' has to do with the other parts of the construct, rather than the encoding declaration itself.



If character encoding is not explicitly specified in at least one of these ways, FAIL

[RI] Given the goals of this test, shouldn't this say "If the UTF-8 character encoding is not explicitly specified..." ?




If character encoding is specified in more than one way, and not all values are the same, FAIL

[RI]  I'm not personally familiar with transcoding scenarios, but I've heard people often quoting them as justification for using the HTTP header to declare encodings and for the HTTP declaration to have higher precedence in HTML than the in-document declarations.  As I understand it, the rationale is that a transcoding server can change the encoding of the document as it passes through, but doesn't change in the internal encoding declaraction.  Since HTTP declarations beat in-document declarations, this is supposed to be OK.  I've also heard that this kind of thing happens particularly when serving documents to mobile devices.  If this is true, then I guess there must be occasions when it is permissible for the HTTP header declaration to be different from the other two?




If any character encoding specified is not "UTF-8", FAIL

If the document is not valid UTF-8, FAIL

[RI] How are people to test this?



For each external resource as defined in 2.3.5 Included Resources:

Request the URI indicated by the href attribute

If the HTTP response Content-Type header value specifies an Internet media type starting with "text/" but does not specify UTF-8 encoding (e.g. "text/css" only instead of "text/css;charset=UTF-8"), warn

PASS

============
Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)
 
http://www.w3.org/People/Ishida/
http://www.w3.org/International/
http://people.w3.org/rishida/blog/
http://www.flickr.com/photos/ishida/
 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.29/673 - Release Date: 06/02/2007 17:52

Received on Wednesday, 7 February 2007 12:25:14 UTC