XML Processing Model WG

Meeting 21, 18 May 2006


See also: IRC log


Norm, Murray, Paul, Alessandro, Richard, Alex, Rui
Andrew, Michael, Henry


Accept this agenda?

-> http://www.w3.org/XML/XProc/2006/05/18-agenda.html


Accept minutes from the previous teleconference?

-> http://www.w3.org/XML/XProc/2006/05/11-minutes.html


Next meeting: 25 May telcon

Any regrets?

Rui sends regrets (WWW 2006)

Face-to-face: 2-4 Aug 2006.

Please register and review the local arrangements pages.

-> http://www.w3.org/2002/09/wbs/38398/XProcFTF2/

Review of open action items

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.

Issue 3089: What version/subset of XPath is used in conditionals?

-> 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.


<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

Any other business?



Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/05/25 16:28:16 $