[jdom-interest] Namespace patch

Elliotte Rusty Harold elharo at metalab.unc.edu
Tue Aug 29 12:20:08 PDT 2000


At 1:59 PM -0500 8/29/00, Brett McLaughlin wrote:
>Elliotte Rusty Harold wrote:
>>
>> I can see that this is necessary, and I'll look into it. However it's
>> counterproductive to work on this at this point. There's an
>> outstanding submission to fix a bunch of namespace issues, most
>> importantly maintaining namespace prefixes. Once that's fixed we can
>> probably do this pretty easily.  However, since Brett and Jason are
>> the only committers and they're a little backlogged right now,
>> nobody's been able to verify the proposed fixes and get them into the
>> main tree.
>
>Which patch are you referring to here? I didn't know we had one to do
>all of these...
>

I posted versions of Namespace and XMLOutputter last Wednesday that 
handled this. See 
http://lists.denveronline.net/lists/jdom-interest/2000-August/002118.h 
tml
To repeat:

I've posted my first pass at the problem of maintaining Namespace 
prefixes in JDOM at the usual location: 
http://metalab.unc.edu/xml/jdom/
This required changing two files:

Namespace.java
XMLOutputter.java

DOMOutputter and SAXOutputter will probably need to be changed too, 
but I didn't want to touch them yet.

The changes to Namespace were surprisingly minor. The changes to 
XMLOutputter were a royal pain. I've run it through all the cases I 
could think of
(multiple URIs, multiple prefixes
  same URI, multiple prefixes,
  same prefix, multiple URIs,
  default and non-default namespaces)
and it seems to handle everything I throw at it, but more testing is 
certainly necessary. I don't doubt that there are bugs. The code also 
needs some cleaning up.

A few notes about the approach I took:

There's almost no extra overhead until the document is serialized. In 
fact, if anything the Namespace class is now marginally faster.

When the document is serialized, no extra walking of the tree is 
required; either backwards or forwards. The namespaces accumulate as 
the tree is walked. This required changing some signatures in 
XMLOutputter to pass along a separate NamespaceStack object. This is 
an extra non-public convenience class I tacked on to the end of 
XMLOutputter. It should probably be moved into a public class.

Namespaces are declared at the highest level where they first appear. 
However, they are not automatically propagated to the root element. 
If a document element contains ten separate svg:svg child elements, 
each svg:svg element will separately declare the svg prefix. I could 
fix this in most cases, but it would require either some extra tree 
walking, or open the possibility of adding namespace declarations for 
prefixes that aren't actually used.

I changed the semantics of the equals() method in Namespace to 
compare against both prefix and URI. This was necessary for some of 
the data structures I used. It could probably be changed back with a 
little effort, but I'm not sure it should be.

I added a utility method to the Namespace class to retrieve the 
Namespace associated with a specified prefix in a given Element 
context. This will be using for retrieving URIs for prefixes that 
appear in attribute values. Asking which URI a prefix is mapped to 
only makes sense in the context of a particular Element since the 
same prefix may be mapped to multiple URIs in different parts of the 
tree or in different documents.
 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+



More information about the jdom-interest mailing list