Fri Aug 6 17:04:17 PDT 2004
attributes is determined by the element on which they appear" The quote you
used is right after they say "If there is no default namespace declaration
in scope, the namespace name is null". Thus, I understand that to say that
it uses the element in which they appear, unless there is no default
Isn't that what it actually says?
On Sun, 23 Feb 2003 14:04:01 -0600, Bradley S. Huffman
<hip at a.cs.okstate.edu> wrote:
> 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
> 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
>> 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
> and the consensus was that this would be a very bad idea. This was a
> decision, it's not a bug, and it's not against either of the namespace
> If you want elements and attributes to be in a different namespace then
> 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
> 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
> documents, and their is really nothing in them about breaking documents
> apart and moving things around. About all they say is what constitutes
> and how to interpret a printed representation accordingly.
> JDOM may not have the processing model you want, and the current methods
> not behave in the way you want them to, but that doesn't make their
> or the way JDOM represents a document incorrect.
More information about the jdom-interest