Re: XPath 1.0 change proposal

James Clark wrote:
>
> As I understand it, you are looking for something more that this: a 
> self-contained definition of the data model that completely specifies 
> all the constraints that the data model must satisfy in order to be 
> useable with XPath.  I do not deny that this would be a nice thing to 
> have and would be more satisfying as a data model definition. 
>  However, I think it's way beyond what is appropriate for an errata 
> (especially after this period of time), and would require a major 
> rewrite (going beyond even what you are now proposing) to be 
> completely satisfactory.  For example, in your current draft I think 
> the separation between the definition of the data model itself and the 
> mapping from XML to the data model is not nearly as clean as it could be.
I would add: the work has already been done, and can be found in the XDM 
specification for XPath 2.0. It's not to everyone's liking, because it 
takes about 30 pages to say little more than XPath 1.0 says in 3; but it 
does exactly what is described here - it defines the data model 
independently of the XML (or infoset) specs, with all the necessary 
constraints, and then quite separately it describes one possible way to 
construct an XDM instance from an XML infoset.

Now it's been pointed out we have a charter (and therefore some kind of 
duty) to maintain XPath 1.0. If you're maintaining an old car then you 
have to replace components that are no longer working. But you don't 
have to fit a catalytic converter to improve the fuel consumption. Just 
because we know how to design catalytic converters doesn't mean we are 
obliged to fit them to old cars. All the evidence is that the old car is 
motoring along quite happily...
>
>
>
> In summary, although XPath 1.0 could have been written in many 
> different ways, and some of those ways might well be superior in some 
> respects to how it was in fact written, I do not believe that this 
> change proposal has identified a defect in XPath 1.0 that is in need 
> of fixing at this stage.
>
>
I couldn't have put it better.

Michael Kay
>
>
>
>
>
>
>
>
>
>
>
>

Received on Friday, 15 March 2013 08:41:03 UTC