[
Lists Home |
Date Index |
Thread Index
]
On Tue, 2002-07-16 at 09:02, Elliotte Rusty Harold wrote:
> >- There is one and only one JDOM. If you commit to it,
> >you have the source code and and open process to work with,
> >but no alternatives to easily switch to.
>
> Please remember that you absolutely can switch parsers. JDOM supports
> just about any SAX2 parser on the planet. You can even use a DOM
> parser if you really want to. In practice JDOM code is *much* more
> portable across parsers than DOM implementations are. I have yet to
> be able to run a significant DOM program on two different DOM
> implementations (in Java) without debugging and rewriting some code,
> even in those parts that are allegedly standard.
Was it due to differences in interpretation of the specifications, bugs
in the implementations, or differences between your interpretation and
the implementation interpretation? From my experience, switching from
one implementation to an other helped discovering bugs in my own
application as well as in implementations. JDOM has the advantage that
there is no specification since it is only one implementation. Someone
using only one implementation of the DOM would run into less
troubles. Doing cross-platform, cross-JVM, and cross-implementation Java
application is harder, no doubt about it.
> >- JDOM's architecture expolits the fact that there it doesn't
> >have to worry about multiple implementations. This is a strength if
> >you like to use classes and constructors rather than
> >interfaces and factories, but some prefer the design patterns
> >that these facilitate.
>
> Be that as it may, I'm coming to realize that an interface-based
> solution is fundamentally wrong for XML read-write APIs. DOM has some
> very deep flaws at its core precisely because it is based on
> interfaces rather than classes. For a long time, this was hidden from
> me by the sheer ugliness of DOM stemming from its IDL heritage. But
> DOM has deeper problems than that.
As Mike suggested, this seems to be more an design pattern problem than
a XML/DOM specific ones. Why interfaces would be a bad thing for DOM and
not SAX for example? It is true that extending the DOM requires to be
implementation specific - most of the DOM implementations are using
internal attributes/methods when manipulating the DOM nodes - but still
being able to manipulate the extension as a transparent DOM Node is
useful.
> Come to the New York XML User's Group meeting September 17 if you want
> to hear me explain exactly what is wrong with DOM (and JDOM, and
> ElectricXML, and dom4j) and how it can be fixed.
The DOM WG is always willing to listen if you want to share your ideas
regarding XML APIs. We recently stopped working on Abstract Schemas
after feedback, some (most?) of them came from this mailing list in
fact. Stopping a draft after 2 years of work is not an easy decision but
is still possible. However, I do believe than restarting from scratch
the DOM API with the same set of requirements would produce the same
result, and only a reduction of those requirements would help
simplifying the DOM API. Parts of the complexity of the DOM API is the
complexity of XML itself and the read/write aspects.
> I also plan to release what I suspect will be the first genuinely
> correct tree-based API for XML processing in Java.
I don't think that anyone can pretend to have _The XML API for
processing XML_ whether it is DOM, JDOM, ElectricXML, or dom4j. DOM is
probably the API which the largest number of requirements and that does
not always play in its favor. SAX1 is (and will continue to be) probably
the most successful API for XML. However, in order to share ideas and
opinions, I might be able to stop by NYC if necessary, it is not so far
from Cambridge (MA) anyway.
Philippe
|
