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

[Jason Hunter]

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-