See also: IRC log
No regrets heard.
There's a long list, please close the ones you can.
Talk about Henry's action on validation root under technical agenda
Henry reports that 2.7 looks good except for a typo
No other comments heard.
Richard: Does a similar question arise in XSLT 2.0?
Norm: No, as far as I can tell, you can't ask this question.
Mohamed: It's not in the language, it's only based on the value of the version attribute.
Henry: I think p:xpath-version
should only be able to return 1.0 and 2.0
... We don't provide a means for asking all the versions that it can.
Richard: What's this for?
Henry: For conditionalizing a pipeline
Norm: The property is only valuable, I think, if the pipeline doesn't specify a version. Then the pipeline can adapt.
Richard: XPath 1.0 backwards compatibility mode only gives different answers, right, it doesn't change the functions available
Norm: Hmm. I'm not sure.
Richard: If that is the case, then the answer they want is probably still 2.0.
Henry: I think we should change the definition of p:xpath-version to report the versions that are available. And decide what 2.0 in 1.0 compatibility mode means. And we should make it clear what the values are and that it's a list.
Norm: I guess the first thing to decide is what backwards compatibility mode.
Norm notes that it's a *static* error to attempt to use XPath 2.0 in a 1.0 processor.
Henry: Then we've got the same problem we had a couple of months ago.
Vojtech: So even a step that isn't called causes an error?
Henry: No, I think what this means is that the error should be dynamic, like it is for psvi-required.
Proposal: Make it a dynamic error if a 1.0 processor attempts to evaluate a 2.0 expression that it cannot determine will yield the right results.
Vojtech: Or if you attempt to use a step that expresses xpath-version=2.0
Henry: I think it was better to put the onus on implementors than on users. Although on balance I think the current plan is a good one, I note that we now move back to putting the onus on users.
Voytech: The problem is that if
xpath-version is not set, you get whatever the processor gives
... You still need the magic when you write in 2.0 but don't specify it.
Norm: AFIACT all this version stuff is only so authors can say "I know I'm using XPath 2.0 so don't even bother"
Henry: By and large you don't need to use this, you only need to do it if you know an XPath 1.0 processor will get the wrong answer or if the error at this point in the pipeline is too late.
Proposal: Make it a dynamic error if a 1.0 processor attempts to evaluate a 2.0 expression that it cannot determine will yield the right results. A 1.0 processor which encounters an explicit xpath-version=2.0 on a step that it is about to evaluate must throw this error.
Richard: If you put something in
that uses XPath 2.0 and you don't say what version then a 1.0
processor will fail when it encounters them.
... Not when it's compiling.
Norm: The general rule about compiling statically for dynamic errors you know will occur still applies.
Vojtech: I think it's even more complex because you can have XPath expressions generated dynamically.
<scribe> ACTION: Norm to revise the spec to reflect the new semantics for p:xpath-version and processor support for versions. [recorded in http://www.w3.org/2008/06/26-xproc-minutes.html#action01]
Norm: Henry, you wanted the p:xpath-version system property to return a list
Henry: Yes, I think that would be more useful.
Norm: Is "1.0 2.0" ever going to be more information than "2.0"? A 2.0 processor will always work in backwards compatibility mode.
<MoZ> a < b < c
Norm: The fact that you could
have a 2.0 processor that did not support 1.0 BCM suggests to
me that Henry is right, it should be a list.
... And I think I don't want to say more than "should be a list, for example 1.0 and 2.0" and not constrain the space any more.
Henry: Works for me.
Vojtech: Is at least one XPath processor required?
Richard: It's going to be very hard to get by without one.
Vojtech: So what is the answer?
Norm: The system property returns either "1.0" or "1.0 2.0" and it should return that answer irrespective of what any ancestor element's xpath-version attribute specifies.
Norm attempts to summarize
Some discussion of whether or not the instance has enough information to answer the question without a schema-import.
<scribe> ACTION: Henry to investigate why XSLT 2.0 required a schema-import and how we might be able to get by without it. [recorded in http://www.w3.org/2008/06/26-xproc-minutes.html#action02]