W3C home > Mailing lists > Public > www-i18n-comments@w3.org > October 2004

Your comments on Character Model Fundamentals [LC071, LC073, LC077, LC078]

From: Richard Ishida <ishida@w3.org>
Date: Thu, 7 Oct 2004 10:22:58 +0100
To: <bjoern@hoehrmann.de>
Cc: <www-i18n-comments@w3.org>
Message-Id: <20041007092257.16DF04F2F9@homer.w3.org>

Dear Björn,

Many thanks for your comments on the 3rd Last Call version of the Character Model for the World Wide Web 1.0: Fundamentals [1].  We appreciate the interest you have taken in this specification.

You can see the comments you submitted, grouped together, at http://www.w3.org/International/Group/2004/charmod1-lc/SortByOriginator.html#LC070
(You can jump to a specific comment in the table by adding its ID to the end of the URI.)

The following comment was accepted and edits were made along the lines you suggested. If you wish to say that you are satisfied or raise an issue, please reply to us within the next two weeks at mailto:www-i18n-comments@w3.org and copy w3c-i18n-ig@w3.org.

PLEASE REVIEW the decisions for the following additional comments and reply to us within the next two weeks at mailto:www-i18n-comments@w3.org (copying w3c-i18n-ig@w3.org) to say whether you are satisfied with the decision taken. 
        LC071, LC077, LC078

Information relating to these comments is included below.

These comments relate to the editor's version at http://www.w3.org/International/Group/charmod-edit/charmod1.html

Best regards,
Richard Ishida, for the I18N WG


Decision: Rejected You raise a valid point mentioning that although the DOM specifies to use UTF-16, not all implementations follow this. When the DOM was created, we were apparently more worried about inter-language compatibility than necessary, but not only that, we were also worried about intra-language compatibility. Today, most major languages have their model for how to deal with Unicode; when DOM1 was created, that wasn't the case. In particular, people were pointing to Corba, which does things like character encoding negotiation, which would not at all have been suited for DOM.

Going back to the text of C016: "When designing a new protocol, format or API, specifications SHOULD require a unique character encoding.", we would like to point out that it doesn't require APIs across languages to use the same encoding. We would also like to point out that e.g. the DOM1 spec is very careful to avoid using the word API for DOM itself (see e.g. http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/). In addition, we would like to point out that C017, "When basing a protocol, format, or API on a protocol, format, or API that already has rules for character encoding, specifications SHOULD use rather than change these rules." would provide strong justification for a spec like DOM that would want to leave the question of character encoding to each language binding.

So therefore, we don't think that the current wording causes any problems.

Decision: Rejected We have rejected this request because we feel that the uppercase string U+HHHH is inferior in appearance compared to the string U+hhhh and that the latter is more common when giving an example of Unicode Scalar Values. In particular, the Unicode standard, v4.0, on page xxxiv ("Notational Conventions") introduces the USV notation with lowercase ('x' and 'y' in this case).

Decision: Rejected We think that it is a somewhat rare edge case that doesn't warrant additional complication in the conformance section. In the general case, every specification should try to conform to the character model, whether it also conforms to some other specification or not. In many cases, conformance to the character model also will come naturally for a derived spec.

[1] The version of CharMod you commented on: 
[2] Latest editor's version (still being edited): 
[3] Last Call comments table, sorted by ID: 
Received on Thursday, 7 October 2004 09:22:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:20:15 UTC