W3C

- DRAFT -

XML Processing Model WG

Meeting 117, 26 Jun 2008

Agenda

See also: IRC log

Attendees

Present
Henry, Paul, Rui, Mohamed, Norm, Vojtech, Richard, Alex, Andrew
Regrets
Chair
Norm
Scribe
Norm

Contents


Accept this agenda?

-> http://www.w3.org/XML/XProc/2008/06/26-agenda

Accepted.

Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2008/06/19-minutes

Accepted.

Next meeting: telcon 3 July 2008?

No regrets heard.

Open actions

There's a long list, please close the ones you can.

Talk about Henry's action on validation root under technical agenda

Comments on the latest editor's draft?

Henry reports that 2.7 looks good except for a typo

No other comments heard.

Relationship between @xpath-version and p:system-property('p:xpath-version')

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2008May/0103.html

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

Accepted.

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

Some discussion

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.

p:schema-import?

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]

Any other business?

None heard.

Adjourned.

Summary of Action Items

[NEW] 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]
[NEW] 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]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/06/26 18:50:43 $