Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Are the Attributes and Namespaces classes necessary?

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: John Cowan <jcowan AT reutershealth.com>
  • To: elharo AT metalab.unc.edu (Elliotte Rusty Harold)
  • Cc: xom-interest AT lists.ibiblio.org (xom-interest)
  • Subject: Re: [XOM-interest] Are the Attributes and Namespaces classes necessary?
  • Date: Wed, 25 Sep 2002 10:18:15 -0400 (EDT)

Elliotte Rusty Harold scripsit:

> Advantages (besides reduced complexity):
>
> 1. The attributes and namespaces requested would always be live
>
> 2. The API for attributes and namespace declarations is much more
> consistent with that for child nodes.

I think this is an excellent idea. A tradeoff of N methods for N classes
is almost always a win: classes tend to be thought of individually, and so
have much more perceived complexity than methods.

> 1. The Element class is two methods more complex.

A trifle.

> 2. Taking a persistent snapshot of attributes or namespaces, would
> require a little more work on the part of the client programmer. (How
> common is this use-case anyway?) At some point, I do foresee adding a
> generic NodeList class that might be able to be used for this purpose.

I'm not a heavy generic-dom user, but I can't imagine this being important.
It's important in SAX because the Attributes object is transient.

> I'd also like to explore if it might also be possible to remove the
> Elements class. However, that's a lot trickier because the
> getChildElements() methods are more useful in practice, and because of
> the filters via name and namespace. Removing Elements might not result
> in a net reduction in complexity.

In line with the general comatoseness of XOM meta-objects, how about just
using Element as a surrogate for Elements? This could be achieved by a
factory method that shallow-copies an Element, omitting all non-element
children. The remaining children can then be iterated in the usual way.
For safety, it should be an error to attempt to attach such an element
to any ParentNode.

Come to think of it, a similar factory method could copy just the
Attributes, solving the above problem as well.

(I would figure out how to generalize this, but cafeconleche seems to be
inaccessible.)

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




Archive powered by MHonArc 2.6.24.

Top of Page