[jdom-interest] Namespace issues, et al.

[Bradley S. Huffman]

Malachi de AElfweald writes:

> There is a couple problems with the link you provided.
> It is not up-to-date (spec has changed since then), it is XML 1.0
> (which I now understand JDOM is, but the W3 spec I sent to you wasn't),
> and it was written by Elliotte in the first place (thus agrees with his 
> views):

Because in this cause he is right.

> I think the reason yourself and Elliotte are not comprehending why there is 
> all
> the confusion on JDOM handling of Namespaces is actually very simple. Until 
> now,
> I didn't realize JDOM wasn't up to the current specification. I thought 
> JDOM
> supported XML 1.1, as is required by many international businesses.

In this case whether it's 1.1 or 1.0 is inconsequential.  Unprefixed
attributes never, ever inherit any declared default namespace. This is
according to the original spec.s *and* section 6.2 of "Namespaces
in XML 1.1", 3rd paragraph, 3rd sentence.

    "The namespace name for an unprefixed attribute is always null."

The only other major issue I see is when a element is moved from one
branch of document tree to another, you want it's namespace and the
namespace of all it's element descendants and all prefix attributes on
them to automatically have their namespaces changed according to the
namespace declarations of their new ancestors.

This was discussed years ago (before I ever became involved in the project)
and the consensus was that this would be a very bad idea.  This was a design
decision, it's not a bug, and it's not against either of the namespace spec.s.
If you want elements and attributes to be in a different namespace then the
one given to them at the time of their creation, then you must explicitly
change their namespace. It's simple, uncomplicated, and easy to remember.
Most importantly it doesn't contradict any of the spec.'s.

JDOM doesn't model the behavior of cut and paste as might be applied to
a sheet of paper, but it's not suppose to, nor do any of the specs require
it. That's a processing issue, not a representation issue.

The XML 1.0/1.1 specs say nothing about how to internally store or process
documents, and their is really nothing in them about breaking documents
apart and moving things around. About all they say is what constitutes XML
and how to interpret a printed representation accordingly.

JDOM may not have the processing model you want, and the current methods may
not behave in the way you want them to, but that doesn't make their behavior,
or the way JDOM represents a document incorrect.

Brad