Cart
[Home] [By Thread] [By Date] [Recent Entries]
> > 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 eliminated. 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 > 1.1. That's looking forward a bit too much, we don't even know what XML 1.1 is really going to be! :) - Dave
|
