RE: [XPath] Incompatibilities with XPath 1.0

Thanks for the comment (this is a personal response).

We've obviously done a lot of work to try and keep the list of
incompatibilities to an absolute minimum. One reason that the list is
long is that we've tried to document them meticulously, regardless how
minor they are. We could have a debate about each one individually (for
example, whether it is acceptable to change the string representation of
very small numbers from "0.00000000001" to "1E-11") but it's not easy to
respond to a general comment that says there are too many items in the
list.

We could try to put some of these under the control of the backwards
compatibility switch.

I don't think a switch that says "ignore everything you read in this
spec and do what the XPath 1.0 spec says instead" would be useful.
Implementations may provide such a switch, but that's a switch as to
whether to run an XPath 1.0 processor or an XPath 2.0 processor; if they
select an XPath 1.0 processor then the XPath 2.0 specification doesn't
come into play, so there is nothing useful we can say about it.

Michael Kay

> -----Original Message-----
> From: public-qt-comments-request@w3.org 
> [mailto:public-qt-comments-request@w3.org] On Behalf Of Martin Duerst
> Sent: 13 February 2004 17:17
> To: public-qt-comments@w3.org
> Subject: [XPath] Incompatibilities with XPath 1.0
> 
> 
> 
> I'm quite frightened by the long list of incompatibilities 
> (even despite a special compatibility switch) between XPath 
> 1.0 and XPath 2.0. Each of these items seems to be small, but 
> overall, this has a large potential for confusion, subtle 
> errors, and so on. Not a big problem for a spec, but a 
> potential nightmare for deployment.
> 
> My guess is that to avoid this, implementations will probably 
> implement both XPath 1.0 and XPath 2.0. If that's the case, 
> it would be easier to make the compatibility switch switch 
> all features, rather than just part of them. Bringing XPath 
> 1.0 and 2.0 closer together would be even better.
> 
> 
> Regards,   Martin.
>

Received on Friday, 13 February 2004 17:01:04 UTC