Fri Aug 6 17:04:17 PDT 2004
An element information item has the following properties:
3.[children] An ordered list of child information items, in document
order. This list contains
element , processing instruction, reference to skipped
entity, character, and comment information
items, one for each element, processing instruction,
reference to an unprocessed external entity,
data character. and comment appearing immediately within
the current element, If the element
content includes any entity references, the list will also
include pairs of entity start marker
information items and their corresponding entity end
marker information items, one pair for each
entity reference. If the element content includes any
CDATA sections, the list will also include
pairs of CDATA start marker information items and their
corresponding CDATA end marker
information items, one pair for each CDATA section. If the
element is empty, this list has no
This simply could not be any clearer - getChild() and getChildren() are
absolutely wrong according to this. So again, we are back to either:
And again, the second is much clearer, particularly when XPath comes
Still seems pretty QED to me.
For the record, good points, Peter. It is good to define what specs we
should look at. It's also worth noting that even if we disagree on the
XML and Namespace spec as being key, the Infoset spec alone has plenty
to say on our names.
> *] The JDOM spec
> This mythical entity would be the result of the work described at the end of
> the last item (and the ranting on mailing lists and the writing and using of
> code, of course). We do want JDOM to grow up to become a standard, after all
> - at the very least, it's worth agreeing to have or not to have one for 1.0.
> Comments welcome.
> To control your jdom-interest membership:
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc.
1200 Pacific Avenue, Suite 300
Santa Cruz, CA 95060 USA
More information about the jdom-interest