Re: ISO 10646 compliance and EU law

From: Antoine Leca (
Date: Wed Jan 05 2005 - 05:09:43 CST

  • Next message: Philipp Reichmuth: "Re: ISO 10646 compliance and EU law"

    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

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


    This archive was generated by hypermail 2.1.5 : Wed Jan 05 2005 - 05:12:00 CST