- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Mon, 12 Nov 2007 19:36:54 +0000
- To: public-xml-processing-model-wg@w3.org
Alex Milowski wrote: > On 11/9/07, Jeni Tennison <jeni@jenitennison.com> wrote: >> <p:xslt> >> ... >> <p:param name="monthName" >> select="/months/month[position() = substring($date, 6, 2)]"> >> <p:document href="months.xml" /> >> </p:param> >> ... >> </p:xslt> > > Wrapping the right-hand side in a number() function call would fix > this for XPath 2.0 > while keeping XPath 1.0 compatible. Yes, I am aware of that. The point is that it's easy to write expressions that work fine in XPath 1.0 and don't work in XPath 2.0. That being the case, it's not enough to tell users to use XPath 1.0 expressions to guarantee compatibility across processors. You have to say "use XPath 1.0 expressions with explicit casting using the string(), number() or boolean() functions in cases where XPath 2.0 would give you a dynamic error, specifically where you supply a value of one datatype where another datatype is expected, and using a [1] predicate where you supply a node-set containing more than one node where a single node is expected." Another way of putting it is that the expression must be *both* legal XPath 1.0 and legal XPath 2.0; that intersection is probably going to be the easiest thing for editors/lints to test. (I still think the expected XPath version should be made explicit.) Cheers, Jeni -- Jeni Tennison http://www.jenitennison.com
Received on Monday, 12 November 2007 19:37:11 UTC