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

* Martin Duerst wrote:
> >[LC083]

>The "descriptively rather than normatively" may not be very clear.
>[...]

I consider both "SHOULD" and "MUST" "requirements" with the difference
that these denote different requirement levels, it is thus not clear
whether e.g. for "Specifications MUST require foo" "bar SHOULD foo" the
requirement has been met. I want language in the document that clearly
allows or prohibes that. I am less concerned about how that is achieved.

> >[LC084]
>
>The response is given in the table, and should also have been
>sent to you:

My problem is that the mail claimed that "edits were made along the
lines you suggested" even though the table states that no edits have
been made. So, are you saying I should assume that the text in the
table is more accurate?

>In internationalization, it is always dangerous to assume that
>things work just because you don't know any exceptions.

In computing, it is always dangerous to assume that things don't work
even though you do not know any exceptions, it might significantly
complicate the interface and implementation. For the uppercase example
taking a string would require to resolve whether

  uppercase("o\x{308}")

triggers an error condition, or would return "Ö", "O\x{308}", "O", etc.
and users of the routine would need to be aware that certain operations
would no longer be possible (like modifying the string without modifying
its length); you also no longer have compile time type checking to
prevent certain kinds of errors, need more testing, longer documentation
and so on. So there is certainly a cost here.

>It makes sense, it shows a specific example where the return type
>needs to be a string.

But not the argument and whether there is actually such a need is
debatable, I know of quite a number of APIs where 'Ä' == uc 'ä' but
'ß' == uc 'ß', so there are quite a number of people who disagree
that this is an absolute requirement (it's also useful because
lc('ß') == lc(uc('ß')) holds true). Charmod does not contain a
requirement that specifications must define such transliteration
operations so that 'SS' == uc 'ß' either.

>Do you mean changing "Specifications of APIs SHOULD NOT specify single 
>characters or single units of encoding as argument or return types."
>to something like "We RECOMMEND that specifications of APIs do not
>specify strings (rather than single characters or single units of encoding)
>as argument or return types."?

I think text such as

  Specifications of APIs SHOULD prefer strings over characters as
  arguments and return types.

would satisfy me.

>I personally think that things like upper-case functions that do
>not change string length should be a way of the past. The Web
>is flexible and doesn't and shouldn't depend on fixed string lengths.

Are there any relevant CSS implementations that render

  <p style="text-transform: uppercase">ß</p>
  <p style="text-transform:      none">SS</p>

the same? Are they required to in CSS 2.1/3.0?

Received on Thursday, 28 October 2004 15:14:07 UTC