Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Attributes, ParentNodes, and "child" nodes ...

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Wolfgang Hoschek <wolfgang.hoschek AT mac.com>
  • To: Mike Colbert <mbcolbert AT yahoo.com>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] Attributes, ParentNodes, and "child" nodes ...
  • Date: Wed, 15 Mar 2006 13:03:34 -0800

Attribute and namespace nodes are not children of their own parent. With that in mind, many related questions can be answered directly.

Wolfgang.

On Mar 15, 2006, at 10:31 AM, Mike Colbert wrote:

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
_______________________________________________
XOM-interest mailing list
XOM-interest AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/xom-interest





Archive powered by MHonArc 2.6.24.

Top of Page