- From: Michael Champion <Mike.Champion@softwareag-usa.com>
- Date: Tue, 2 May 2000 15:53:37 -0400
- To: <www-dom-xpath@w3.org>
----- Original Message ----- From: "Scott Boag/CAM/Lotus" <Scott_Boag@lotus.com> To: <www-dom-xpath@w3.org> Sent: Tuesday, May 02, 2000 3:31 PM Subject: Re: [dom-xpath] XPath or? (was RE: Announcing www-dom-xpath@w3.org) First, I'd like to thank you for a very constructive counter-proposal! > > I don't see how a method on Node is (or should be) really optional. A good point ... > In any > case, bloated it is: witness the JDOM stuff. People are becoming upset > with the sheer size of the API, in my experience. JDOM puzzles me a bit; at first glance it seems just as "bloated" as the DOM in terms of the number of methods, etc. On the other hand, it has more Java-friendly class bindings rather than abstract interfaces and avoids some of our more horrific naming schemes (they would NEVER THINK of calling something getNodesByXPathExpression() .... but the DOM has long since given up on finding shorter names that don't conflict with other APIs ). Anyway, I'm not sure what "lesson" JDOM has for DOM; we'll just see if they end up in the ditches that the DOM WG has tried hard to avoid... while avoiding the ditches we find ourselves mired in ;~) > How about something like the following? > I'm mulling this over ... > > My big point is, I don't think that all new API in the W3C should become > part of the DOM. That's definitely one quite possible outcome of this discussion! We could simply write a W3C Note proposing a common XPath API that is more tangentially related to the DOM. The main argument for putting it *in* the DOM is efficiency - one can do a lot inside a DOM implementation to support indexing/inverted lists/etc. that would make XPath queries work well that would be much harder *on top of* the DOM.
Received on Tuesday, 2 May 2000 15:54:51 UTC