Michael Kay writes:

> On the other hand, it might be that everyone ends up 
> implementing the whole
> of XPath 2.0 because it's too much of a pain to implement a 
> subset. That's
> certainly what I intend to do.

Everytime something like this comes up our community winds up 
rediscovering or rediscussing the same tradeoffs.  I think it's worth 
pointing out that the above point, while very important in some contexts, 
is less pertinent in others.  In particular, if you're in an environment 
where you have or can conveniently integrate an existing full function 
XPath implementation, then you're right.  Providing the full XPath not 
only gives users a richer capability, it may be easier for the 
implementer.

Conversely, if you're in an environment in which the existing XPath 
implemenations aren't appropriate for one of the many reasons existing 
implementations sometimes can't be used (e.g. performance, packaging, 
licensing, implementation programming lanuage, error handling or reporting 
model, if evaluation is to be type aware, whether type information can be 
conveniently conveyed from your validation framework to the XPath 
implementation, etc., etc.) then requiring the full XPath language is 
indeed a significant implementation task.  It's also more function to 
test, and whether one can just "trust" the testing done against an 
existing XPath implementation is a maybe. 

So, I don't think there's one answer that's clearly the right one for 
everyone:  you can make good cases both for and against full XPath 2.0, 
limited subset, or some sort of variability.  A related debate has to do 
with whether evaluation should be type-aware.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------





From antti_sissonen@h... Wed Feb 07 08:43:45 2007
Received: from aji.w3.org ([133.2