- From: Joseph Kesselman <keshlam@us.ibm.com>
- Date: Thu, 31 Oct 2002 11:51:45 -0500
- To: Christian Parpart <cparpart@surakware.net>
- Cc: www-dom@w3.org, "Dominic Chambers" <dominic.chambers@bigfoot.com>, Philippe Le Hegaret <plh@w3.org>
On Thursday, 10/31/2002 at 05:43 CET, Christian Parpart <cparpart@surakware.net> wrote: > can't imagine _ANY_ usecase for a standalone XPath Module implementaion. It's a separate module precisely because there are, and will be, DOMs that don't implement it, for various reasons. > It's usually for a W3 reference implementation to cover most parts > recommented. Not all implementations are reference implementations. Not all implementations are intended to be fully general. The DOM very deliberately does not want to take an all-or-nothing approach; we'd rather folks be as compatable as they can be -- and at well-named, documented levels of compatabilty -- even if there are portions their customers don't need and that they don't want to support. You're right, there will be market forces demanding more features. There will also be market forces demanding more efficiency in memory, including in code size. We can let the marketplace decide which trade-offs are most interesting. Having said that: If someone has a DOM which does not want to implement the XPath module, do we really want to prevent their customers from easily working around that? To take your own examples, if Xerces hasn't yet implemented the DOM XPath API, do you really want to force them all the way to a completely different set of XPath APIs? ______________________________________ Joe Kesselman / IBM Research
Received on Thursday, 31 October 2002 11:52:25 UTC