[jdom-interest] Accessing Child Elements

[Brett McLaughlin]

"Peter V. Gadjokov" wrote:
> 
> 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.

No, he's said that it is confusing in light of the XML Namespace
specification, which I think is different.

First, we have no constructor that absorbs its parent's namespace, which
means a getChild that took that into account would begin to build
non-uniformity into our method behaviors.

Second, it is clear from the XML Namespace rec that a namespace is
intrinsic to an Element; although it may make sense for an Element to be
referenced implicitly by it's parent namespace, it is wrong in regards
to the spec, and thus I don't like to encourage it.

Third, it is not at all unusual for the default namespace, and the no
namespace, to be used. Almost every XSLT document around uses both. So
your claim that they aren't common uses is way off. XHTML has the same
case.

>        - 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.

All the time. XSLT, SVG, and XML Schemas are two very common cases where
I'm constantly having children in a different namespace than the parent.
Well designed XSLT templates require this.

> 
> 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

I think so, given an understanding of the XML Namespace spec. YOu have
to remember, we are intuitive as long as that intuitiveness is correct.
We went through this a long time ago - if something is intuitive but
WRONG, we won't put it in; we don't encourage bad use-patterns. That's
why getText() no longer returns trimmed content. People expected it, but
they were WRONG, so we made sure to make them be right.

> 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

Not true - it deals with local names AND a Namespace. There is never a
use in the core of a local name along (even when it's only a local name
passed in, a Namespace object is added and that's how the Element is
dealt with). It's always a local name and Namespace.

> 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

In your methodology, they have to know the precise state of the
document. I'd rather be exact and verbose on a single element and have
the Element be indpendent of the condition of its surroundings. That's
safe, and good programming. To depend on the surroundings being a
certain way is a bad idea.

> 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 don't think so - that assumes the user blindly used JDOM without ever
bothering to read an email or Javadocs. We can't help that kind of user.
We can help the one that read that spec, read the Javadocs quickly, and
understands that for the same reason, we make sure that each Element has
its namespace specified, to avoid confusion. In your case, literally
changing the order of the tree being built changes the namespace. 

Element parent = new Element("parent", myNamespace);
parent.addChild(new Element("child"));

is not the same as

Element child = new Element("child");
Element parent = new Element("parent", myNamespace);
parent.addChild(child);

Unless you change the whole API. That's a very confusing situation! I
think if you add getChild(), you have to change addChild(), and on down
the line... feels like a slippery slope.

> 
> 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

Why? By definition, that really blows out a major component of the
specification. I actually really like default namespaces, as they make
life... well... easy...

> 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.

Again, though, prefixes are an intrinsic part of XML Namespaces. Or did
I misunderstand you here?

> 
> 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

To me, it's non XML Namespaces-compliant, promotes incorrect
understandings of the XML Namespaces spec, and is prone to cause
unpredictable results. I can't speak for Elliotte ;-)

> 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

I think you are exaggerating here - what is so complex about it? In my
book, I use namespaces in every example, and have not received a single
question on them - and I get a ton of questions!

> 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.

I think you brought out a good FAQ - but I maintain (and I think
Elliotte does too) that this change wouldn't remain true to the spec.

In any case, good discussions, let's keep at it ;-)

-Brett

> 
> Thanks,
> 
> -pvg

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org