[jdom-interest] Re: jdom-interest digest, Vol 1 #194 - 17 msgs
David W. Smiley
dsmiley at mitre.org
Fri Sep 1 14:09:28 PDT 2000
> >I'm not sure it's the right thing to go this way but let's look it
> >over. I don't see what bugs you'd have when moving elements between
> >docs. The simple idea is that if you have
> > <foo:child/>
> >When you say parent.getChild("child") it's kinda natural for the
> >unspecified namespace of "child" to be the same as the parent, not the
> >no-namespace. It's a simple way of thinking: ask Bob Jones about his
> >kid Billy and he naturally refers to the Billy in the Jones namespace.
> Bugs or no bugs, this just doesn't seem obvious to me. I'd rather
> explicitly specify my namespaces.
Do you refer to your mother by her full name? Does your Java code use
fully qualified package names always?
>I think this is going to cause big,
> unexpected problems for programmers when they encounter documents
> where the children don't have the same namespaces as the parent.
It's hard to imagine "big unexpected problems" arising from this; you'd
quickly see your error after the first test-run. The only thing that
makes me weary about this whole discussion is that I don't know that
much about xml namespaces (I have read some of the FAQ). However I have
a strong feeling that namespaces should work how I am proposing it
should since I think namespaces should work in a way similar to other
applications of a name space that I am familiar with (ex: last names,
Java packages). **The rough rule I mean when I said "works the same" is
that one shouldn't have to get overly specific about a name if a context
can be assummed.** This doesn't hold for the serialized form of an XML
document (since you must put the prefix everywhere it should apply (i.e.
in scope) according to the spec), but it sure as hell would make it
convenient if within JDOM I wouldn't have to be so specific all the
time. This is another way JDOM could become a better DOM, and XML for
that matter for ease in specifying namespaces :-)
Imagine JDOM working roughly like this:
(1)Elements are created with a null namespace field if none is specified
in the constructor.
(2)Elements have a getNamespace() method that would work much like my
getRootElement() method did in my pseuodocode earlier. That is,
recursively traverses ancestors, starting with itself, looking for a
namespace field that is not null and then returns it (possibly being
(3)When an element is added to another element:
if the namespace field of the added element is null, leave it null
if the namespace field of the added element is NOT null, then call
getNamespace on the new parent. If it is the same namespace as the
added element's namespace field, then set the namespace of the added
element's namespace field to null (inheritance), otherwise leave it as
(3)If an element is removed:
if the namespace field of the removed element is null, then call
getNamespace on the parent of the removed element, and set the namespace
field of the removed element to that value.
if the namespace field of the removed element is NOT null, then leave
it as is.
(4)If an element is cloned/copied:
(works like removal but on a copy and without the actual removal)
(5)There is an instance of Namespace that represents the "Null XML
Namespace" --that is, a lack of a namespace
(6)The namespace behavior of Elements as described here applies to
Attributes in the same way (where appropriate).
(7)When serializing a document in which the root element has null for
its namespace field, the Null XML Namespace is assumed (the field is
_not_ set to this).
(8) "xmlns" and "xmlns:" prefixed attributes are considered transient.
They aren't really there (i.e. detectable by the api), but it is visible
in the serialized form of an xml document.
Oh, and I agree with what Peter V. Gadjokov had to say about namespaces
in [Re: Namespace patch]. It is a tad confusing, but are you simply
saying that Namespaces should be distinguishable via the URI and not the
prefix? And that Element.equals and hashcode would test against that
URI and the element's name? That would be consistent with what the XML
Namespace FAQ says about the issue; see this section:
-- David Smiley
More information about the jdom-interest