RE: Mixed @xpath-version attributes

> -----Original Message-----
> From: 
> [] On 
> Behalf Of Norman Walsh
> Sent: Friday, April 25, 2008 1:28 PM
> To:
> Subject: Mixed @xpath-version attributes
> We currently specify that the default @xpath-version is 1.0. I think
> we did this in order to maximize interoperability; the idea being that
> users are likely to forget to specify an explicit version so making
> the default 1.0 will force all implementations to treat the pipeline
> the same way.
> Unfortunately, I think the right answer to the "mixed version"
> question is straightforward nesting. And that means that either we
> need to have two versions of the standard library, or say that the
> standard library is magic, or provide a "don't care" value for
> @xpath-version.
> I don't like any of those answers, so I propose that we change our
> story and say that the default @xpath-version, if none is specified,
> is implementation-defined.
> With that change, I think we can simply say:
>   If a step specifies an @xpath-version, then that is the version that
>   it uses. If it does not specify a version, but a version is
>   specified on one of its ancestors, the nearest ancestor version
>   specified is the version that it uses. If no version is specified
>   on the step or among its ancestors, then its XPath version is
>   implementation-defined.
> I think it's ok if the implementation makes that decision dynamically.
> So if an <p:pipeline xpath-version="1.0"> imports a library, it can
> elect to make implementation-defined @xpath-version of the steps in
> that library "1.0". If the same implementation imports that library
> into a <p:pipeline xpath-version="2.0">, it can make it 2.0.
> Thoughts? (If we can come to closure on this quickly, I'd like to get
> it into the 1 May draft, so please do reply.)
>                                         Be seeing you,
>                                           norm

Looks reasonable to me. Perhaps similar rules should apply also to


Received on Friday, 25 April 2008 11:47:17 UTC