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

[philip.nelson at omniresources.com]

> Philip, I think we're increasingly on the same page with this 
> but I want
> to write out my thoughts on the matter to make sure.
> 

OK, I think it is time to move on with this issue.  What I was offering was
a sort of scoping solution to the problem of changing default namespaces.
Let's move on by saying we only need to solve the problem of changing the
namespace of existing elements and attributes, and only if someone comes up
with the "can't argue with that" use case.  

I come to this conclusion after going back to the namespaces spec *again*
and this time reading one of the cross links to the xml spec.  A namespace
is technically an attribute of an element.  A default namespace, while
textually represented in a scoped fashion, has a requirement that JDOM in
fact does meet now:

"If a default value is declared, when an XML processor encounters an omitted
attribute, it is to behave as though the attribute were present with the
declared default value."

So ends that discussion ;-) JDOM does the required thing.  Perhaps you could
argue that NO_NAMESPACE is not an appropriate default but it's time to move
on.

I think we have to conceed however, that JDOM is not a particularly
namespace friendly way to work with namespaces. If we choose to improve this
situation, we should include the ability to change all elements and
attributes where a particular namespace occurs.  For default namespaces, if
possible, this should be as simple as possible because it is very simple in
textual xml because of namespace scope. Possibly a 

Namespace.setNamespace(Namespace old, Namespace new, List data) //other
signatures may be better

You would have to at least have protected setNamespace() methods on element
and attribute.  When creating a document in memory, you could use the
simpler constructors to construct and then retroactively add the namespace.
You could use it to change the namespace of a document built externally and
you could use it for subtrees within a document.

A few more clarifications so I/we can clearly articulate the JDOM approach
to namespaces in the future...

> I think the name "default namespace" probably causes some 
> confusion.  <snip>
> > What I think the problem is lies in the difference between 
> the object model
> > and the textual representation.  

The confusion is because the NO_NAMESPACE namespace *outputs* differently
depending on where it is used.  And because of peoples perceptions about how
default namespaces work in the textual representation, it does not work the
way they expect.  This can be corrected with a good FAQ I think.

<snip>

> > Changing the default namespace of an entire tree is very 
> simple because you
> > only have to change it in one place.  
> 
> Why should it be any different to change the URI associated with the
> empty-string prefix than to change the URI associated with the "x"
> string prefix?

Because it is *so* simple to do in the textual representation.  If you are
going to change a prefix, you figure you will touch a lot of elements and
attributes.  With a no prefix namespace, attributes are by definition not
affected, and only the declaring element is affected.

> NO_NAMESPACE means the element is in no namespace.  That's 
> semantically
> identical to it having a namespace prefix of "" and a URI of 
> "", per the
> namespaces spec.

Agreed.  Our FAQ just needs to say loud and clear that if you are using
namespaces, the simple name, value constructors are not appropriate in
almost all cases.  

> You construct this with:
snip

I'll put together FAQ text in a separate message.