[
Lists Home |
Date Index |
Thread Index
]
At 3:57 PM -0400 7/16/02, Philippe Le Hegaret wrote:
>Was it due to differences in interpretation of the specifications, bugs
>in the implementations, or differences between your interpretation and
>the implementation interpretation?
Yes. :-)
Oh, and you left a couple out, specifically: areas in which the
behavior of the standard interfaces is underspecified, and
functionality which has been deliberately omitted from DOM.
>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?
Because SAX is a read-only API. That proves to be a crucial difference.
>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.
Yes, but as I intend to prove, that benefit can be fully achieved
without interfaces, and without resorting to non-portable, internal
knowledge of the implementation.
>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.
Perhaps the base problem is that the DOM requirements were too broad.
Very few of us actually need to have single programs that manipulate
HTML in JavaScript, XML in C++, and other applications in still other
languages. I am certainly not trying to do everything DOM claims, but
by doing less I think I can do better in the niche I'm attacking (XML
+ Java). DOM is the Edsel of APIs. It tried to be a Corvette and a
station wagon at the same time, and instead of being everything to
everyone, it became nothing for nobody.
>> 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.
I'm not going to claim to be the only XML API. This isn't the first
and it won't be the last. But am I willing to argue that all existing
tree-based APIs for Java are deeply flawed. And unless someone
surprises me in the next couple of months, I think I'm going to
produce the first such API that correctly models XML. (Note that I do
not feel the same way about non-tree APIs. In particular I think SAX
is correct, aside from a few minor issues on the fringes. I suspect
XNI is equally correct, perhaps more so, though I haven't yet looked
at it closely.)
> DOM is
>probably the API which the largest number of requirements and that does
>not always play in its favor.
Certainly, but perhaps instead of using that as an excuse for DOM, we
should consider whether that's a proof that the DOM requirements were
too broad, and smaller, more focused APIs may be more appropriate.
> 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.
Happy to see you. If you can't make it to New York, I'll be in Boston
for SD in November, where I'll be leading a BOF on this.
--
+-----------------------+------------------------+-------------------+
| 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/ |
+----------------------------------+---------------------------------+
|
