- From: Michael Kay <mike@saxonica.com>
- Date: Fri, 14 Oct 2005 18:08:30 +0100
- To: "'Dan Connolly'" <connolly@w3.org>, <ashok.malhotra@oracle.com>
- Cc: <public-rdf-dawg-comments@w3.org>, <w3c-xsl-query@w3.org>
> I don't see it in > > I Backwards Compatibility with XPath 1.0 (Non-Normative) > http://www.w3.org/TR/2005/WD-xpath20-20050915/#id-backwards-compatibility The existence of the incompatibility is documented in item 7 of I.2: http://www.w3.org/TR/xpath20/#N14E1C > > J Revision Log (Non-Normative) > http://www.w3.org/TR/2005/WD-xpath20-20050915/#id-revisions-log > The revision log only logs changes made since April this year, whereas this decision was made way back before the first draft of XPath 2.0 was published in 2001: see http://www.w3.org/TR/2001/WD-xpath20-20011220/#id-literals > > Could you help me find rationale for the change in XPath? We don't tend to publish rationale: it's hard enough to get everyone to agree on what the language should be without asking everyone to agree on the reasons. I normally have quite a good memory, but five years is a long time and I simply don't recall what the arguments for this were at the time. One of the factors might have been SQL compatibility. It's been a very stable part of the spec. I think it's a good change: we get a lot of XSLT users who are puzzled about the strange results that double arithmetic sometimes gives, and it's not easy to explain these effects to non-technical users. Decimal arithmetic produces far fewer surprises. Michael Kay
Received on Friday, 14 October 2005 17:08:53 UTC