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

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

LC074 okay,
LC081 okay,
LC082 okay,

I am not satisfied wrt to LC083, you note

[...]
  We have replaced 'mandate' with 'require' thoughout the document.
  'Require' is well defined in RFC 2119. Please note that we are not
  using upper-case in this case, because we are using 'require'
  descriptively, rather than normatively, in our spec.
[...]

If you do not use the terms as defined in RFC 2119 the term is not well-
defined. The term is further used to spell out normative requirements
(e.g. in C016) lacking a definition it is not clear what the requirement
actually means.

LC084 is not marked as accepted but rather as "noted" without changes in
<http://www.w3.org/2004/02/charmod1-lastcall>, it is thus not clear to
me what your actual response to the issue is, I consider this comment
not addressed. I'll need to know your response to this issue in order to
consider whether your response to LC085 satisfies me.

LC086, I can't tell whether "We reworked many abbreviations" is
satisfactory, I would need to look at the text, but it should be
okay to assume it is.

LC089, okay.

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

That is the opposite of what I've asked for! You would also need to
remove all instances of the term (and similar terms if any) in the
document for that to make sense, if you do that I could live with
the resolution.

>LC075

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

If there are cases where this would not work, please change the example
in the specification to actually make sense. You have failed to cite
reasons for keeping the SHOULD NOT rather than replacing it with e.g.
RECOMMENDED, so this does not satisfy me.

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

With "good" wording it is easy to understand, with "poor" wording it
is easy to misunderstand. Lack of interoperability is often caused by
misunderstandings, I thus do not buy it at all that this is not an
interoperability issue. If this is not an interoperability issue and
not meant to limit behavior which has potential for causing harm, the
document would not conform to RFC 2119 regardless of whether you use
SHOULD NOT or MUST NOT. Further, you can easily say that spec must not
use them in normative parts and should not use them in informative
parts, so this does not satisfy me.

>LC080

I'll need to look at this more closely.

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

I can live with that.

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

I can live with that.

Received on Wednesday, 27 October 2004 18:34:31 UTC