L2/09-266

Subject: UAX #44 Feedback
From: Asmus Freytag
Date: Jun 14, 2009

================== start chunk for PRI feedback document ===============

> > Date: Sun, 14 Jun 2009 00:41:20 -0700
> > From: Asmus Freytag <asmusf@ix.netcom.com>
> > To: Kenneth Whistler <kenw@sybase.com>
> > Subject: Re: Unicode 5.2: UAX #44 Updated (was: Re: Validation text)
...

> > -----
> > 
> > This annex describes the UCD and provides a guide to the various 
> > documentation files associated with it. **Although this description and 
> > guide is complete for the UCD itself, there are other portions of the 
> > Unicode Standard which must also be consulted to obtain the complete 
> > picture regarding Unicode character properties.** In particular, 
> > implementers should familiarize themselves with the formal definitions 
> > and conformance requirements for properties detailed in Section 3.5, 
> > "Properties" in [Unicode <../tr41/tr41-4.html#Unicode>] and **with 
> > further normative specifications regarding particular character 
> > properties** in Chapter 4, "Character Properties" in [Unicode 
> > <../tr41/tr41-4.html#Unicode>].
> > 
> > ==> Additional information about character properties and their use is 
> > contained in the Unicode Standard and its annexes.
> > 
> > rationale: the first half is incomprehensible, and in the second "obtain 
> > the complete picture" is a weird way to express this. The whole sentence 
> > really says nothing more than "additional info elsewhere". So, best to 
> > shorten.
> > 
> > ==> the material
> > 
> > rationale: shorter and eliding detail that's not that relevant. "go and 
> > read chapter 4" is enough of a message here, without needing to qualify 
> > what the reader will find there. Nobody who hasn't first read chapter 4 
> > can really sort what "further normative specifications regarding 
> > particular character properties" will offer him or her, so this is a 
> > classic case of "TMI" ;-)
> > 
> > ------
================== end chunk for PRI feedback document ===============


================== start chunk to add to UAX #44 feedback ======

> > Date: Mon, 15 Jun 2009 15:20:25 -0700
> > From: Asmus Freytag <asmusf@ix.netcom.com>
> > To: Kenneth Whistler <kenw@sybase.com>
> > Subject: Re: Unicode 5.2: UAX #44 Updated (was: Re: Validation text)

[[ Re claim in Section 5.9, "Validation" that "the regular expressions
are always backwards compatible for previous versions of the UCD." ]]

>> >> 2) is this even true? There's nothing that prevents a different 
>> >> formulation of a regular expression that is substantially different on 
>> >> the surface. I think all that can be gurarnteed is what is guaranteed in 
>> >> the stability - there is not, and should not, be a guarantee about the 
>> >> way the "expressions" are written.
>> >>     
> >
> > Yabbut... The point here is not that the regular expressions
> > have any kind of immutability. Rather, the point is that we
> > don't engage in removal of property aliases or value aliases or make bizarro
> > property changes that would trash existing regular expressions
> > when we go from UCD Version N to Version N+1.
> >
> > That implies that if you have a regular
> > expression that works for validation of a property for
> > UCD Version N, it should be backwards compatible for
> > Version N-1, as well.
> >
> >   
Why not say what you mean?

"Regular expressions for Version N+1 will continue to accept all valid 
values for versions 1..N"

However, is that actually true?

If a particularly gnarly value for some property X is actually retired 
(say, one string value that happens to have an oddball character in it, 
or, hypothetical example, the value 10E+3 replaced by 1,000 in later 
versions to obviate the need to use exponents) will all future versions 
of the expression still accept it?

> > And note that here we are talking about regular expressions
> > for *validating* properties -- not necessarily regular expressions
> > using properties in general. For those, we should maintain
> > syntactic validity, but it is entirely possible that a given
> > regular expression that defines a non-null set in UCD
> > Version N could end up defining a null set in UCD Version N+1,
> > for example.
> >   

A./

================= end chunk to add to UAX #44 feedback =============