[
Lists Home |
Date Index |
Thread Index
]
9/20/2002 3:50:23 PM, "Bullard, Claude L (Len)" <clbullar@ingr.com> wrote:
>It could be. Generally, something that is simpler
>and easier to explain has a way of winning in an
>ecology of competing codes.
Well, yeah, but IMHO XOM gets its simplicity largely by
avoiding the nasty bits of XML that the DOM flounders through
and gets itself dirty in the process. I'm thinking specifically
of non-namespaced well-formed XML, "syntax sugar" such as CDATA
sections, all the stuff that DTDs inflict on the data model
such as entity declarations, entity references, default attribute
values, and probably other horrors that I've managed to blissfully
forget.
Now I for one would be very very happy to see all this stuff
deprecated, or moved to some "XML syntax sugar preprocessor"
spec, and then we could all build from a nice, clean,
XPath-compatible data model.
If XOM can somehow promote that agenda, I'm all for it!
I also appreciated the point that John Cowan made about XOM's
conceptual integrity. As we all know, W3C DOM got the way it is
partly because it is the proverbial camel designed by a committee.
It's about 5 years old now, and it's time for someone to come along
and refactor it. Or better yet, since the notion of interoperable
API standards is so unfashionable these days, let a hundred
refactorizations of DOM/JDOM/dom4j/proprietary APIs bloom,
create an ecology of competing codes, and let Father Darwin sort
them out.
|
