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

[Jochen Strunk]

We are using jdom in the context of a web framework. Different parts of the 
application deliver parts of an xml document. The framework then assembles 
these parts, assigning each a unique namespace to avoid conflicts.

To do this we need the following use case to be supported and I was 
wondering if you think jdom should provide support for this kind of use.

Consider having an element which outputs like this:

<element>
      <child1 />
      <child2 />
</element>

to achieve this, I need to do the following:

Element element = new Element("element");
Element child1 = new Element("child1");
Element child2 = new Element("child2");

element.addContent(child1);
element.addContent(child2);

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);

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.

This is not very straightforward any more :-(


At 01:01 29.03.2001 -0800, you wrote:
>Philip Nelson wrote (March 9th):
> >
> > #3
> > Finally, here is a little more of an api change.  The NO_NAMESPACE 
> namespace
> > is identified as a namespace that represents nothing.  However, I think a
> > distiction needs to be made between "the element has no namespace" and "the
> > element has an empty namespace"
> >
> > These are now equivalent in JDOM and what I *think should happen* doesn't
> > happen.  Here is an example (c/o Jochen Strunk)
> >
> > Element element = new Element("element",
> > Namespace.getNamespace("http://foo"));
> > Element child1 = new Element("child1");
> > Element child2 = new Element("child2");
> >
> > element.addContent(child1);
> > element.addContent(child2);
> >
> > XMLOutputter op = new XMLOutputter("     ", true);
> > op.output(element, System.err);
> >
> > It outputs:
> > <element xmlns="http://foo">
> >       <child1 xmlns="" />
> >       <child2 xmlns="" />
> > </element>
> >
> > In my opinion this is incorrect, the correct output would be:
> > <element xmlns="http://foo">
> >       <child1 />
> >       <child2 />
> > </element>
>
>In my current opinion, the observed behavior is correct.  An element
>created without a namespace has no namespace.  It does not inherit a
>namespace, even if it has the chance to inherit a no-prefix "default"
>namespace.  The "correct output" example proposed above would mean that
>child1.getNamespaceURI() can return different values depending on its
>location in the document.  To have a child element's namespace be
>affected by its location in the document violates the namespace model we
>use.
>
>Per the namespaces spec, "If the URI reference in a default namespace
>declaration is empty, then unprefixed elements in the scope of the
>declaration are
>not considered to be in any namespace."  So the output above is
>consistent in indicating that child1 has no namespace.  It didn't have
>one on creation, and it doesn't get one just because it's added to
>another element.
>
>Philip Nelson wrote (today):
>
> > NO_NAMESPACE has got to be explained, both in the FAQ and in the api docs.
> > It means "absense of namespace" in some contexts and "empty namespace" in
> > the context of a parent element but only while outputting. Actually, I 
> can't
> > even say off the top of my head what it means in the context of a fully
> > qualified namespace.  There is no way to tell if it's an empty namespace or
> > the absense of a namespace by looking at it.  Jason is right, DOM is the
> > same way except that somehow, magically, it does know the difference when
> > outputting, or at least Xerces does when using the TreeWalker.  Since
> > Elliote's point in this approach to a namespace api was to avoid contextual
> > meaning of the namespace, this seems inconsistent to me.
>
>I think you're right we need to (a) make sure this is the right approach
>and (b) document it better.
>
>One alternate approach is to replace the NO_NAMESPACE special namespace
>with a simple "null" value to indicate an element not in any namespace.
>Then getNamespaceURI() would return null for elements not in any
>namespace.  getNamespace() would return null.  And so on.  The outputter
>would have to be changed to be smart enough to print the *same* output
>as today to write xmlns="" to remove the default namespace where
>appropriate.
>
>Hmm... I kind of like NO_NAMESPACE still because it makes the
>XMLOutputter code cleaner.  It makes spec sense also because of the
>namespace spec quote above and a related quote, "The default namespace
>can be set to the empty string. This has the same effect, within the
>scope of the declaration, of there being no default namespace."
>
>-jh-
>_______________________________________________
>To control your jdom-interest membership:
>http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com




(-) Jochen Strunk
(-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH
(-) Brüder-Knauß-Str. 79 - 64285 Darmstadt,
(-) Tel: 06151 665402, Fax: 06151 665373
(-) strunk at signal7.de, www.signal7.de