Lists Home |
Date Index |
> > Seems to me that it's time to put this release out! Unless
> > someone reports a significant bug in the next few days,
> > I soon be finalizing this release, including the javadoc
> > updates that are now in CVS.
To clarify: that's the "sax2r2" branch in CVS, not the main
tree (which isn't yet synced up with the doc updates, and
which includes "SAX2 extensions 1.1" updates). If anyone
wants to see all those changes, use the "sax2r2" branch.
(There's a "viewcvs" option to do that, and CVS also has
ways to specify branches to CVS commands like "get".)
> It might be worth noting the current discussion on xml-dev (or content
> thereof) regarding surrogate pairs, as SAX relies on the Java char and
> String constructs throughout.
I'll catch up on that, but my advice on that point is unlikely to
change. As I've pointed out in an upcoming O'Reilly book
(you might have heard about it, called "SAX2" ... ;-) surrogate
pairs aren't the only place that a Java "char" doesn't match
a "character" ... there are also composed characters to
worry about, even in the absence of surrogate pairs.
Point is that anyone working at the "character" level MUST
NOT ASSUME that such characters consist only of a single
Java "char" value. And that'd be true even if "char" were
to make an incompatible change, and acquire a few extra
bits at the left so that surrogates could in some cases be
Developers just have to deal with the fact that a single "character"
is never going to be a single "char", and that's no different in
ANY programming environment.
> I'd qualify this as a minor documentation
> fix, as it only matters should SAX2 processors have to deal with XML
That's looking forward a bit too much, we don't even know
what XML 1.1 is really going to be! :)