Re: XPath version

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 UTC