xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Re: [XOM-interest] 0x25?

From: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
To: luca passani <passani AT eunet.no>, xom-interest AT lists.ibiblio.org
Subject: Re: [XOM-interest] 0x25?
Date: Wed, 9 Apr 2003 13:27:34 -0400

At 4:48 PM +0100 3/27/03, luca passani wrote:

Anyone who knows what this means?

the XML file is the one at:
http://wurfl.sourceforge.net/wurfl.xml

thank you

luca

nu.xom.MalformedURIException: URIs cannot contain 0x25

This one should be fixed in the d11 I just uploaded. Pleas ele tme know if for some reason it doesn't appear to be.
--

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo AT metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| Processing XML with Java (Addison-Wesley, 2002) |
| http://www.cafeconleche.org/books/xmljava |
| http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.cafeconleche.org/ |
+----------------------------------+---------------------------------+

From elharo AT metalab.unc.edu Wed Apr 9 13:42:05 2003

by happyhouse.metalab.unc.edu (Postfix) with ESMTP id 2379E20042
for <xom-interest AT lists.ibiblio.org>;
Wed, 9 Apr 2003 13:42:01 -0400 (EDT)
Received: (qmail 14222 invoked from network); 9 Apr 2003 17:42:03 -0000
Received: from unknown (HELO [192.168.254.4]) ([216.254.85.72])
(envelope-sender <elharo AT metalab.unc.edu>)
by mail16.speakeasy.net (qmail-ldap-1.03) with SMTP
for <janekdb AT yahoo.co.uk>; 9 Apr 2003 17:42:03 -0000
Mime-Version: 1.0
X-Sender: elharo AT mail.ibiblio.org
Message-Id: <p04330101baba08b947cd@[192.168.254.4]>
In-Reply-To: <20030327155018.71977.qmail AT web20902.mail.yahoo.com>
References: <20030327155018.71977.qmail AT web20902.mail.yahoo.com>
Date: Wed, 9 Apr 2003 13:30:40 -0400
To: Janek Bogucki <janekdb AT yahoo.co.uk>,
xom-interest AT lists.ibiblio.org
From: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
Subject: Re: [XOM-interest] XSLT and simplicity
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-BeenThere: xom-interest AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: <xom-interest.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/xom-interest>
List-Post: <mailto:xom-interest AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Apr 2003 17:42:05 -0000

At 3:50 PM +0000 3/27/03, Janek Bogucki wrote:

What does Elliotte mean by XSLT support? Does this mean XOM can be used as the source node tree
and the result node tree of a XSLT transformation?

Yes. And this is present in the current code. I had to update the TOdo list. :-) Currently this is hidden behind the XSLTransform class. If someone has a use case for accessing TrAX directly, it would be easy enough to exposer the relevant classes publicly.
--

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo AT metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| Processing XML with Java (Addison-Wesley, 2002) |
| http://www.cafeconleche.org/books/xmljava |
| http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.cafeconleche.org/ |
+----------------------------------+---------------------------------+

From elharo AT metalab.unc.edu Wed Apr 9 13:42:05 2003

Return-Path: <elharo AT metalab.unc.edu>
Delivered-To: xom-interest AT lists.ibiblio.org
Received: from mail.speakeasy.net (mail16.speakeasy.net [216.254.0.216])
by happyhouse.metalab.unc.edu (Postfix) with ESMTP id 6E15620125
for <xom-interest AT lists.ibiblio.org>;
Wed, 9 Apr 2003 13:42:03 -0400 (EDT)
Received: (qmail 14243 invoked from network); 9 Apr 2003 17:42:05 -0000
Received: from unknown (HELO [192.168.254.4]) ([216.254.85.72])
(envelope-sender <elharo AT metalab.unc.edu>)
by mail16.speakeasy.net (qmail-ldap-1.03) with SMTP
for <dirk AT juniper.net>; 9 Apr 2003 17:42:05 -0000
Mime-Version: 1.0
X-Sender: elharo AT mail.ibiblio.org
Message-Id: <p04330102baba097172e9@[192.168.254.4]>
In-Reply-To: <3E4D3CA4.2010803 AT juniper.net>
References: <3E4D3CA4.2010803 AT juniper.net>
Date: Wed, 9 Apr 2003 13:32:00 -0400
To: dirk bergstrom <dirk AT juniper.net>, xom-interest AT lists.ibiblio.org
From: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
Subject: Re: [XOM-interest] a small bug, perhaps
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-BeenThere: xom-interest AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: <xom-interest.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/xom-interest>
List-Post: <mailto:xom-interest AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Apr 2003 17:42:05 -0000

At 10:59 AM -0800 2/14/03, dirk bergstrom wrote:

i got the following error running 1.0d10:

java.lang.NullPointerException
at nu.xom.TextWriter.writeAttributeValue(TextWriter.java:171)
at nu.xom.Serializer.write(Serializer.java:224)
at nu.xom.Serializer.write(Serializer.java:477)
at nu.xom.Serializer.write(Serializer.java:164)
at net.juniper.rli.xml.XMLifier.renderToStream(XMLifier.java:71)

i had set preserveBaseUri(true) on the serializer, but hadn't actually
defined a base uri (the perils of cut-n-paste). it's my fault for asking
the library to do the impossible, but i don't think it should throw an NPE.
writeAttributeValue is looking for the length of the baseURI string...

I've just fixed this in 1.0d11. You can get the code form the XOM site.
--

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo AT metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| Processing XML with Java (Addison-Wesley, 2002) |
| http://www.cafeconleche.org/books/xmljava |
| http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.cafeconleche.org/ |
+----------------------------------+---------------------------------+

From todd.trimmer AT trizetto.com Wed Apr 9 13:54:07 2003

Return-Path: <todd.trimmer AT trizetto.com>
Delivered-To: xom-interest AT lists.ibiblio.org
Received: from sdc01-x08.trizetto.net (unknown [208.229.189.32])
by happyhouse.metalab.unc.edu (Postfix) with SMTP id EEA0F200F3
for <xom-interest AT lists.ibiblio.org>;
Wed, 9 Apr 2003 13:54:06 -0400 (EDT)
Received: by s-coengl-eb1.tzg.com with Internet Mail Service (5.5.2656.59)
id <23ASBHT0>; Wed, 9 Apr 2003 11:54:02 -0600
Message-ID: <89297B2626BD5541B479C42E9599B6245D6948@s-coengl-e05>
From: "Trimmer, Todd" <todd.trimmer AT trizetto.com>
To: "'xom-interest AT lists.ibiblio.org'" <xom-interest AT lists.ibiblio.org>
Date: Wed, 9 Apr 2003 11:53:44 -0600 MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
charset="iso-8859-1"
Subject: [XOM-interest] Needs hasX(String)
X-BeenThere: xom-interest AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: <xom-interest.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/xom-interest>
List-Post: <mailto:xom-interest AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Apr 2003 17:54:07 -0000

Comments on XOM

1) No Lists. Why not? Now XML processing cannot be used by generic
Collection processing algorithms that try to mimic C++'s STL. This was the
greatest strength of JDOM. If you don't want live Lists, that's one thing,
but no Lists at all?

2) DOM mimicking. Again, another strength of JDOM lost. insertChild,
appendChild, insertBefore, insertAfter... aggghhhh! All of this unnatural
processing of what is essentially a "list" is what made DOM icky. So why do
you want it back in XOM? You want to minimize the number of different ways
someone can do the same operation. These inserters are contradictory and
confusing.

3) Not enough probe methods. On Node, there's a hasChildren(), but no
hasParent()?

Element is missing:
hasChildElements(String)
hasChildElements(String, String)
hasFirstChildElement(String)
hasFirstChildElement(String, String)
hasAttribute(String)
hasAttribute(String, String)
hasNamespaceURI(String)

... basically, whenever you can do getX(String key), there should be a
matching hasX(String key).

Why insist on using null as an indicator of non-presence? You're
semantically overloading the meaning of null. And it can dangerously lead to
NPEs, which can be hard to trace and debug (See
http://www-106.ibm.com/developerworks/java/library/j-diag3.html).

If a getX(int index) throws an Exception for a bad index, why doesn't a
getX(String key) throw an Exception for a bad key? Again, inconsistency.

Using null for non-presence is like tip-toeing through a field of landmines.
Look at how laborious this is:

String a = e.getAttributeValue("a");

if (a == null)
a = "";

String b = e.getAttributeValue("b");

if (b == null)
b = "";

String c = e.getAttributeValue("c");

if (c == null)
c = "";

...

And don't give me a "you can encapsulate that in your own utility class"
excuse, because you know a lot of programmers will try to use expert
chaining of method calls, confident that the data is coming in valid:

String s = a.
getFirstChildElement("b").
getFirstChildElement("c").
getFirstChildElement("d").
getFirstChildElement("e").
toString();

But what if it's not a valid chain? What if "d" doesn't exist? BAM! A NPE.
An Exception would be much nicer. An Exception that walks up the getParent()
chain of the Element that does not contain the missing child would be even
nicer:

nu.xom.NoSuchChildException: There is no child named "d" under "a/b/c"

I know you don't care much for method call chaining, but this complaint is
addressing a problem much more fundamental. A programmer shouldn't have to
constantly check for null to avoid NPEs. I don't want to have to bloat my
code with state-checking every 3 lines. If I want to safely probe around, I
can still do so, by diligently using hasX(String) calls. This approach
better mirrors in spoken English what is trying to be solved.

Todd Trimmer

From jcowan AT reutershealth.com Wed Apr 9 14:20:29 2003

Return-Path: <jcowan AT reutershealth.com>
Delivered-To: xom-interest AT lists.ibiblio.org
Received: from skunk.reutershealth.com (unknown [65.200.144.21])
by happyhouse.metalab.unc.edu (Postfix) with ESMTP id 7736320031
for <xom-interest AT lists.ibiblio.org>;
Wed, 9 Apr 2003 14:20:29 -0400 (EDT)
Received: from skunk.reutershealth.com (unknown [127.0.0.1])
by skunk.reutershealth.com (Postfix) with SMTP
id A7F7C46E34; Wed, 9 Apr 2003 14:22:52 -0400 (EDT)
Received: by skunk.reutershealth.com (sSMTP sendmail emulation);
Wed, 9 Apr 2003 14:22:52 -0400
Date: Wed, 9 Apr 2003 14:22:52 -0400
From: John Cowan <jcowan AT reutershealth.com>
To: "Trimmer, Todd" <todd.trimmer AT trizetto.com>
Subject: Re: [XOM-interest] Needs hasX(String)
Message-ID: <20030409182252.GP15421 AT skunk.reutershealth.com>
References: <89297B2626BD5541B479C42E9599B6245D6948@s-coengl-e05>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <89297B2626BD5541B479C42E9599B6245D6948@s-coengl-e05>
User-Agent: Mutt/1.4i
cc: xom-interest AT lists.ibiblio.org
X-BeenThere: xom-interest AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: <xom-interest.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/xom-interest>
List-Post: <mailto:xom-interest AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Apr 2003 18:20:29 -0000

Trimmer, Todd scripsit:

Comments on XOM

1) No Lists. Why not? Now XML processing cannot be used by generic
Collection processing algorithms that try to mimic C++'s STL. This was the
greatest strength of JDOM. If you don't want live Lists, that's one thing,
but no Lists at all?

In essence XOM objects *are* (rather than contain) lists. In a possible
future where collections are universal, it would probably be good to make
xom.Element implement List, but we aren't there yet in terms of Java
deployment.

3) Not enough probe methods. On Node, there's a hasChildren(), but no
hasParent()?

It's a trivial convenience method equivalent to "getParent() == null".
Likewise for the others. JDOM is cluttered with these.

Why insist on using null as an indicator of non-presence?

What other meaning could it reasonably have?

Using null for non-presence is like tip-toeing through a field of landmines.
Look at how laborious this is:

String a = e.getAttributeValue("a");

if (a == null)
a = "";

That only works if it's really true that the absence of an "a" attribute
is the same as it being present with the empty-string value. If it were
an "id" attribute, absence would be one thing and the empty string quite
another (and invalid to boot).

But what if it's not a valid chain? What if "d" doesn't exist? BAM! A NPE.

Use XPath instead.

--
John Cowan jcowan AT reutershealth.com www.ccil.org/~cowan
www.reutershealth.com
"If I have not seen as far as others, it is because giants were standing
on my shoulders."
--Hal Abelson

From elharo AT metalab.unc.edu Wed Apr 9 14:50:18 2003

Return-Path: <elharo AT metalab.unc.edu>
Delivered-To: xom-interest AT lists.ibiblio.org
Received: from mail.speakeasy.net (mail13.speakeasy.net [216.254.0.213])
by happyhouse.metalab.unc.edu (Postfix) with ESMTP id 7922220079
for <xom-interest AT lists.ibiblio.org>;
Wed, 9 Apr 2003 14:50:18 -0400 (EDT)
Received: (qmail 30954 invoked from network); 9 Apr 2003 18:50:22 -0000
Received: from unknown (HELO [192.168.254.4]) ([216.254.85.72])
(envelope-sender <elharo AT metalab.unc.edu>)
by mail13.speakeasy.net (qmail-ldap-1.03) with SMTP
for <todd.trimmer AT trizetto.com>; 9 Apr 2003 18:50:22 -0000
Mime-Version: 1.0
X-Sender: elharo AT mail.ibiblio.org
Message-Id: <p04330109baba1834eada@[192.168.254.4]>
In-Reply-To: <89297B2626BD5541B479C42E9599B6245D6948@s-coengl-e05>
References: <89297B2626BD5541B479C42E9599B6245D6948@s-coengl-e05>
Date: Wed, 9 Apr 2003 14:47:29 -0400
To: "Trimmer, Todd" <todd.trimmer AT trizetto.com>,
"'xom-interest AT lists.ibiblio.org'" <xom-interest AT lists.ibiblio.org>
From: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
Subject: Re: [XOM-interest] Needs hasX(String)
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-BeenThere: xom-interest AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: <xom-interest.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/xom-interest>
List-Post: <mailto:xom-interest AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Apr 2003 18:50:19 -0000

At 11:53 AM -0600 4/9/03, Trimmer, Todd wrote:

Comments on XOM

1) No Lists. Why not? Now XML processing cannot be used by generic
Collection processing algorithms that try to mimic C++'s STL. This was the
greatest strength of JDOM. If you don't want live Lists, that's one thing,
but no Lists at all?

XOM has lists. They just aren't java.util.Lists. java.util.Lists aren't type safe. Using the Collections API creates way too much casting back and forth. Perhaps if Java had true generic support, this might be plausible, but not with Java as it is.

What would you want to do with a java.util.List that you can't do with a Node?

2) DOM mimicking. Again, another strength of JDOM lost. insertChild,
appendChild, insertBefore, insertAfter... aggghhhh! All of this unnatural
processing of what is essentially a "list" is what made DOM icky. So why do
you want it back in XOM? You want to minimize the number of different ways
someone can do the same operation. These inserters are contradictory and
confusing.

If there's strong objection, I could see removing insertBefore() and insertAfter(). They're mostly convenience methods. I should look at my samples to see how often they're actually used. Is anyone actually using these? appendChild() is also just a convenience method, but it is a very useful one for the most common use-case by far.

Looking at it now, I do note that insertChild(int position, Node child) neglects to mention whether it inserts before or after. I think it's before, but I need to check that and document it in the API docs.

Were I to expose java.util.Lists as part of the public API, as JDOM does, then all the methods of the List class effectively become part of the XOM API. That's a lot more methods than ParentNode has now, many of which don't make sense.

3) Not enough probe methods. On Node, there's a hasChildren(), but no
hasParent()?

Element is missing:
hasChildElements(String)
hasChildElements(String, String)
hasFirstChildElement(String)
hasFirstChildElement(String, String)
hasAttribute(String)
hasAttribute(String, String)
hasNamespaceURI(String)

... basically, whenever you can do getX(String key), there should be a
matching hasX(String key).

I prefer fewer methods to learn. It's a trade-off, I admit, but simplicity is a virtue.
--

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo AT metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| Processing XML with Java (Addison-Wesley, 2002) |
| http://www.cafeconleche.org/books/xmljava |
| http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.cafeconleche.org/ |
+----------------------------------+---------------------------------+

From jcowan AT reutershealth.com Wed Apr 9 14:57:25 2003

Return-Path: <jcowan AT reutershealth.com>
Delivered-To: xom-interest AT lists.ibiblio.org
Received: from skunk.reutershealth.com (unknown [65.200.144.21])
by happyhouse.metalab.unc.edu (Postfix) with ESMTP id 565BB20079
for <xom-interest AT lists.ibiblio.org>;
Wed, 9 Apr 2003 14:57:25 -0400 (EDT)
Received: from skunk.reutershealth.com (unknown [127.0.0.1])
by skunk.reutershealth.com (Postfix) with SMTP
id B26F746E34; Wed, 9 Apr 2003 14:59:44 -0400 (EDT)
Received: by skunk.reutershealth.com (sSMTP sendmail emulation);
Wed, 9 Apr 2003 14:59:44 -0400
Date: Wed, 9 Apr 2003 14:59:44 -0400
From: John Cowan <jcowan AT reutershealth.com>
To: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
Subject: Re: [XOM-interest] Needs hasX(String)
Message-ID: <20030409185944.GT15421 AT skunk.reutershealth.com>
References: <89297B2626BD5541B479C42E9599B6245D6948@s-coengl-e05>
<p04330109baba1834eada@[192.168.254.4]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <p04330109baba1834eada@[192.168.254.4]>
User-Agent: Mutt/1.4i
cc: xom-interest AT lists.ibiblio.org
X-BeenThere: xom-interest AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: <xom-interest.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/xom-interest>
List-Post: <mailto:xom-interest AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Apr 2003 18:57:25 -0000

Elliotte Rusty Harold scripsit:

Looking at it now, I do note that insertChild(int position, Node child) neglects to mention whether it inserts before or after. I think it's before, but I need to check that and document it in the API docs.

I think it would severely violate the Law of Least Astonishment if the
behavior were anything but "insert before". In which case appendChild
is by no means a convenience method, since it cannot be reduced to inserting
before any actual child.

--
John Cowan http://www.ccil.org/~cowan <jcowan AT reutershealth.com>
"Any legal document draws most of its meaning from context. A telegram
that says 'SELL HUNDRED THOUSAND SHARES IBM SHORT' (only 190 bits in
5-bit Baudot code plus appropriate headers) is as good a legal document
as any, even sans digital signature." --me

From elharo AT metalab.unc.edu Wed Apr 9 15:15:52 2003

Return-Path: <elharo AT metalab.unc.edu>
Delivered-To: xom-interest AT lists.ibiblio.org
Received: from mail.speakeasy.net (mail13.speakeasy.net [216.254.0.213])
by happyhouse.metalab.unc.edu (Postfix) with ESMTP id BF28920042
for <xom-interest AT lists.ibiblio.org>;
Wed, 9 Apr 2003 15:15:51 -0400 (EDT)
Received: (qmail 666 invoked from network); 9 Apr 2003 19:15:57 -0000
Received: from unknown (HELO [192.168.254.4]) ([216.254.85.72])
(envelope-sender <elharo AT metalab.unc.edu>)
by mail13.speakeasy.net (qmail-ldap-1.03) with SMTP
for <jcowan AT reutershealth.com>; 9 Apr 2003 19:15:57 -0000
Mime-Version: 1.0
X-Sender: elharo AT mail.ibiblio.org
Message-Id: <p0433010dbaba1fd9b69a@[192.168.254.4]>
In-Reply-To: <20030409185944.GT15421 AT skunk.reutershealth.com>
References: <89297B2626BD5541B479C42E9599B6245D6948@s-coengl-e05>
<p04330109baba1834eada@[192.168.254.4]>
<20030409185944.GT15421 AT skunk.reutershealth.com>
Date: Wed, 9 Apr 2003 15:10:02 -0400
To: John Cowan <jcowan AT reutershealth.com>
From: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
Subject: Re: [XOM-interest] Needs hasX(String)
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
cc: xom-interest AT lists.ibiblio.org
X-BeenThere: xom-interest AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: <xom-interest.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/xom-interest>
List-Post: <mailto:xom-interest AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Apr 2003 19:15:52 -0000

At 2:59 PM -0400 4/9/03, John Cowan wrote:

I think it would severely violate the Law of Least Astonishment if the
behavior were anything but "insert before". In which case appendChild
is by no means a convenience method, since it cannot be reduced to inserting
before any actual child.

Personally, I'm not astonished either way, but if many programmers are astonished by an insert after (and assuming there aren't an equal or greater number astonished by insert before) then it makes sense to keep the behavior as insertBefore.

I think appendChild is still a convenience though (albeit one I like) because you can always insertChild(lastChildPosition + 1) to append to the list.
--

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo AT metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| Processing XML with Java (Addison-Wesley, 2002) |
| http://www.cafeconleche.org/books/xmljava |
| http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.cafeconleche.org/ |
+----------------------------------+---------------------------------+

From todd.trimmer AT trizetto.com Wed Apr 9 15:23:53 2003

What would you want to do with a java.util.List that you can't do with a Node?

Fling around Iterators and Comparators to generic algorithms working on
unmodifiable Collections. Like the C++ STL.

I admit that a lack of Java Generics retards this, too.

Truthfully, I do this so little, I can rely on Bridges and subclassing
NodeFactory(s) to give me a toList() (asList()??) as needed.

Todd Trimmer

From elharo AT metalab.unc.edu Wed Apr 9 16:02:26 2003

Return-Path: <elharo AT metalab.unc.edu>
Delivered-To: xom-interest AT lists.ibiblio.org
Received: from mail.speakeasy.net (mail15.speakeasy.net [216.254.0.215])
by happyhouse.metalab.unc.edu (Postfix) with ESMTP id 25BE5200EB
for <xom-interest AT lists.ibiblio.org>;
Wed, 9 Apr 2003 16:02:26 -0400 (EDT)
Received: (qmail 5817 invoked from network); 9 Apr 2003 20:02:32 -0000
Received: from unknown (HELO [192.168.254.4]) ([216.254.85.72])
(envelope-sender <elharo AT metalab.unc.edu>)
by mail15.speakeasy.net (qmail-ldap-1.03) with SMTP
for <todd.trimmer AT trizetto.com>; 9 Apr 2003 20:02:32 -0000
Mime-Version: 1.0
X-Sender: elharo AT mail.ibiblio.org
Message-Id: <p0433010fbaba27cf9588@[192.168.254.4]>
In-Reply-To: <89297B2626BD5541B479C42E9599B6245D6948@s-coengl-e05>
References: <89297B2626BD5541B479C42E9599B6245D6948@s-coengl-e05>
Date: Wed, 9 Apr 2003 15:50:35 -0400
To: "Trimmer, Todd" <todd.trimmer AT trizetto.com>,
"'xom-interest AT lists.ibiblio.org'" <xom-interest AT lists.ibiblio.org>
From: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
Subject: Re: [XOM-interest] Needs hasX(String)
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-BeenThere: xom-interest AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: <xom-interest.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/xom-interest>
List-Post: <mailto:xom-interest AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Apr 2003 20:02:26 -0000

At 11:53 AM -0600 4/9/03, Trimmer, Todd wrote:

Why insist on using null as an indicator of non-presence? You're
semantically overloading the meaning of null. And it can dangerously lead to
NPEs, which can be hard to trace and debug (See
http://www-106.ibm.com/developerworks/java/library/j-diag3.html).

The claim made here is "As you might have guessed, I call this pattern the Null Flag bug pattern because it is caused by inconsistently using null pointers as flags for exceptional conditions." I agree that using null to indicate an exceptional condition is a bad idea. I do not, however, believe, that an element not having a certain attribute or a certain child element is in any way exceptional.

Whether you use hasChild() or (getChild() != null), you still have to make the test. And either way you still get an exception if you fail to make the test. Using a NoSuchChildException would be marginally more helpful than a NullPointerException, but I'm really not sure that we should see no such child as an exceptional condition. What about the case where you know the child element might not be there? You don't want to put core program logic in the catch block. I guess that's why you need hasChild().

The main differentiator for me is which one makes the API easier to learn and easier to use. In this case, I don't think there's enough benefit to hasChild() to justify adding the extra methods. The added complexity from the added size completely outweighs the small gain (if any) in the readbaility of the finished code.
--

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo AT metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| Processing XML with Java (Addison-Wesley, 2002) |
| http://www.cafeconleche.org/books/xmljava |
| http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.cafeconleche.org/ |
+----------------------------------+---------------------------------+

From elharo AT metalab.unc.edu Wed Apr 9 16:02:29 2003

Return-Path: <elharo AT metalab.unc.edu>
Delivered-To: xom-interest AT lists.ibiblio.org
Received: from mail.speakeasy.net (mail15.speakeasy.net [216.254.0.215])
by happyhouse.metalab.unc.edu (Postfix) with ESMTP id 5AD9B2013A
for <xom-interest AT lists.ibiblio.org>;
Wed, 9 Apr 2003 16:02:28 -0400 (EDT)
Received: (qmail 5856 invoked from network); 9 Apr 2003 20:02:34 -0000
Received: from unknown (HELO [192.168.254.4]) ([216.254.85.72])
(envelope-sender <elharo AT metalab.unc.edu>)
by mail15.speakeasy.net (qmail-ldap-1.03) with SMTP
for <todd.trimmer AT trizetto.com>; 9 Apr 2003 20:02:34 -0000
Mime-Version: 1.0
X-Sender: elharo AT mail.ibiblio.org
Message-Id: <p04330110baba296ef6f4@[192.168.254.4]>
In-Reply-To: <89297B2626BD5541B479C42E9599B6245D6948@s-coengl-e05>
References: <89297B2626BD5541B479C42E9599B6245D6948@s-coengl-e05>
Date: Wed, 9 Apr 2003 15:54:09 -0400
To: "Trimmer, Todd" <todd.trimmer AT trizetto.com>,
"'xom-interest AT lists.ibiblio.org'" <xom-interest AT lists.ibiblio.org>
From: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
Subject: Re: [XOM-interest] Needs hasX(String)
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-BeenThere: xom-interest AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: <xom-interest.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/xom-interest>
List-Post: <mailto:xom-interest AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Apr 2003 20:02:29 -0000

At 11:53 AM -0600 4/9/03, Trimmer, Todd wrote:

Using null for non-presence is like tip-toeing through a field of landmines.
Look at how laborious this is:

String c = e.getAttributeValue("c");

if (c == null)
c = "";

Not that this is really all that complex, but it can be simpler than this:

if ((c = e.getAttributeValue("c")) == null)
c = "";

What would you suggest instead?

if (e.hasAttribute("c"))
c = e.getAttributeValue();
else
c = "";

Honestly, the variant you dislike looks the clearest and simplest to me. I guess we have different tastes. De gustibus non disputandum est.
--

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo AT metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| Processing XML with Java (Addison-Wesley, 2002) |
| http://www.cafeconleche.org/books/xmljava |
| http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.cafeconleche.org/ |
+----------------------------------+---------------------------------+

From elharo AT metalab.unc.edu Wed Apr 9 16:02:36 2003

Return-Path: <elharo AT metalab.unc.edu>
Delivered-To: xom-interest AT lists.ibiblio.org
Received: from mail.speakeasy.net (mail15.speakeasy.net [216.254.0.215])
by happyhouse.metalab.unc.edu (Postfix) with ESMTP id 668A02013A
for <xom-interest AT lists.ibiblio.org>;
Wed, 9 Apr 2003 16:02:33 -0400 (EDT)
Received: (qmail 5882 invoked from network); 9 Apr 2003 20:02:36 -0000
Received: from unknown (HELO [192.168.254.4]) ([216.254.85.72])
(envelope-sender <elharo AT metalab.unc.edu>)
by mail15.speakeasy.net (qmail-ldap-1.03) with SMTP
for <todd.trimmer AT trizetto.com>; 9 Apr 2003 20:02:36 -0000
Mime-Version: 1.0
X-Sender: elharo AT mail.ibiblio.org
Message-Id: <p04330111baba2af552f2@[192.168.254.4]>
In-Reply-To: <89297B2626BD5541B479C42E9599B6245D694C@s-coengl-e05>
References: <89297B2626BD5541B479C42E9599B6245D694C@s-coengl-e05>
Date: Wed, 9 Apr 2003 15:59:21 -0400
To: "Trimmer, Todd" <todd.trimmer AT trizetto.com>,
"'xom-interest AT lists.ibiblio.org'" <xom-interest AT lists.ibiblio.org>
From: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
Subject: RE: [XOM-interest] Needs hasX(String)
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-BeenThere: xom-interest AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: <xom-interest.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/xom-interest>
List-Post: <mailto:xom-interest AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Apr 2003 20:02:36 -0000

At 1:23 PM -0600 4/9/03, Trimmer, Todd wrote:

Elliotte Rusty Harold [mailto:elharo AT metalab.unc.edu] writes:

Fling around Iterators and Comparators to generic algorithms working on
unmodifiable Collections. Like the C++ STL.

What generic algorithms would this allow? There's no natural ordering on nodes, beyond the document ordering already provided so you don't need to sort them, or find the max or min. Maybe you could define a custom comparator for a particular application, but I suspect in that case what you really want to do is use the list of nodes to build a list of other things,like numbers or strings, and then perform your operation on that list.
--

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo AT metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| Processing XML with Java (Addison-Wesley, 2002) |
| http://www.cafeconleche.org/books/xmljava |
| http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.cafeconleche.org/ |
+----------------------------------+---------------------------------+

From jcowan AT reutershealth.com Wed Apr 9 16:08:55 2003

Return-Path: <jcowan AT reutershealth.com>
Delivered-To: xom-interest AT lists.ibiblio.org
Received: from skunk.reutershealth.com (unknown [65.200.144.21])
by happyhouse.metalab.unc.edu (Postfix) with ESMTP id 23B9D200EB
for <xom-interest AT lists.ibiblio.org>;
Wed, 9 Apr 2003 16:08:55 -0400 (EDT)
Received: from skunk.reutershealth.com (unknown [127.0.0.1])
by skunk.reutershealth.com (Postfix) with SMTP
id 687BC46E34; Wed, 9 Apr 2003 16:11:18 -0400 (EDT)
Received: by skunk.reutershealth.com (sSMTP sendmail emulation);
Wed, 9 Apr 2003 16:11:18 -0400
Date: Wed, 9 Apr 2003 16:11:17 -0400
From: John Cowan <jcowan AT reutershealth.com>
To: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
Subject: Re: [XOM-interest] Needs hasX(String)
Message-ID: <20030409201117.GU15421 AT skunk.reutershealth.com>
References: <89297B2626BD5541B479C42E9599B6245D6948@s-coengl-e05>
<p04330109baba1834eada@[192.168.254.4]>
<20030409185944.GT15421 AT skunk.reutershealth.com>
<p0433010dbaba1fd9b69a@[192.168.254.4]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <p0433010dbaba1fd9b69a@[192.168.254.4]>
User-Agent: Mutt/1.4i
cc: xom-interest AT lists.ibiblio.org
X-BeenThere: xom-interest AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: <xom-interest.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/xom-interest>
List-Post: <mailto:xom-interest AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Apr 2003 20:08:55 -0000

Elliotte Rusty Harold scripsit:

Personally, I'm not astonished either way, but if many programmers
are astonished by an insert after (and assuming there aren't an equal
or greater number astonished by insert before) then it makes sense to
keep the behavior as insertBefore.

What's astonishing about insert after is that to put something at the
beginning you now need a negative index number.

I think appendChild is still a convenience though (albeit one I like) because you can always insertChild(lastChildPosition + 1) to append to the list.

If that works it needs to be documented. It would surprise (though not
astonish) me if you were allowed to pass lastChildPosition+1 to insertChild.

--
First known example of political correctness: John Cowan
"After Nurhachi had united all the other http://www.reutershealth.com
Jurchen tribes under the leadership of the http://www.ccil.org/~cowan
Manchus, his successor Abahai (1592-1643) jcowan AT reutershealth.com
issued an order that the name Jurchen should --S. Robert Ramsey,
be banned, and from then on, they were all _The Languages of China_
to be called Manchus."

From todd.trimmer AT trizetto.com Wed Apr 9 16:22:22 2003

Sent: Wednesday, April 09, 2003 2:54 PM
To: Trimmer, Todd; 'xom-interest AT lists.ibiblio.org'
Subject: Re: [XOM-interest] Needs hasX(String)

At 11:53 AM -0600 4/9/03, Trimmer, Todd wrote:

>Using null for non-presence is like tip-toeing through a field of landmines.
>Look at how laborious this is:
>
> String c = e.getAttributeValue("c");
>
> if (c == null)
> c = "";

Not that this is really all that complex, but it can be simpler than this:

if ((c = e.getAttributeValue("c")) == null)
c = "";

What would you suggest instead?

if (e.hasAttribute("c"))
c = e.getAttributeValue();
else
c = "";

Honestly, the variant you dislike looks the clearest and simplest to me. I guess we have different tastes. De gustibus non disputandum est.

Try

c = e.hasAttribute("c") ? e.getAttributeValue("c") : "";

Of course, I really want

// getAttributeValue(String name, String uri, String def)
c = e.getAttributeValue("c", "", "");

but that's a different argument and clouds why I don't like null for
non-presence.

Todd Trimmer

From elharo AT metalab.unc.edu Wed Apr 9 16:35:46 2003

Return-Path: <elharo AT metalab.unc.edu>
Delivered-To: xom-interest AT lists.ibiblio.org
Received: from mail.speakeasy.net (mail11.speakeasy.net [216.254.0.211])
by happyhouse.metalab.unc.edu (Postfix) with ESMTP id D3E3820045
for <xom-interest AT lists.ibiblio.org>;
Wed, 9 Apr 2003 16:35:45 -0400 (EDT)
Received: (qmail 6822 invoked from network); 9 Apr 2003 20:35:52 -0000
Received: from unknown (HELO [192.168.254.4]) ([216.254.85.72])
(envelope-sender <elharo AT metalab.unc.edu>)
by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP
for <xom-interest AT lists.ibiblio.org>; 9 Apr 2003 20:35:52 -0000
Mime-Version: 1.0
X-Sender: elharo AT mail.ibiblio.org
Message-Id: <p04330112baba32a12053@[192.168.254.4]>
Date: Wed, 9 Apr 2003 16:34:51 -0400
To: xom-interest AT lists.ibiblio.org
From: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: [XOM-interest] ParentNode.insertbefore and insertAfter
X-BeenThere: xom-interest AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: <xom-interest.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/xom-interest>
List-Post: <mailto:xom-interest AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Apr 2003 20:35:46 -0000

Is anybody using the insertBefore and insertAfter methods heavily? If so for what applications?

Does anyone feel strongly about these methods? Do I need to keep them as conveniences even though their functionality could be provided in terms of the indexOf() and insertChild(int i) methods?

As an experiment I commented them out to see what broke. It turns out that insertAfter is used only once internally (in XIncluder). It is not used in the samples at all.

insertBefore is used a few times in XInclude and once in the samples. Almost every use of either of these methods is inserting before or after the root element of a Document.

Are they useful conveniences? Or is the simplification achieved by deleting them worth the minor pain this would cause?

Right now I'm leaning toward deleting them because I can always add them back again later after 1.0 if their omission causes major problems or confusion, but taking them out would be much harder at a later point if they prove unnecessary. But I'm only maybe 60/40 on this so if there's an outcry to save them, I'll go along with it. Comments? Thoughts?

--

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo AT metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| Processing XML with Java (Addison-Wesley, 2002) |
| http://www.cafeconleche.org/books/xmljava |
| http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.cafeconleche.org/ |
+----------------------------------+---------------------------------+

From todd.trimmer AT trizetto.com Wed Apr 9 16:39:38 2003

Sent: Wednesday, April 09, 2003 2:51 PM
To: Trimmer, Todd; 'xom-interest AT lists.ibiblio.org'
Subject: Re: [XOM-interest] Needs hasX(String)

At 11:53 AM -0600 4/9/03, Trimmer, Todd wrote:

>Why insist on using null as an indicator of non-presence? You're
>semantically overloading the meaning of null. And it can dangerously lead to
>NPEs, which can be hard to trace and debug (See
>http://www-106.ibm.com/developerworks/java/library/j-diag3.html).

The claim made here is "As you might have guessed, I call this pattern the Null Flag bug pattern because it is caused by inconsistently using null pointers as flags for exceptional conditions." I agree that using null to indicate an exceptional condition is a bad idea. I do not, however, believe, that an element not having a certain attribute or a certain child element is in any way exceptional.

And yet getX(int) is exceptional? And java.util.* consistently considers
this exceptional (both indexed and keyed)?

Why is null not OK for an out of bounds index and yet is OK for a missing
key?

Whether you use hasChild() or (getChild() != null), you still have to make the test. And either way you still get an exception if you fail to make the test. Using a NoSuchChildException would be marginally more helpful than a NullPointerException, but I'm really not sure that we should see no such child as an exceptional condition. What about the case where you know the child element might not be there? You don't want to put core program logic in the catch block. I guess that's why you need hasChild().

The main differentiator for me is which one makes the API easier to learn and easier to use. In this case, I don't think there's enough benefit to hasChild() to justify adding the extra methods. The added complexity from the added size completely outweighs the small gain (if any) in the readbaility of the finished code.

Semantically overloading null is not easier to use. An NPE that gives no
indication as to what is null other than the line number is not easier to
learn than an Exception that can walk up the structure to give you a
meaningful status of where the model was at when it croaked.

Making it exceptional makes sure the error doesn't get propogated further
into systems that have nothing to do with XOM, like a null String being
returned from getAttributeValue(..). That null reference can be flung around
to disparate systems that can accept a String. Tracing it back to the
original culprit can be hard.

The worst thing about hasX(String) followed by a getX(String) is the double
lookup. You can cache the last lookup key and Object result, but you have to
invalidate it for every add and remove and key mutation (like setLocalName()
has to clear the cache of the parent).

Todd Trimmer

From RegierAveryJ AT JohnDeere.com Wed Apr 9 16:48:33 2003

Return-Path: <RegierAveryJ AT JohnDeere.com>
Delivered-To: xom-interest AT lists.ibiblio.org
Received: from fdpnmailgw.mailgws.com (unknown [164.121.249.102])
by happyhouse.metalab.unc.edu (Postfix) with ESMTP id 2D5032008C
for <xom-interest AT lists.ibiblio.org>;
Wed, 9 Apr 2003 16:48:33 -0400 (EDT)
Received: from 164.121.15.19 by fdpnmailgw.mailgws.com with ESMTP (MMS
SMTP Relay (MMS v5.5.1)); Wed, 09 Apr 2003 15:48:20 -0500
Received: by edxgw1.dx.deere.com with Internet Mail Service (5.5.2653.19
) id <2FRAW268>; Wed, 9 Apr 2003 15:48:19 -0500
Message-ID: <CE5456E81CB8EF4E9DA9E7E8C454918712225A AT edxmb5.jdnet.deere.com>
From: "Regier Avery J" <RegierAveryJ AT JohnDeere.com>
To: "'xom-interest AT lists.ibiblio.org'" <xom-interest AT lists.ibiblio.org>
Subject: RE: [XOM-interest] Needs hasX(String)
Date: Wed, 9 Apr 2003 15:48:09 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 128A589E139890-01-01
Content-Type: text/plain;
charset=iso-8859-1
Content-Transfer-Encoding: 7bit
X-BeenThere: xom-interest AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: <xom-interest.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/xom-interest>
List-Post: <mailto:xom-interest AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
<mailto:xom-interest-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Apr 2003 20:48:33 -0000

... but I suspect in that case what you really want to do is use the list of nodes to build a list of other things,like numbers or strings, and then perform your operation on that list.

Which XOM makes difficult to do. *If* XOM actually provided an iterator()
method on Node or ParentNode the following would be possible using my
personal already created utility classes:

return new MutatingIterator(node.iterateChildren()) {
public Object mutate(Object o) {
return createBusinessObjectFromNode((Node)o);
}
};

There are already lots of utility classes out there for transforming the
contents of an Itererator into the standard Collecitons classes. Iterators
are the natural interface point.

Instead, I've got to create XOM specific iterator something along these
lines:

class XOMNodeIterator {
private Node node;
private int pos = 0;

public XOMNodeIterator(Node node) {
this.node = node;
}
public boolean hasNext() {
return pos < node.getChildCount();
}

public Object next() {
return node.get(pos++);
}
}

return new MutatingIterator(new XOMNodeIterator(node)) {
public Object mutate(Object o) {
return createBusinessObjectFromNode((Node)o);
}
};

Of course, if you want a thread-safe implementation, it gets much more
complex. Yes, I can write it once and put it in my library, but now my
library depends on XOM instead of just the application, because the XOM API
isn't complete.

IMHO, adding convenience methods doesn't introduce complexity, it alleviates
complexity from client code. Complexity arises from complex relationships.
Convenience methods don't add relationships.
At the very least you could add some standard iterator classes to the API
without actually adding the iterateX() methods. If you included the ability
to mutate to these standard iterator implementations such like:

public Object next() {
return mutate(node.get(pos++));
}
protected Object mutate(Node node) { return node; }

The the above code loses a cast:

return new XOMNodeIterator(node) {
protected Object mutate(Node node) {
return createBusinessObjectFromNode(node);
}
};

Regards,
Avery Regier

RE: [XOM-interest] 0x25?, Sebastien Brissaud, 04/01/2003
- <Possible follow-up(s)>
- Re: [XOM-interest] 0x25?, Elliotte Rusty Harold, 04/09/2003