[jdom-interest] First pass at Namespace revision[eg]

[Elliotte Rusty Harold]

More thoughts on this:

At 1:12 PM +0200 3/29/01, Jochen Strunk wrote:


>This is very straightforward.
>Now I want to change the element so it outputs like this:
>
><element xmlns="http://foo">
>      <child1 />
>      <child2 />
></element>
>
>There's two things in jdom that make this very hard. First, there is 
>no setNamespace method. However, I can achieve the same results by 
>using getCopy. So I would do:
>
>Namespace foo = Namspace.getNamespace("http://foo");
>element = element.getCopy(element.getName(), foo);
>

I forget when and why getCopy() got added. It was probably a 
compromise to avoid adding setName() and setNamespace() methods to 
Element. But frankly it strikes me as weird and unnecessary. I'd 
prefer to delete it from the Element class. It could plausibly belong 
in a separate JDOMUtils class or package, but I'd prefer not to 
clutter the core API with it.

>That results in the original element beeing deep copied and thrown 
>away by the garbage collector.
>But the result is still not what I want, the element now outputs:
>
><element xmlns="http://foo">
>      <child1 xmlns="" />
>      <child2 xmlns="" />
></element>
>
>As I understand this happens because in your namespace model a 
>child's namspace should not be affected by its location in the 
>document. So the next step to achieve the wanted result would be 
>traversing all child elements of element and assigning them the foo 
>namespace. Its obvious that I do not want to use getCopy for this 
>task since it would unnecessarily do a deep copy. I would need to 
>implement my own copy method which gives me the same element in the 
>foo namespace.
>

Your use case is not addressed by simply adding a setNamespace() 
method to Element. Instead what you need is a 
setNamespaceForThisElementAndAllItsDescendants() which strikes me as 
even less of a good idea.

I think what you really want is an API in which namespace 
declarations are treated the same as any other attributes, and in 
which all information about namespace is dependent on the position of 
an element in the tree. I can accept the need for such an API, but we 
decided not to do this a LONG time ago. Making this change now would 
be a HUGE change to the internal structure of most of JDOM.

I think the right solution for your rather unusual need is for you to 
write a method like this:


public static Element changeDefaultnamespaceForAllDescendants(Element 
original) {

   // recursively descend the tree and recreate all the nodes with new 
namespaces
   // as you go

}

I don't propose putting any method like this into JDOM itself. I 
don't think it's a common need, and I prefer not to complicate the 
API. In any case, even if we did put a method like this in the JDOM 
API, we'd still have to recursively descend the tree and change the 
namespace of every element. The whole JDOM API is based around the 
idea of namespaces being an intrinsic property of the elements and 
attributes they're attached to, not something merely derived from 
namespace declaration attributes.


-- 

+-----------------------+------------------------+-------------------+
| 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/     |
+----------------------------------+---------------------------------+