Re: mobileOK comments

hi Richard,

Just a question: is everything between each [RI] one comment? So are
these 4 comments? What about the text after "[RI] How are people to test
this?"?

Richard Ishida wrote:
> 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.

agree with the comment.

> 
> 
> 
> 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..." ?
> 

agree with the comment.

> 
> 
> 
> 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?
> 
> 

My impression is that there are such situation,s but that they would not
be "mobileOK". Maybe it should mabe more explicit what the intend of
this rule is.

> 
> 
> 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?

why could they not use the test described at
http://www.w3.org/International/questions/qa-forms-utf-8 (perl regex)?

Regards, Felix.

> 
> 
> 
> 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/
>  
>

Received on Thursday, 8 February 2007 12:43:19 UTC