[jdom-interest] Accessing Child Elements

Brett McLaughlin brett.mclaughlin at lutris.com
Thu Sep 7 09:24:23 PDT 2000

Elliotte Rusty Harold wrote:
> I think the current behavior of JDOM with respect to namespaces is
> correct and should not be changed. I am categorically opposed to ALL
> the proposals that have been made in this thread. It is NOT true that
> you can assume that a child element shares the namespace of its
> parent. RDF and XSLT are just two common XML applications where this
> assumption is very frequently violated.
> A large part of the issue is that, unlike DOM, JDOM allows elements
> to exist and be moved and copied and so forth independent of a
> document or context. To allow namespaces to be context dependent
> would mean that an element could change from an RDF set element to an
> SVG set element to a MathML set element simply depending on where it
> was put. This is not what users need or want.
> I understand not all the proposals involve context dependent
> namespaces. Some simply want a request for children to assume the
> namespace of the parent. However, I still don't like this. In the
> general case, I may not know the namespace of the parent. For
> instance, I could be walking a document tree looking for all svg
> elements in the http://www.svg.org/ namespace. I don't know where
> those will show up. Or looking for all title elements with no
> namespace. In either case I should ask for exactly what I want. I
> think making the behavior of the getChild(String name) method
> dependent on the namespace of the parent element will be confusing
> for many users and cause unexpected bugs.
> I think the current approach is simpler, more intuitive, easier to
> explain and easier to learn. This is,
> 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.
> Note that these rules are true for ALL methods in ALL classes. There
> are no special cases, or instances where the rules change depending
> on which method you're calling. This is consistent, and therefore
> easy to learn and easy to use. What's being proposed is much less
> consistent, much less easy to learn, and much less easy to use.
> I do think there are some current problems with our namespace
> implementation--allowing namespace declarations for attribute values
> for the most part--but those are all orthogonal to what's being
> discussed in this thread.

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


> --
> +-----------------------+------------------------+-------------------+
> | Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
> +-----------------------+------------------------+-------------------+
> |                  The XML Bible (IDG Books, 1999)                   |
> |              http://metalab.unc.edu/xml/books/bible/               |
> |   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
> +----------------------------------+---------------------------------+
> |  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
> |  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
> +----------------------------------+---------------------------------+
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 

More information about the jdom-interest mailing list