[jdom-interest] builders not preserving namespace attributes in xsl files

[Brett McLaughlin]

Ed Morehouse wrote:
> 
> Thank you.  If you don't mind, i would be grateful if you would send me a brief
> description of the cause of the bug once you've fixed it.  I spent a good hour
> wading through DOMBuilder.buildTree(), which seemed to me to be the most likely
> locus of such a thing, but i came away feeling unenlightened, and began to
> suspect that the problem might be somewhere in xerces (especially when i saw
> that SAXBuilder did the same thing).  I wouldn't mind getting my hands dirty
> with jdom, and i imagine that you prefer patches to bug reports, so any
> description you would care to offer might help us both.

No problem. The error is tied to the fact that for each Element in JDOM,
that Element has a Namespace object tied to it (even if the Namespace is
the NO_NAMESPACE object). However, there is no means of adding namespace
declarations for namespaces that are not intrinsic to the Element. So in
your example, the XSL namespace is picked up, because it is tied to the
element called stylesheet, in the XSL namespace. However, since the foo
and JavaXML prefixed namespaces are never tied to a specific Element,
they are never dealt with. In essence, there is no
addNamespaceDeclaration() method available for objects. 

What you see in SAXBuilder and DOMBuilder is that the namespace
declarations /are/ being reported correctly (thus, there is no bug with
Xerces), but they are essentially ignored if they aren't on an Element.
For example, in SAXBuilder, we actually turn off namespace processing,
and thus all namespaces are reported as attributes (we are more
efficient this way); we even capture each Namespace in the characters()
callback:

            if (attName.startsWith("xmlns")) {
                int attributeSplit;
                String prefix = "";
                String uri = atts.getValue(i);
                Namespace ns = null;
                if ((attributeSplit = attName.indexOf(":")) != -1) {
                    prefix = attName.substring(attributeSplit + 1);
                }

                // Add namespace to list
                ns = Namespace.getNamespace(prefix, uri);
                elementDefinitions.add(ns);
                namespaces.add(ns);
            }
        }

        // Add this element and its definitions to the global mapping
map
        namespaceDefinitions.put(rawName, elementDefinitions);

The problem is that other than when the Element is created:

        Element element =
            new Element(name, prefix, getNamespaceURI(prefix));

there is no means of adding these other Namespaces to the element's
declaration.

The fix, essentially, would be to add (back - we used to have this)
something like:

addNamespaceDeclaration(Namespace ns)

onto the Element. We could then add these additional declarations to the
Element, and it would be easy enough to print them out at the
XMLOutputter level. Each Element, then, would presumably have a HashMap
of declarations on it (other than the one that is intrinsic to it).

You can take a look at this if you like - I'm bogged down, so the more
help the merrier.

> 
> Sorry again for the sloppy bug reporting. I promise i will be more precise in
> the future.

Actually, it wasn't a big deal - I got your problem mixed up with
Elliotte fixing disparate prefixes, so that was a lot of the confusion.

-Brett

> 
> -Ed
> 
> Brett McLaughlin wrote:
> > Yep, it's a bug. I'll work on it tonight or tomorrow...
> >
> > -Brett
> 
>                                   ------------
> 
>  - The happiest of people aren't the ones
>    who always have the best of everything;
>    they are the ones who always make the best
>    of everything they have.
> 
>                                            Ed Morehouse
>                                            Software Engineer/Evil Genius
>                                            The Motley Fool

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org