[Sax-devel] Re: [Sax-users] Misleading sentence
Brought to you by:
dmegginson
From: David B. <da...@pa...> - 2002-05-27 18:22:01
|
> What parsers exist that provide empty strings for the local name of > non-namespace qualified elements? I don't have those results handy, but I recall that when I tested, Crimson certainly behaved that way. (That was in a version about six months before that extremely belated JDK 1.4 release, which was at that time expected within two months.) I reported one of their examples not working because of this, and provided a patch to make that example work on all SAX parsers (including Crimson). And while I wish I remembered the other parsers that behaved that way, I don't. Sorry. The behavior wasn't universal when I checked, but it wasn't uncommon either. Testing today could well produce different results. >> This is a good example of why allowing implementation variability causes >> problems > > ... everything else > I've ever seen or heard indicated to me that local names were provide > for non-namespace qualified elements, given the default settings of the > namespace features. Could be ... I am convinced that making this particular point not be an implementation variability issue would be a good thing from the perspective of application portability. > I think the number of places you're having to "correct" the spec to > justify the behavior you claim indicates a real problem. No parts of the spec have changed ... ContentHandler.startElement() has said "if one is specified, both must be" since David Megginson wrote it. Yes, I checked the CVS history. You're pointing at inconsistent information from a tutorial. > Once the Memorial Day long weekend is over, we should poll some more > implementers, and see what they've been thinking the correct behavior is. Well, the "desirable" behavior is almost certainly going to be providing localName in all cases. I could see making that be "correct" in SAX 2.1, but given that I've seen "written to spec" SAX 2.0 implementations that don't behave that way, it shouldn't change before then. In any case, I do think it's clear that parsers providing that "desirable" behavior are fully conformant. The cost is to applications code, which may be parser-dependent unless it uses qName in such cases. - Dave |