RE: Comments on "W3C mobileOK Basic Tests 1.0" WD from i18n core WG

Now I understand why Felix thought the review was over, but I don't
understand why I thought we hadn't yet reached 6 March ;-) Apologies.

Since Felix is very busy this week, I will send the comments again,
individually, as per our usual process, and to the public mailing list cited
in the document status. We ask that you accept them as LC comments. 

Thanks,
RI

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

> -----Original Message-----
> From: member-i18n-core-request@w3.org 
> [mailto:member-i18n-core-request@w3.org] On Behalf Of Richard Ishida
> Sent: 20 March 2007 10:16
> To: 'Felix Sasaki'; member-bpwg@w3.org
> Cc: member-i18n-core@w3.org
> Subject: RE: Comments on "W3C mobileOK Basic Tests 1.0" WD 
> from i18n core WG
> 
> 
> I'm not sure why Felix thought this LC was over.  Please do 
> not respond to this mail for the time being.  I'd like to 
> discuss with Felix putting these comments through the normal 
> process we use for making LC comments.
> 
> RI
> 
> ============
> 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/
>  
>  
> 
> > -----Original Message-----
> > From: member-i18n-core-request@w3.org 
> > [mailto:member-i18n-core-request@w3.org] On Behalf Of Felix Sasaki
> > Sent: 20 March 2007 06:22
> > To: member-bpwg@w3.org
> > Cc: member-i18n-core@w3.org
> > Subject: Comments on "W3C mobileOK Basic Tests 1.0" WD from 
> i18n core 
> > WG
> > 
> > 
> > Hello MWBP WG,
> > 
> > These are comments on
> > http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070130/
> > from the
> > i18n core WG, including one private comment from me (comment 6). I 
> > apologize for the delay in sending the comments. Due to the 
> delay I'm 
> > sending them not to the public comments list 
> > http://lists.w3.org/Archives/Public/public-bpwg-comments/ , but to 
> > your member list. Would it still be possible for you to 
> accept them as 
> > LC comments?
> > 
> > ----------------
> > COMMENT 1
> > ----------------
> > About "3.3 CHARACTER_ENCODING_SUPPORT and 
> CHARACTER_ENCODING_USE", see 
> > expect below:
> > 
> > [[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"/>)]]
> > 
> > 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.
> > 
> > 
> > ----------------
> > COMMENT 2
> > ----------------
> > About "3.3 CHARACTER_ENCODING_SUPPORT and 
> > CHARACTER_ENCODING_USE", see 
> > expect below:
> > 
> > [[If character encoding is not explicitly specified in at 
> > least one of 
> > these ways, FAIL]]
> > 
> > Given the goals of this test, shouldn't this say "If the 
> > UTF-8 character 
> > encoding is not explicitly specified..." ?
> > 
> > 
> > ----------------
> > COMMENT 3
> > ----------------
> > About "3.3 CHARACTER_ENCODING_SUPPORT and 
> > CHARACTER_ENCODING_USE", see 
> > expect below:
> > 
> > [[If character encoding is specified in more than one way, 
> > and not all 
> > values are the same, FAIL]]
> > 
> > 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?
> > 
> > 
> > ----------------
> > COMMENT 4
> > ----------------
> > About "3.3 CHARACTER_ENCODING_SUPPORT and 
> > CHARACTER_ENCODING_USE", see 
> > expect below:
> > 
> > [[If any character encoding specified is not "UTF-8", FAIL
> > 
> > If the document is not valid UTF-8, FAIL]]
> > 
> > How are people to test this?
> > 
> > 
> > ----------------
> > COMMENT 5
> > ----------------
> > About "3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE"
> > It would be great if you could add a reference to the Q/A "FAQ: 
> > Multilingual Forms", see 
> > http://www.w3.org/International/questions/qa-forms-utf-8 . It 
> > contains 
> > among others a Perl regular expression testing for UTF-8.
> > 
> > 
> > ----------------
> > COMMENT 6
> > ----------------
> > A personal comment , not endorsed by the i18n core WG, about "3.3 
> > CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE"
> > 
> > [[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]]
> > 
> > Should a @charset rule in an  included CSS stylesheet be taken into 
> > account? I.e., should there also be a warning if such a rule 
> > specifies 
> > an encoding different that UTF-8?
> > 
> > Regards, Felix
> > 
> > 
> 
> -- 
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.446 / Virus Database: 268.18.14/727 - Release 
> Date: 19/03/2007
> 11:49
>  
> 
> 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.15/728 - Release Date: 20/03/2007
08:07

Received on Wednesday, 21 March 2007 15:28:15 UTC