Your comments on Character Model Fundamentals [LC070, LC074, LC075, LC079, LC080, LC081, LC082, LC083, LC084, LC085, LC086, LC087, LC088, LC089]

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 comments were noted or 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.
        LC074, LC081, LC082, LC083, LC084, LC086, LC089


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. 
        LC070, LC075, LC079, LC080, LC085, LC087, LC088

Information relating to these comments is included below. You will receive notification of decisions on remaining comments at a later date.

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




DECISIONS REQUIRING A RESPONSE
==============================

LC070
http://www.w3.org/International/Group/2004/charmod1-lc/SortByOriginator.html#LC070
Decision: Partially accepted We removed 'legacy encoding' as a formally defined term from CharMod Fundamentals. We will revisit this for CharMod Normalization.



LC075
http://www.w3.org/International/Group/2004/charmod1-lc/SortByOriginator.html#LC075
Decision: Partially Accepted Changed C056 from "Specifications of APIs SHOULD NOT specify single character or single encoding-unit arguments." to "Specifications of APIs SHOULD NOT specify single characters or single units of encoding as argument or return types."

We agree that return types should also be mentioned, and that 'encoding-unit' has to be replaced by 'units of encoding'.

However, we disagree with your counterexample. The fact that an 'uppercase' function can take a single character, even an sz, as an argument in some cases doesn't prove that there are no cases where it will not become necessary to hand over more than one character at a time to a function for proper uppercasing. Therefore, in general, both the arguments and the return type should be strings.



LC079
http://www.w3.org/International/Group/2004/charmod1-lc/SortByOriginator.html#LC079
Decision: Rejected We have decided to reject this comment because there may for example on occasion be historic reasons to mention these terms. Also, we would like to point out that this is just an issue of wording, not of interoperability, so there is no reason to be absolutely strict.



LC080
http://www.w3.org/International/Group/2004/charmod1-lc/SortByOriginator.html#LC080
Decision: Partially accepted We revised the explanations of byte and other strings to clarify their utility.

We added this whole section (the diff. kinds of string) in response to a comment on a previous version of Charmod. To the issue of whether or not distinguishing the different types of strings is a good idea, as we indicate in the first paragraph of section 6.1, these are existing notions. We feel it is important to formalize their definitions so we can label and describe appropriate and inappropriate practices. We added the example to the section on byte strings, to emphasize a bad practice.



LC085
http://www.w3.org/International/Group/2004/charmod1-lc/SortByOriginator.html#LC085
Decision: Rejected We have decided to reject this comment because, as you may be able to deduce from our response to your issue LC084, we do not think that CSS 2.1 violates C028. The specific example you give is therefore not applicable. Even if we accepted your point re. C028, we would like to note that it would still be possible to produce CSS that conformed to the character model, for example by always using the @charset rule.

The question of what should be done with some implementations or content to try to conform to the character model even if the specification they use doesn't conform to the character model doesn't have an easy answer in general (as shown above, sometimes this may be easy; at other times, it may not be easy). Making any general statements about such cases therefore doesn't look like it will help at all.



LC087
http://www.w3.org/International/Group/2004/charmod1-lc/SortByOriginator.html#LC087
Decision: Rejected There are links to conformance criteria from existing mailnotes and the like, and these links depend on the numbers used. For this reason, though we would also prefer to maintain a sequential order, we do not want to renumber the criteria.



LC088
http://www.w3.org/International/Group/2004/charmod1-lc/SortByOriginator.html#LC088
Decision: Partially accepted We have produced a simple list of the conformance requirements in Appendix D. We may make this more sophisticated in future versions of the document.




USEFUL LINKS
==============
[1] The version of CharMod you commented on: 
http://www.w3.org/TR/2004/WD-charmod-20040225/
[2] Latest editor's version (still being edited): 
http://www.w3.org/International/Group/charmod-edit/charmod1.html
[3] Last Call comments table, sorted by ID: 
http://www.w3.org/International/Group/2004/charmod1-lc/

Received on Wednesday, 6 October 2004 11:00:05 UTC