Re: [XPath] Incompatibilities with XPath 1.0

Hello Jonathan,

At 19:04 04/02/16 -0500, Jonathan Robie wrote:
>I agree with Mike - if I have an existing XSLT 1.0 stylesheet, and I want 
>to know what I have to make it work with XSLT 2.0, this list of 
>incompatibilities tells me precisely what to watch out for.

Well, I guess you or Mike can do that. But do you expect the
average developer out there to memorize the list and then go
through a stylesheet step by step?

So what I think would help a lot (doesn't have to be in the
spec, of course) would be some tool that takes a stylesheet
as input and lists up all the potential problems. Seems like
a very good CR exit criterion.

Also good would be recipes to rewrite code so that it does
what the stylesheet originally did in 1.0, but is also working
on 2.0.

Of course the best thing in this line of thought would be
to have a tool that detected the potential problems and
fixed them using the recipes. Just ideas.

Another way to look at the problem would be to try the
above, and then potentially tweak it to eliminate issues
that cannot be handled by a machine.


>A global statement that "these are two different languages" does not tell 
>me what I need to change.

Of course not. I don't think at all that listing the differences
was a bad idea as long as they are there.


>And of course it would be good to have the languages be the same, but 
>there have been specific reasons for each change.

Another potential improvement would be to do away with the compatibility
mode, or to make the compatibility mode really completely compatible.
The current compatibility mode creates three languages, 1.0, 2.0compat,
and 2.0pure. In many ways, that's worse than two languages.


>I'm classifying this as substantive, but I am not sure if you have 
>specific requests for greater compatibility - if so, listing them would be 
>helpful.

Rather than specific items, I'm worried about the overall story.

Regards,   Martin.


>Jonathan
>
>Michael Kay wrote:
>
>>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 Tuesday, 17 February 2004 18:05:21 UTC