[jdom-interest] getChild() vs. getChildElements()

[Joerg]

Hi everybody,

I am new to this list and was just digging through the list archives
trying to get a picture of the development of the JDOM API. I was also
following the unfortunate discussion about the naming of the getChild()
or getChildElement() methods. When I stumbled over JDOM, the first thing

I was lucky about to see was the simple structure and naming of the API.

Once we made our own DOM implementation for a special purpose, added a
few 'special Java' functions (for example getChilds() :-) ) and
developed a DOM wrapper from this, because the standard DOM methods are
more or less unusable. This wrapper simplifies the access to the
document for a (very common) subset of XML-Documents. For example we
trimmed away all dangling whitespace and normalized multiple text nodes
already in the DocumentHandler of the SAX parser. For our purposes it is

e.g. of no interest to call getContent() for a non-leaf Element. Our
method even returns 'null', when called on a non-leaf Element.
Furthermore our getChilds() method returns only Element nodes (as an
Enumeration, a List is better but we had nothing else then) to avoid all

the nerve-racking 'instanceof' or getNodeType() checks.

What I mean is, we 'declared' a special case in the usage of XML to our
general case. An XML Document is in that case a tree of Elements, which
can have values. This view of an XML document is very common for
problems in which you have to manipulate deep data structures, which
form the vast majority of problems outside the area of traditional
document management. In our case it is explicitly defined, that you work

only with Elements when you navigate on the tree. So it is not necessary

there to say 'getChildElement()' or 'getChildElements()', this would be
a steady repetition of a meaningless statement, because we don't deal
with other Nodes than Elements. So we named our methods getChild() and
getChilds(), which says everything necessary, namely that you want to
have one or all childs (not the parent and not the siblings) of a given
Element, which are, as always, also Elements.

In JDOM, as I understood, the situation is even much more clear than in
our DOM wrapper. Here, not everything is based on a Node, so the only
potential tree-building class is Element. And text is mainly a value of
an Element (All people, who want to use XML in a different manner, can
use getMixedContent() or DOM directly). This is a basic goal of JDOM, so

I don't understand this discussion at all, why the nice simplicity of
JDOM should be sacrificed a foggy 'standards compliance'. JDOM is JDOM,
it has its specialized purpose and its clear basic definitions (you
should have no other nodes than Elements, folks). This argument of the
confused JDOM beginners which only know the DOM specification is a
little bit far-fetched. When someone starts reading about JDOM it is
very soon absolutely clear what is its intention and what is the
difference to standard DOM. And if not then it is necessary to emphasize

this point, but not to change the API because of this.

The first time, I was first a little bit confused when I saw the class
diagram because I was missing, what, the Node class of course. But then
I thought: "hey are these people really thinking about what you really
want to DO with an XML document and not only about what is in a certain
way formally consistent?". I understand it, for example, not as yet why
someone had the idea to tie a DOM node to a specific document. These
0.1% of the cases where it would be nice to get directly the Document,
containing the node, really don't justify all that increasing of entropy

when all the computers perform all these unneccessary cloneNode()
operations, while they are merging or transforming XML documents. O.K.,
I could imagine that Elements with the same name can have a different
purpose in different DTD's or that the meaning of an Element is somehow
bound to the document it is part of. But I'm a little bit
digressing from the subject.

For my (of course personal) opinion JDOM should be specialized in its
intention and consequent in the optimization for that special purpose.
This does not imply, that it is not standards compliant, because there
are all these special functions with which you can do everything else,
the standard requires (for me it would be perfect even without that but,

who knows, one day I will need them, too). Everything else will bring
JDOM in the direction of DOM and this is definetly the wrong direction.
Therefore the often mentioned 'default' in the
naming should reflect this what is used most often in the area, JDOM is
explicitly addressing (manipulating XML data structures with Java). And
this naming should be short, significant and free of repetitions (like
it is more or less now). Everything else is wasting resources (time,
nerves and entropy) like DOM is doing.

All I can do now is waiting, hoping that JDOM continues this promising
way it started, that we can silently bury our own DOM wrapper (in
honour, of course), because its major drawback is (apart from the owner
document reference, which I cannot get rid of) that it not automaticly
follows the evolving of the standards. Otherwise I have to implement
proper namespace support soon (ahrrrg... some fearless hero has to do
such things, but I'm through with implementing DOM features for some
time).

But, joking apart, I have the impression that JDOM can get a cool
standard, because of its clear and useful design approach and the
competence and influence, which is assembled here.

If you are here then you probably read all the stuff before, so thanks
for your time.

Joerg


--
<?xml version="1.0" standalone="no" encoding="ISO-8859-1"?>
<businesscard>
  <bookmarks>
    <bookmark> http://www.google.com </bookmark>
    <bookmark> http://www.gnu.org </bookmark>
    <bookmark> http://java.apache.org </bookmark>
    <bookmark> http://www.w3.org </bookmark>
    <bookmark> http://www-db.stanford.edu/lore </bookmark>
  </bookmarks>
  <sender>
    <firstname> Jörg </firstname>
    <name> Kirchhof </name>
    <title> Dipl.-Ing. </title>
    <email> joerg at freiheit.com </email>
    <phone> +49-40-890584-14 </phone>
  </sender>
  <company>
    <name> freiheit.com Technologieberatung GmbH </name>
    <address> Theodorstraße 42-90 </address>
    <zip> 22761 </zip>
    <city> Hamburg </city>
    <country> Germany </country>
    <phone> +49-40-890584-0 </phone>
    <fax> +49-40-890584-20 </fax>
    <www> http://www.freiheit.com </www>
  </company>
</businesscard>