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

-- 
Norman Walsh <ndw@nwalsh.com> | Never interrupt your enemy when he is
http://nwalsh.com/            | making a mistake.-- Napoleon