Lists Home |
Date Index |
Elliotte Rusty Harold [mailto:email@example.com] 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
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
> 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
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
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...
Some books are to be tasted, others to be swallowed, and some few to be
chewed and digested. - francis bacon, 1597