[jdom-interest] Accessing Child Elements

[Peter V. Gadjokov]

Wrote Brett
 
>For the record, I'm also in agreement with Elliotte - he laid the
>reasons out very well, so I'll just say I agree ;-)

Fair enough, although my understanding of Elliotte's reasons is not as
clear as yours yet. Elliotte has said that
       - having getChild return anything other than a child in the
         empty namespace is confusing.
       - there is a set of simple rules that describes
         the behaviour of all methods create/find methods involving
         names and namespaces.

On the first item, I don't see how that method is less confusing and
even if it was (hard to distinguish between confusing to me or
Ellioette and 'objectively confusing'...), the 'non-confusing' method
seems useless and impractical to me. I don't see how one would have a
reason to call it often if namespaces were in use.

As to the rules they are:

1. An unprefixed name with a URI is always in the default namespace. 
2. An unprefixed name without a URI is always in no namespace. 
3. A prefixed name is always in whatever namespace the URI specifies. 

Concise, granted but easy and intuitive? I don't see the notion of a
prefixed or unprefixed names being directly represented in the core
API - certainly every method on Element that has anything to do with
names (besides getQualifiedName) deals with local names, always. To
apply the rules, a user has to know the precise state of the
parameters being passed in to something like
getChild("name", namespace). Additionally, you need to know what
prefixes are and how they behave and that there is, for instance, such
a thing as a 'default' namespace which, as far as the Java API user is
concerned, is the same namespace as any other namespace with the same
URI except it's different. Suppose then you hit the namespace spec and
figured out exactly how it's different. You find out that in textually
represented XML, if an element declares a namespace with a URI and no
prefix, any child elements without a prefixed name or default
namespace declaration of its own belongs to the namespace of the
enclosing element. Ah, you say, so prefixes and namespaces are there
so my JDOM tree looks and acts like an XML tree! You create a new
element, with an _unprefixed_ name and no namespace, you add it to the
parent and what do you get? A child in the empty namespace. Sure,
that's what the rule says but that's not the rule you just saw in the
Namespace spec. Easy to learn though, no?

I'm not suggesting the 'dynamic' behaviour should be implemented as
described above - I'm hoping to illustrate that the ruleset is
anything but intuitive and easy to learn and that familiarity and habit
do not always constitute simplicity. The simple changes I proposed are
of essentially equivalent (high) complexity, give or take some delta
for taste. The difference is that I wanted the notion of a default
namespace effectively removed (and coalescing namespace declarations
to default or otherwise to be done during output) and the default
behaviour of getChild and co to do something useful when namespaces
are in use - this also lays the groundwork for banishing the whole
prefix mess from the core model.

Now, I'm perfectly happy to accept that Ellioette doesn't like this
change because it doesn't appeal to him aesthetically, it seems oddly
unfamiliar, or he has an experience-based gut-feeling that is likely
correct but hasn't fully bubbled up to concious verbalization. These
might not be great strictly technical reasons but they are reasons
nonetheless - APIs are designed, implemented and used  by people,
after all. But given the overwhelming complexity of namespace/prefix
handling in the current implementation, I find it difficult to accept
that a couple of fairly small, in the grand scheme of things, changes
make the whole thing 'categorically' wrong and unintuitive - not 
without some more concrete justification of the more intuitive and
useful nature of the existing behaviour.

In any event, I think I've ranted on this matter long enough. JDOM works
and is useful to me right now, as it is. I do think we are missing an
oppurtunity to do something well in line with the 'JDOM Philosophy',
as stated in the FAQ:

[...] JDOM should hide the complexities of XML wherever possible, while
remaining true to the XML specification [...]

I'll take working code over philosophy any day though.

Thanks,

-pvg