[
Lists Home |
Date Index |
Thread Index
]
9/21/2002 2:31:14 PM, Elliotte Rusty Harold <elharo@metalab.unc.edu> wrote:
>The underlying problem seems to be that this approach mixes up the
>view of XML as a tree of nodes and XML as a sequence of text. Either
>view makes sense. Both views are useful for processing (though only
>the text is normative). But using them both at the same time is
>ultimately confusing.
Uhh, how many of Dare's customers do you think really want clean separation
between the "tree of nodes" and "sequence of text" views? I can understand
the desire for implementers to choose one or the other, and can appreciate
the conceptual integrity of a "pure tree" view. On the other hand, as
a user of this stuff I fequently latch onto
x.innerXML = "<example>Raw DOM is <b>too</b> tedious</example>";
when I can, and miss it when I can't. And I see no particular
reason why the implementation should whine at me if I don't
give it a closing tag (I never thought to try!) since it's "obvious"
that's what's needed. The whole point of convenience methods
to make things convenient!
To be honest, the buildup for XML made me hope that you had found
some powerful synthesis of the "tree of nodes" and "strings of
text" views, built XPath deeply into the architecture, and come up with
something that was both elegant and easy to use. You got the elegant
tree view pretty well, and I appreciate your courage in simply ignoring
the syntax sugar. Maybe the elegant XOM core with a well-thought-out
convenience layer on top of it, probably including something
very much like the MS innerXML stuff, and definitely including XPath,
would pique the interest of the Underwhelmed.
|
