RE: [Sax-devel] SAX and xmlns attributes
Brought to you by:
dmegginson
From: Paul R B. <pr...@fi...> - 2002-05-17 16:17:21
|
> Any XML Parser that conforms to the DOM or the Namespace specs does or > should assign the namespace to the xmlns attributes. > The information is not exposed to SAX users only because SAX disallows > it, and not because parsers can't do that. The point is not that parsers can't, the point is that parsers *don't*. For example, Xerces doesn't. > > (2) Nothing needs to change, as any SAX-consuming DOM-builder already > > includes an appropriate filter to account for the various > > idiosyncrasies of DOM's namespace handling as of DOM2. > Agree. And as you say nothing needs to be changed here (the filter will > be no-op). And, therefore, SAX need not change. DOM builders are still going to be responsible for translating (blank,xmlns:.*,xmlns:.*) into the current flavor expected by a DOM implementation. It is much simpler to ensure that DOM builders interpret SAX-compliant events in a DOM-compliant way than to require that lots of existing SAX-compliant code interprets SAX-compliant events in a DOM-compliant way. > I thought about this use case. I still don't see why a programmer would > write an "if" statement checking for BOTH blank URI and qname, instead > of just checking if qname starts with "xmlns:". I agree that this is how > code could be written.. but I am not sure if this is a "real life" > scenario. The blank URI filter is actually quite a bit faster than the multi-character string comparisons necessary to check the namespace first (which overlaps for significant portion with the xml namespace and the xslt namespace) and then the prefix on the qname, since java.lang.String has the length as private instance variable. No one uses SAX for convenience; people use it for efficiency. If you've worked in a leadership role any large software development project, you know that you don't just go around changing APIs, especially not APIs that are in wide and general use. -- Paul |