W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > November 2007

Re: XPath version

From: Jeni Tennison <jeni@jenitennison.com>
Date: Fri, 09 Nov 2007 20:55:47 +0000
Message-ID: <4734C953.2080600@jenitennison.com>
To: Norman Walsh <ndw@nwalsh.com>
CC: public-xml-processing-model-wg@w3.org

Norman Walsh wrote:
> / Jeni Tennison <jeni@jenitennison.com> was heard to say:
> | rules. Users can, without too much difficulty, end up with XPath 1.0
> | expressions that will work fine in engines that support XPath 1.0 and
> | cause type errors in XPath 2.0, so it's not simply a matter of using
> | expressions that follow XPath 1.0 syntax.
> 
> Yes, this course of action clearly does reduce interoperability, at
> least in the short term. To a certain extent, we're trying to learn to
> live with that.
> 
> Can you provide some examples where this is the case that you think
> are likely to turn up in pipelines?

Bearing in mind that all options are strings:

<p:xslt>
   <p:input name="source" select="/database/record[position() = $index]">
     <p:pipe step="pipe" port="source" />
   </p:input>
   ...
</p:xslt>

Of course you could say that options were xs:untypedAtomic instead; at 
least that would make them castable. Then the only problem would come if 
you actively created a string using something like:

<p:xslt>
   ...
   <p:param name="monthName"
     select="/months/month[position() = substring($date, 6, 2)]">
     <p:document href="months.xml" />
   </p:param>
   ...
</p:xslt>

Funnily enough, if you stick to XPath 1.0 syntax, precisely because you 
don't have the full range of XPath 2.0 datatypes you tend to create 
expressions that involve (implicit) casting of strings to numbers. 
That's where the problems will mostly lie, I think.

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com
Received on Friday, 9 November 2007 20:56:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:54 GMT