Murray: I'm torn. I tend to agree
that if we use XPath 2.0, we're ahead of the vangaurd and will
lose people. Compatibility mode will make it too complex.
... If we straight-out adopt XPath 2.0, then maybe we've gone
too far.
... I don't have a strong opinion technically, but can we do it
politically?
... I was working under the assumption that 2.0 is backwards
compatible. I was going to suggest that in our first draft, we
make a statement to say that we've chosen 1.0 for the following
reasons, however, we stipulate that it's possible that 2.0 is
the way to go, we need feedback.

Norm repeats some of his arguments.

Richard: I agree, and if there's
an XSLT 2. component, you can use that.
... The excess verbosity in the small number of cases where
it's needed doesn't seem a hardship

Mohamed: I think the smaller
subset is XPath 2.0 in compatibility mode. In XPath 1.0 there
are some additional things.
... The case of saying that XProc can handle XPath 2.0 in
compatibility mode can be maybe the point of consensus.

Alessandro: Maybe we could say
that implementations have a choice of using XPath 1.0 or XPath
2.0 in compatibility mode.
... If you want to write a pipeline that works on any
implementation, then you have to use XPath 1.0

Norm reiterates his concern about
interoperability.

<MoZ> (XPath2.0 in
compatibility mode) intersect (XPath 1.0)

Murray points out that anyone can write a
component to use XPath 2.0 expressions

Richard: If "if" and maybe one or
two other places were the only places where XPath expressions
entered into things, then maybe you could do it with different
components.
... But we also want to use XPath to establish parameters

Murray: In the pipeline language,
we'll have expressions like p:if and we're trying to decide
where to get the expression language
... We get to point into another spec and avoid writing all the
explanations.
... The second part is, I need to use something that's in XPath
2.0. I can do that with an XSLT 2.0 component and return
something into the pipeline (that can be tested with XPath
1.0)

<MoZ> XSLT1.0 and XSLT2.0 are
compnonents

<MoZ> not XPath1.0 and
XPath2.0

Alessandro: Just like in the
language we have steps that use components and we plan to have
a number of components specified in the language, we could have
the same approach for expressions.

<MoZ> XPath will be a part of
XProc language, but XSLT2 will be a component of the
language

Alex: I think the problem is that
the places I want to go with XPath 2.0 are type-based and that
would require a whole new layer to our language. That would
create a whole new bunch of work and significantly delay our
progress. As much as I want 2.0, I don't think we should try to
do all that in V1.0.
... The most conservative thing to do is say it's XPath 1.0 and
see what users say when we put out the first draft.
... I don't believe XPath 2.0 is the 20% (the edge case), but I
don't think we should take it on unless we're willing to take
on schema typing.

Norm: Would we have consensus to
proceed in the following way: we publish the first draft saying
that the expressions in the language are XPath 1.0 (and only
1.0) with an explicit request for users feedback on whether or
not that's satisfactory for enough of their use cases.

Mohamed: I just want to add that
on some platforms there will be XPath 2.0 available before
XPath 1.0.

Norm: I think it would be
reasonable to allow an implementor to use a 2.0 processor in
1.0 backwards-compatibility mode.

Alessandro: I still feel that
maybe we want to discuss this further. A question: I am
wondering if we say that we use XPath 1.0 now, how will we use
2.0 in the future.

Norm: I expect to use the version
of the pipeline doucment for that purpose.

Richard: Restricting it to the
subset with 1.0 compatibility mode does have an advantage. It
would be straightforward to say that V2 implementations that
choose to be able to run 1.0 pipelines will run them in
backwards compatibility mode. That maximizes the chances that
they'll still work.

Mohamed: I was thinking that this
was the restriction of compatibility mode. Maybe we have to be
more restrictive and say that it's not in compatibility
mode.

Norm: I think we'd lose
interoperability if we did that.

Alessandro: One question that
hasn't been adressed very clearly: would it be allowed for a
pipeline implementation to use an XPath 2 engine in backwards
compatibility mode. Would that be considered compliant?

Richard: I don't see why not.

Norm: I think that's the right
thing to do.

Alessandro: If we say either a
1.0 engine or a 2.0 engine in backwards compatiblity mode then
I can agree with the consensus.

Paul: So we're saying that the
core language will use 1.0 and any language that does the right
thing is ok.

Richard wonders if processors can detect the
edge cases that give different answers with 2.0 in backwards
compatibility mode.

Richard enumerates the cases. Case 2 is nearly
impossible to detect.

Alex: I think that a good XPath
2.0 library will tell you if you're in one of these strange
cases.

Mohamed: Maybe we could handle
this a different way, by asking the XSL WG to handle these
differences as warnings.
... Maybe as warnings, it could be handled by the implementors.
Those warnings may give errors in XProc.

Norm: I doubt it.

Proposal: We say that we use
XPath 1.0 expressions (in the first draft, with an explicit
request for user feedback). Expressions that aren't valid XPath
1.0 expressions are errors. An implementation that evaluates
the expressions using an XPath 2.0 processor in backwards
compatibility mode is conformant.

(Provided that it gives errors for non-1.0
expressions)

Alex: Do we want to include the
number case?

Richard: I'd be entirely happy if
we said that implmentations should report the compatibility
mode cases.

Accepted.

<PGrosso> "Should" is okay
for compat issues, but "must" for non-1.0 expressions.