[jdom-interest] Namespace declaration "gets lost"

[Bradley S. Huffman]

Laurent Bihanic writes:

> 
> I had a quick look at SAXHandler code and it seems the bug lay in the use of 
> List.removeAll(Collection) in endElement (see line 
> availableNamespaces.removeAll(addl);).
> 
> IMHO, the scenario is the following: After the second declaration, your 
> namespace appears twice in the list of available namespaces (good) and also a
> s 
> an additional namespace for the current element (good too). When processing 
> the endElement event, SAXHandler removes all the additional namespaces of the
>  
> "ended" element from the list of available namespaces using List.removeAll. 
> This method removes *all* occurrences of the objects contained in the 
> collection passed as argument. Hence the two namespace declaration are remove
> d 
> (bad!).

Sure enough, because Namespace.equals() considers two namespaces equal if
there uri's are equal (regardless of prefix).

> Later on, when encountering the "returnvalue" attribute, SAXHandler fails to 
> resolve the namespace and uses NO_NAMESPACE instead (bad too!) (see method 
> getNamespace).
> 
> Questions :
> 1. Why does endElement() remove the additional namespaces from the list of 
> available namespaces ? SAX dedicates this task to endPrefixMapping and 
> SAXHandler.endPrefixMapping does it perfectly.

Looks like it been in since b6 or so. Looking deeper, why do we even worry
about keeping track of in-scope namespaces? Looks like the only time
SAXHandler's getNamescape is called is when a attribute has a prefix. Why
not just use element.getNamespace(String) to get the namespace and handle
the housekeeping? For most cases it should match the elements namespace.
Tried this last night and it seemed to shave off a few cycles for test cases
with a high number of attributes (probably from getting rid of the iterator
creation).

Also looking at Element.getNamespace(String) shouldn't it also return 
Namespace.XML_NAMESPACE for the prefix 'xml'?

Brad