See also: IRC log
Alessandro gives regrets for 29 Nov
(Note that we are not meeting on 22 Nov!)
Norm summarizes the state of play
Henry: The traditional schema group compromise seems appropriate: call attention to it in the next draft of the spec and ask for implementor and user feedback.
Alex: So we're going to allow for different answers in the two versions.
Norm: Yes, for now, with Henry's suggestion for priority feedback
Henry: The 99.99% case is when you're comparing strings in XPath 1, one of the strings will coerce to a number. In that case, you will get the same answer.
Murray: Why can't we settle on XPath 2.0
Henry/Richard: Because right now there are too many implementation communities where 1.0 is only available.
Murray: I think it'd be better to leave them behind than to possibly give different results.
Henry: The proposal as it stands
includes the idea that we give authors guidance for
... It's extremely unlikely that the kinds of xpaths that don't interoperate will really turn up in practice.
... I'd rather include the XPath 1.0 people in at the expense of that very small problem than exclude them to get rid of it.
Alex: Interoperability is more than just getting the same answer; there are also cases where the XPaths simply won't work on some implementations.
Norm: I think saying XPath 2.0 only would be a tactical error.
Murray: So can we say 1.0 only?
Norm: There are implementors that only plan to support 2.0.
Alex: I'm not sure that guiding
authors to use some squishy middle ground is the right
... I think it'd be better to explain the interoperability problems.
Some discussion of the right interoperability story.
Henry: I'd like to see the editor try to write up the point that we arrived at.
Norm: Uh, I did that.
Alex: Do we want to allow the xpath-version attribute on any element?
Norm: I was thinking of
... But I'm perfectly happy to try putting it only on p:pipeline-library and p:pipeline
Some discussion of what the differences between 1.0 and 2.0 actually are
Richard: Should we just make it a static error to attempt to use XPath 2.0 with an XPath 1.0-only processor?
Henry: I'm happy with the silent attempt because it is amenable to conditional pipelines.
Murray: Back in the days when we
were first talking about SGML on the web, one of the
expressions that came up was "perverse obscurity".
... This discussion of 1.0/2.0 corners is perverse obscurity.
... We're setting up a situation where it is possible for pipelines to generate the wrong answer.
Henry: I think you're exhagerating the situation.
Norm: I think the number of cases where you're going to give the wrong answer is quite small.
Richard: Presumably users of XSLT 2.0 processors with XSLT 1.0 stylesheets are experiencing the same problems.
Henry: I've been doing this for years and I've never had a problem.
Norm: We could make XPath 1.0 compatibility mode a MUST for implementors
Richard: And we could say that XPath 1.0 implemntors MUST only run expressions that will give teh same result
Norm: Bah, I don't think I want to go there.
Henry: I sort of like this road;
nobody loses, it's just that some people win more than
... I think the spec should say that if someone asks for XPath 2.0 evaluation, your XPath 1.0 implementation MUST only evaluate those XPaths which they know have the same value.
Richard: And if yours doesn't know any, it must reject them all.
Norm: So we're going basically the route I outlined, but saying that 2.0 processor must implement 1.0 mode and a 1.0 processor must not evaluate any expression that it cannot determine will give the same result in XPath 2.0.
Richard: Can we find out what the subset is?
Alex: Maybe. There's an appendix in XPath 2.0 spec.
Proposed: Go forward as above for the next draft.
Norm outlines his plan
Alex: I'm all for it.
Proposed: go this way for the next draft.
Norm: I think we need a new draft asap.
Richard: We also need the stuff about what types are in scope.
Norm: I'm happy to do the next draft with a fair number of "TBD" sections.
Proposed: editor will make a new public draft with the XPath/XSLT decisions and as many other decisions as possible to be published as soon as practical.
Norm: Anyone object to putting those in the next draft?
Mohamed, do we have strong use cases for them
Norm: Yes, and they're optional anyway
Norm summarizes the state of default bindings
Norm attempts to summarize the default input/output case.
See 2.3 in the 13 Nov editor's draft.
<scribe> ACTION: Norm to change all the examples [recorded in http://www.w3.org/2007/11/15-xproc-minutes.html#action01]
Henry: It occurs to me that wrt
the visible step types, it's not completely clear whether we
have schema rules or xslt rules. If I import something that
imports something else, do I get to use what's in the third
thing or not.
... Richard and my prose supposes that the answer is yes. The current draft suggests that it's no.
... And the message about circular imports clearly suggests that it's no.
Richard: I believe that Henry's message is right, modulo that fix.
Henry: I'd like to particularly encourage Alex to review it.
Alex: Right. Will do.