[
Lists Home |
Date Index |
Thread Index
]
Elliotte Rusty Harold [mailto:elharo@metalab.unc.edu] wrote:
...
> > - Can't insert XML strings directly into the tree
>
> What do you mean by this? Are you saying
> element.appendChild("<p>Hello</p>") should attach a p child to
> element?
Yes, both MSXML and the .NET implementation have supported this through
the Inner/OuterXml properties.
> I can't say this appeals to me. You might be able to come up with a
> logically consistent model where this makes sense, but I don't see
> it. Most of the people who want to do this appear to be confusing
> text and markup. Still, it would be an interesting approach for
> somebody to experiment with.
It actually turns out to be quite useful in certain scenarios (say,
reading a string of XML from a DB that needs to be loaded into a
subtree).
...
> But there are some new features waiting to be discovered in the API.
> My absolute favorite is the getValue() method on Node. I think this
> is going to be shockingly useful, and lead to much more robust
> solutions. DOM has a method named getValue(), but it's essentially
> useless. This one is based on XPath's string-value function, and it
> actually works. In many examples I implemented in DOM, JDOM, and
> XOM, getValue() lopped off huge chunks of complicated, error-prone,
> navigation code by immediately returning exactly what the client
> needed.
It's nothing new. Microsoft's implementations have had this for some
time. MSXML's 'text' property, .NET's InnerText/OuterText, and
XPathNavigator's Value property all return the XPath string-value. Even
though they aren't part of the standard DOM API, these properties are
commonly used and do a tremendous job of simplifying traversal code.
BTW, the 'text' property has been around since the early MSXML days.
> The getStringForm() method helps a lot for simple problems, while
> still allowing more complex solutions to more complex problems. JDOM
> used to have something like this, but threw it away (partially under
> my instigation, I'm afraid) after the first couple of betas.
Again, nothing new. MSXML has had an 'xml' property since the early
days. And .NET's implementations have continue the tradition with
InnerXml/OuterXml along with various other mechanism for pushing streams
of XML 1.0 out.
...
> And unlike any other API I've seen, XOM is designed to support
> subclassing while maintaining absolute control over well-formedness.
> Barring an I/O error, XOM will not let you create malformed documents
> in any way at any time. Of course, this, like all claims, is modulo
> undiscovered bugs. But if bugs are discovered, I am committed to
> fixing them. Unlike every other API I've seen, I do not rely on the
> client programmer being an XML expert. It's the API's job to make
> sure the rules of XML are followed, not the client's.
You must not have seen the .NET DOM implementation then (XmlNode
hierarchy). It allows subclassing and extensibility in some very
powerful ways.
I agree with Dare. Having spent a lot of time with the Microsoft APIs, I
didn't see anything new or outrageously compelling about the XOM design.
--
Aaron Skonnard <http://skonnard.com>, DevelopMentor <http://develop.com>
Essential XML Quick Reference available online in PDF format...
<http://develop.com/books>
Some books are to be tasted, others to be swallowed, and some few to be
chewed and digested. - francis bacon, 1597
|
