[
Lists Home |
Date Index |
Thread Index
]
At 9:13 PM -0700 9/20/02, Dare Obasanjo wrote:
> - No XPath support [this makes makes it a non-starter in my book]
This will be added eventually. In fact, a number of design decisions
I made have been very much affected by the needs of XPath. But I felt
it was important to get the core right first.
> - Doesn't preserve lexical fidelity
That's a feature, not a bug, and quite a deliberate one too. If your
application requires lexical fidelity, then your application is
designed wrong, and needs to be fixed.* XOM is quite deliberately
engineered to produce cognitive dissonance in developers who are
misusing XML features. Treating syntax sugar as architecturally
significant is the one of the most common errors.
* Possibly if you're writing an editor, this isn't true. But if
you're writing an editor you're in a very weird place any way--for
instance, you may not be able to assume constant well-formedness--and
you really need a custom API designed for that use case.
> - 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?
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.
>PS: I had really expected to see a new paradigm in manipulating XML
>presented by ERH besides the
>entire-document-in-memory-with-random-access and
>streaming-forward-only-access models. All I saw was a slightly
>tweaked W3C DOM. Perhaps people like me were the wrong audience and
>the announcement was meant for Java folks?
It's not a completely new design by any stretch of the imagination.
If there hadn't been a JDOM first, then there wouldn't have been a
XOM (and if there hadn't been a DOM there wouldn't have been a JDOM).
We all learn from what's gone before.
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.
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.
Some of the neatest hacks are hidden behind the scenes. XOM is the
only API I know of that can really figure out what needs to be a
character reference and what doesn't. There's actually a lot of code
to make that work (and some more is needed for particular character
sets) but it only appears as a single argument to a single method.
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.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| XML in a Nutshell, 2nd Edition (O'Reilly, 2002) |
| http://www.cafeconleche.org/books/xian2/ |
| http://www.amazon.com/exec/obidos/ISBN%3D0596002920/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.cafeconleche.org/ |
+----------------------------------+---------------------------------+
|
