See also: IRC log
-> http://www.w3.org/XML/XProc/2006/05/18-agenda.html
Accepted.
-> http://www.w3.org/XML/XProc/2006/05/11-minutes.html
Accepted.
Any regrets?
Rui sends regrets (WWW 2006)
Please register and review the local arrangements pages.
-> http://www.w3.org/2002/09/wbs/38398/XProcFTF2/
A-20-01: Norm to write up his thoughts on parameters and inputs
<scribe> Completed.
A-19-01: Alex to send mail describing his ideas about variables.
<scribe> Completed.
A-13-01: MSM to draft a complete table; ETA: 15 June 2006
<scribe> Continued.
-> http://www.w3.org/Bugs/Public/show_bug.cgi?id=3089
Norm has given reasons for perferring XPath 1.0.
Others have pushed back.
Murray: Is XPath 2.0 backwards compatible with 1.0?
Norm: Sort of.
<richard> http://www.w3.org/TR/xpath20/#id-backwards-compatibility
Richard: Some expressions have different meanings.
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.
Richard: XPath 2.0 in 1.0 compatibility mode doesn't remove all the extra stuff in 2.0
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: We'd be explicitly allowing the variance of 2.0 backwards incompatibility.
Some discussion of what we're going to say about errors.
<MoZ> we could give a parser with xproc
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.
<richard> I agree
<alexmilowski> I agree too. :)
<MoZ> +1 to PGrosso
None.
Adjourned