XOM API for Processing XML with Java

[Elliotte Rusty Harold <elharo AT metalab.unc.edu>]

> I have noted the following problems with the current management of 
> default namespaces with the current implementation of XOM (as far as 
> I understand well the source :))
>   If the read XML file is something like
>         <pref1:tag1 xmlns="uri2" xmlns:pref1="uri1">
>                 <tag2/>
>                 ...
>                 <tag2/>
>         </pref1:tag1>
>   When it will be stored, it will become:
>         <pref:tag1 xmlns:pref1="uri1">
>                 <tag2 xmlns="uri2"/>
>                 ...
>                 <tag2 xmlns="uri2"/>
>         </pref1:tag1>
>   The result may waste a lot of storage and it diverges much from 
> the original file, eventually making the user unhappy when it read 
> it back.

I've confirmed this. It is definitely a bug. I also think it explains 
another bug that had been mystifying me in XSLT processing. And it 
caused me to investigate and discover yet another bug in 
serialization that can lead to duplicate xmlns:prefix attributes in 
certain circumstances.  So this is a productive bug. :-)

Most importantly, I think I've finally got a handle on exactly how 
additional namespaces should be handled. Here's my tentative plan:

1. addNamespaceDeclaration() (formerly declareNamespace) can declare 
the default namespace by passing the empty string for the prefix.

2. addAdditionalNamespace() can redeclare prefixes that are already 
in use on the element name and the attribute names. It can't change 
the namespace URI for these prefixes (that throws a 
NamespaceException) but it can duplicate them.

3. removeNamespaceDeclaration() removes only those prefixes in the 
list of additional namespaces. It never affects the namespaces on the 
element and attribute names. It never throws an exception. If you 
attempt to remove a namespace that is not in the list of additional 
namespaces, it doesn't do anything. i.e. removing a namespace that 
doesn't exist is a no-op.

4. getNamespaceDeclarationCount() returns the number of local 
namespaces; that is, those namespaces that belong to this element 
even when it doesn't have a parent. This includes:

    A. The namespace of the element itself, which might be the
       default namespace with no prefix.
    B. The namespace of each prefixed attribute.
    C. Each namespace added by addNamespaceDeclaration

However, duplicates are removed when the list is generated. So for 
<foo xlink:type="simple" xlink:href="..."/> 
getNamespaceDeclarationCount would return 1 if foo is not in a 
default namespace and 2 if it is. Additional namespaces inherited 
from the parents of foo are not included.

5. getNamespacePrefix(int index) iterates over all local prefixes, 
including the empty string prefix for the default namespace. Like 
getNamespaceDeclarationCount() duplicates are removed, and the parent 
declarations are not considered. A naive serialization could simply 
issue all local prefix declarations on each element. Of course, a 
more sophisticated algorithm that does not unnecessarily redeclare 
namespaces will be used. However, the logic for this will go in 
Serializer and toXML, not getNamespaceDeclarationCount and 
getNamespacePrefix.


I think this will resolve all outstanding issues and bugs in 
namespace handling. I also think it's a little simpler and easier to 
understand than what XOM is doing now. Comments? Thoughts?


--

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo AT metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|           Processing XML with Java (Addison-Wesley, 2002)          |
|              http://www.cafeconleche.org/books/xmljava             |
| http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA  |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
+----------------------------------+---------------------------------+