From: Antoine Leca (Antoine10646@leca-marti.org)
Date: Wed Jan 05 2005 - 05:09:43 CST
On Tuesday, January 4th, 2005 22:20Z, Kenneth Whistler explained:
> Antoine continued:
>
>> From what I read now, it seems that a "claim of conformance" can be
>> transitive. I would not have think of it, but if this the law,
>> let's conform to it.
>
> Well, nor am I a lawyer. But what I would say is that that is
> the clear intent of both of the standardization committees in
> working on and publishing their standards.
I have clear the intent, and indeed it is important to achieve it, and yes I
agree you guys (both sides) are working carefully in this way.
I was only pointing out that my first reading of 10646 did not allow me to
understand that you can claim conformance without actually doing something.
As a software writer I had very clear that working (correctly ;-)) with
UTF-16 allows me to interoperate with 10646 and to eventually apply to 10646
conformance without even having to worry about the inner intrincates. I
thank you to remind this publicly, since you are right thinking I could have
mislead uninformed people thinking otherwise.
OTOH, as a professional that sometimes have to deal with legal clauses (for
example when dealing with EU supranational organisations) I worry about the
further steps I have to do to actually comply with the laws. And as a buyer
I know very well the difference between a product "advertised as conforming"
and a product "conforming", when it comes to actually ask the vendor about a
defect of conformance: only the latter case allow you to ask for a refund on
legal bases! In the former case it is purely matter of commercial
relationships (translated to normal speak, "I will correct your bug if I got
the feeling you'll buy me more in the future").
>> Just using UTF-16 as character set, and we are registered as
>> conformant to ISO/IEC 10646. Nice, after all.
>
> Well, you would need to be using UTF-16 *correctly*. :-)
I never considered using UTF-16 incorrectly :^).
In fact, the real point here is that what I (or any software writer for that
matter) think is "correctly" might be *different* form your point of view
:-D. I agree you are doing an useful job toward making it clearer and
clearer, so it does not intent to be a critic in any way, just a matter of
facts.
> And then if you need to cross all your i's (U+0268) and dot all
> your t's (U+1E6D), you can get your corporate lawyer to
> file a little paper someplace that says, by the way, our
> company's product, Whirleygigatron 5.0, is conformant with
> both the Unicode Standard, Version 4.0, and ISO/IEC 10646:2003
> (or whatever).
The big difference between Sybase (no intended pun, I just take an obvious
example here) and a potential small company making software, is that you
have a (dedicated) "corporate lawyer" where I am both the writer and the
used-to-be-the lawyer (and all the "documentation, testing, marketing, or
legal departments" as well ;-)). Or more exactly, that I cannot convince the
boss I need to consult with her personnal lawyer (too busy with accounting
matters actually) about software conformance.
So I would take your point as it could be a good idea to file this claim
somewhere. Of course, depending of the size of the company, the way to file
this could be different: a big company which cares about its assets will
record this in a dedicated place (and will have a QA process to assure
itself it is actually correct); a smaller one won't, and I guess a mention
in the README file will suffice.
> If you try to write a 10646 application without reference to
> the Unicode Standard, you'll be pretty limited in what you can
> do, because 10646 (deliberately) says very, very little about
> the actual semantics of any of the characters encoded in
> the standard.
Of course, because the field of application of 10646 is MUCH more narrow
than the one of Unicode. As you rightly said, 10646 does not care about the
actual use of U+094D (well, not entirely true, it relates to implementation
levels), much less about the differences between Hindi and Sanskrit at the
respect. As you noted, you even did not need to worry about that if writing
a CTE convertor, so it is fine this way. OTOH it is clear that writing say a
rendering engine for Nagari script should have more clues this about (in
fact, it should have clues _beyond_ Unicode as well.)
Antoine
This archive was generated by hypermail 2.1.5 : Wed Jan 05 2005 - 05:12:00 CST