RE: New Corrigendum to The Unicode Standard

From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Wed Aug 22 2007 - 01:33:03 CDT

  • Next message: Jukka K. Korpela: "Apostrophes at www.unicode.org"

    > -----Message d'origine-----
    > De : Asmus Freytag [mailto:asmusf@ix.netcom.com]
    > Envoyé : mercredi 22 août 2007 07:48
    > À : verdy_p@wanadoo.fr
    > Cc : unicode@unicode.org
    > Objet : Re: New Corrigendum to The Unicode Standard
    >
    > On 8/21/2007 8:26 PM, Philippe Verdy wrote:
    > > I was not making a formal proposal, just proposing something to help
    > > referring to the version with corrigendums applied. OK the letter "d" is
    > > used for drafts, but drafts don't need to be referred to for long term,
    > > that's not the case for compliant implementations.
    > >
    > You either propose or you don't propose. This isn't a formal reply by
    > the way, just my personal frustration with the way you cloud every issue
    > with fanciful 'suggestions' that are just too often based on an
    > incomplete understanding of how the standard actually works.

    It not so much fancy. But the long sentence needed to refer to versions with
    corrigendums and the ambiguity when no such extension is made and one refers
    only to Unicode "5.0.0" or "4.0.1" or "4.0.1" or "3.2.0" or "3.1.1" or
    "3.0.0" without saying if corrigenda are or are not included.

    AndI did not imply that these were applied in sequence (I said that in the
    branches out of the trunk, they may be mutually incompatible, meaning that
    they create in fact as many branches as there are corrigendums applied.)

    In fact I have included too many alternatives, because corrigendas were
    integrated in the trunk, so regarding Unicode 5.0.0 only corrigendum 6 is
    relevant (because all past corrigendums are already part of it and inherited
    in future releases, I hope; if not a new corrigendum would need to be
    created to revert the change once again).

    > Corrigenda, by their very nature, never allow an implementation to
    > comply with both the base version of the standard and the same version
    > with a corrigendum. Corrigenda are issued only where defects have been
    > found with *normative* information, and where it can be expected that
    > implementers would want to patch an implementation to correct just those
    > defects and not wait for the next version of the standard.
    >
    > Granted, as you point out below, if you don't support a feature subject
    > to a corrigendum, then that corrigendum has no material effect on your
    > implementation, but that's an obvious corollary.

    I am more concerned by the stability and assumption of upward compatibility
    that this absence of precision will create. For me, it's not enough to say
    that an application conforms to Unicode 5.0.0 as it does not say if C.6 is
    applied or not (such absence of precision is quite common, simply because
    applications were created before the corrigenda were published; so it would
    be useful to include a precision of the corrigendum level (the TUS 5.0.0
    book is at corrigendum level 5 as it includes all corrigenda of past
    releases up to Corrigendum 5); In my notation it would be 5.0.0c5 without
    correction, and currently 5.0.0c6 if fully corrected.

    The BiDi algorithm is not optional in Unicode 5.0.0, it is normative and
    full part of it.
    But because the conformance rules include this sentence :

            " In a reference or claim of conformance to a particular version of
    the Unicode Standard, if the citation does not specifically mention a
    corrigendum, then the corrigendum does not apply for that reference or
    conformance claim."

    This means that the implementation of any corrigendum after a release should
    not be implied by any application refering only to a single version. This
    means that an application that claims conformance to "Unicode 5.0.0" only is
    not upward compatible with past releases, because it does not conform to
    them.



    This archive was generated by hypermail 2.1.5 : Wed Aug 22 2007 - 01:35:27 CDT