XOM API for Processing XML with Java

[Mike Colbert <mbcolbert AT yahoo.com>]

> Indeed, and that is possibly the most obvious mistake
> DOM folks made; and since then has plagued many other
> APIs (without their own fault -- once this de facto
> "standard" view become the norm, it's hard not to
> follow it). So I think XOM can thank DOM for its
> influence on forcing this decision to be made.

It certainly feels broken.  Now I'm left guessing what methods in nu.xom
with parameters of type Node actually do when passed an Attribute.  Not
to mention what methods that return Node or Nodes will ever return
an Attribute.  A lot of this is easy to guess, but that doesn't save you much
work when guessing is not enough.
 
Mike
 


----- Original Message ----
From: Tatu Saloranta <cowtowncoder AT yahoo.com>
To: Mike Colbert <mbcolbert AT yahoo.com>; xom-interest AT lists.ibiblio.org
Sent: Wednesday, March 15, 2006 12:54:27 PM
Subject: Re: [XOM-interest] Attributes, ParentNodes, and "child" nodes ...


--- Mike Colbert <mbcolbert AT yahoo.com> wrote:

> > Attribute.getParent is conceptually different from
> the other 
> > getParent methods, and arguably should have been
> called 
> > getElement or something.
> 
> But Attribute inherits getParent from Node.  I
> suspect I'm way off-base, but I'm
> starting to question the IS-A relationship between
> Attribute and Node.  Liskov/LSP

Indeed, and that is possibly the most obvious mistake
DOM folks made; and since then has plagued many other
APIs (without their own fault -- once this de facto
"standard" view become the norm, it's hard not to
follow it). So I think XOM can thank DOM for its
influence on forcing this decision to be made.

On the other hand, even XML specification itself could
have mandated an ordering (like document ordering) for
attributes: if this was made, it would have made
implementations slightly more complicated, but would
have made Namespace specification better, and allowed
full streaming of xml. As things are, indeterminate
ordering of attributes means that namespace resolution
can only be done after seeing all the attribute nodes,
preventing streaming access to attributes.

And Namespace nodes... well, those are just silly; but
they are the result of XML Namespaces being bolted on
top of xml, as opposed to being designed as part of
it. While I usually prefer layered/modular approach to
allow efficient decomposition of the problem and
solution, namespaces are one core thing that really
should have been designed as part of xml 1.0.

-+ Tatu +-

ps. As a more practical solution, one could just adopt
Canonical XML suggestion for ordering, in cases where
it is needed. It's quite intuitive, and could be
considered the most applicable standard.



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com