IRC log of xproc on 2009-10-29

Timestamps are in UTC.

14:59:28 [RRSAgent]
RRSAgent has joined #xproc
14:59:28 [RRSAgent]
logging to http://www.w3.org/2009/10/29-xproc-irc
14:59:42 [Zakim]
MoZ, you asked to be pinged at this time
14:59:44 [Norm]
Meeting: XML Processing Model WG
14:59:44 [Norm]
Date: 29 Oct 2009
14:59:44 [Norm]
Agenda: http://www.w3.org/XML/XProc/2009/10/29-agenda
14:59:44 [Norm]
Meeting: 158
14:59:44 [Norm]
Chair: Norm
14:59:44 [Norm]
Scribe: Norm
14:59:47 [Norm]
ScribeNick: Norm
15:00:29 [Norm]
I'll be along in just a moment
15:01:29 [MoZ]
Zakim, code?
15:01:32 [Zakim]
the conference code is 97762 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), MoZ
15:01:59 [Vojtech]
Vojtech has joined #xproc
15:02:14 [Zakim]
XML_PMWG()11:00AM has now started
15:02:21 [Zakim]
+Norm
15:02:29 [Zakim]
+MoZ
15:02:43 [Zakim]
+Vojtech
15:03:36 [Norm]
Zakim, who's on the phone?
15:03:37 [Zakim]
On the phone I see Norm, MoZ, Vojtech
15:03:43 [Norm]
Regrets: Paul
15:04:10 [ht]
zakim, please call ht-781
15:04:14 [Zakim]
ok, ht; the call is being made
15:04:18 [Zakim]
+Ht
15:04:55 [Norm]
Present: Norm, Mohamed, Vojtech, Henry
15:05:03 [Norm]
Topic: Accept this agenda?
15:05:03 [Norm]
-> http://www.w3.org/XML/XProc/2009/10/29-agenda
15:05:08 [Norm]
Accepted.
15:05:16 [Norm]
Topic: Accept minutes from the previous meeting?
15:05:16 [Norm]
-> http://www.w3.org/XML/XProc/2009/10/22-minutes
15:05:20 [Norm]
Accepted.
15:05:25 [Norm]
Topic: Next meeting: face-to-face 2-3 November, Santa Clara, CA, US
15:05:41 [Norm]
Henry will be a little bit late on Monday morning.
15:06:39 [Norm]
Topic: Latest editor's draft
15:06:56 [Norm]
-> http://www.w3.org/XML/XProc/docs/langspec.html
15:07:22 [Norm]
Topic: Agenda topics for the face-to-face
15:07:59 [Norm]
Norm: I think we need consider the state of the draft, the test suite, coverage, implementation status.
15:08:13 [Norm]
...and beginning to draft our PR request.
15:08:42 [Norm]
Norm: One bit of good news in that regard, Liam noted that it's unheard of for a spec to go from LC to PR.
15:09:11 [Norm]
Norm: And also the default XML processing modle.
15:09:15 [Norm]
s/modle/model/
15:11:25 [Norm]
Norm: Let's do default XML processing model on Tuesday morning so Mohamed can participate by phone.
15:12:31 [Norm]
Mohamed: I'll also try to have some ideas in place for not going back to Last Call.
15:12:46 [Norm]
---note to scribe: return to technical toipcs ---
15:14:42 [Norm]
Norm: Any comments on the latest editor's draft?
15:14:58 [Norm]
Vojtech: I have no big problems with the new versioning scheme, so I'm fine with that.
15:15:30 [Norm]
...I think relaxing the rules for with-option/with-param is a good thing.
15:16:07 [Norm]
...I think this small change to parameter input ports will also make things easier.
15:16:22 [Norm]
Norm: Right. With respect to not breaking existing pipelines, we have the required version attribute issue.
15:17:58 [Norm]
Henry: I don't think the required version attribute has any impact on the LC to PR question.
15:18:20 [Norm]
...If we can make the argument that there's good interoperability that's been demonstrated by the end of the LC period then we can go to PR, the scale of the change isn't relevant.
15:18:33 [Norm]
...Personally, I've changed my mind three times int he last two minutes, I don't know what the right answer is.
15:18:51 [Norm]
Norm: Does anyone know what the right answer is? Is anyone strongly in favor of one position or the other?
15:19:52 [Norm]
Vojtech: One breaks existing pipelines, but making it required may be odd. Moving a pipeline out of a library will require adding the attribute.
15:20:14 [Norm]
Norm: But that cuts both ways, if you don't make it required then a pipeline from a V2 library silently becomes a V1 pipeline.
15:21:46 [Norm]
Some discussion about whether or not mixing pipelines of different versions is a problem.
15:22:07 [Norm]
Mohamed: So for example you can have a pipeline A in V1 that imports a pipeline B in V2.
15:22:14 [Norm]
Norm/Vojtech: Yes
15:24:52 [Norm]
Mohamed: But what's the value of the static context for the version.
15:25:00 [Norm]
Vojtech: It's a static value, it's not dymanic at all.
15:25:33 [Norm]
Mohamed thinks we're rehashing a discussion from several years ago.
15:29:14 [Norm]
Mohamed: What does this mean: <p:pipeline version="1.0"> ... <p:xslt use-when="p:system-property('p:version') = '2.0'">...
15:30:50 [Norm]
Norm: I think a processor loads that pipeline with the V1 rules: no unknown steps, no unknown options, etc. But at runtime, if it really is a V2 processor then the use-when will return true.
15:31:49 [Norm]
Norm: If you want to run a V2 pipeline, you have to specify version="2.0"; if you want it to work in a V1 processor, you have to protect those regions that aren't fowards-compatible with use-when.
15:34:11 [Norm]
Henry: If I'm a V1 processor and I encounter a V1 pipeline, then I know what to do. If I'm a V2 processor and I encouter a version="1.0" pipeline and I encounter a V2 step then...
15:34:34 [Norm]
...So if I encounter a step that I do understand, but isn't in V1, I have to throw an error. Is that clear?
15:34:56 [Norm]
Norm: No, I think that's probably not clear enough.
15:35:25 [Norm]
Henry: I think we should clarify that: a V2 step is an error in a pipeline being run in backwards-compatibe V1 mode, even if the processor recognizes it.
15:35:26 [Norm]
Norm: yes.
15:37:03 [Norm]
Some discussion about what it even means for this spec to have a backwards compatible section given that there are no preceding versions.
15:37:54 [Norm]
Vojtech: Now that we have this version attribute and the p:version system property, and something similar for the xpath-version, I wonder if we shouldn't make p:version a sequence like p:xpath-version.
15:38:20 [Norm]
Norm: Uhm...
15:40:15 [Norm]
Norm: I'm not sure I see the value given that XProc version really only determines what constitutes a static error
15:40:30 [Norm]
Vojtech: But what about a step you want to have in V1 and V3, but not V2.
15:40:51 [Norm]
Mohamed: What about a future where there's a 2.0 "iso" version and a 2.0 "w3c" version.
15:41:35 [Norm]
Norm: I'm reluctant to go there.
15:43:12 [Norm]
Mohamed: So suppose there's a 1.1 and a 2.0.
15:43:35 [Norm]
...Some implementations only implement 2.0 and 1.0 backwards compatibility and others implement 1.1
15:45:43 [Norm]
Vojtech: There's a small asymetry between the system properties.
15:46:28 [Norm]
Norm: What do others think about this assymetry
15:46:33 [Norm]
s/assymetry/assymetry?/
15:46:52 [Norm]
Vojtech: I think in the use-when you may not have enough information to decide which part of the pipeline to include.
15:46:54 [Norm]
Norm: How?
15:47:15 [Norm]
Vojtech: I'm not sure, but soemthing like a processor that implements 1.0 and 2.0 but not 1.1. In use-when you can't test this.
15:47:34 [Norm]
Norm: Fair enough.
15:48:30 [Norm]
Norm: XPath "=" comparisons are existential so I guess it wouldn't do any harm.
15:48:40 [Norm]
Vojtech: Except in XPath 1.0 you'd get only the first one.
15:48:43 [Norm]
Norm: Ah. Yes.
15:52:13 [Norm]
Henry: All of the following are possible: I support V1, V2 and V1 in backwards compatible mode, and only V2.
15:53:09 [Norm]
...The problem is that we've tied our hands here. We might have been better off if we'd provided a function p:supports-version that returns true or false. So you can find out by querying whether a particular version is supported.
15:54:00 [Norm]
Norm: And a p:supports-xpath-version function?
15:54:10 [Norm]
Mohamed: That's what we proposed on May, 2008.
15:55:02 [MoZ]
| Just thinking: Wouldn't it make sense to have an XPath extension
15:55:03 [MoZ]
| function p:xpath-version-supported(version), similarly to
15:55:06 [MoZ]
| p:psvi-supported()? Some of the processors will support only XPath 1.0,
15:55:08 [MoZ]
| some 2.0, but not necessarily 1.0, etc., so perhaps it could be useful
15:55:10 [MoZ]
| to have access to this information in the pipeline.
15:55:11 [MoZ]
I thought the resolution from last Thursday used only the system
15:55:13 [MoZ]
property, I thought p:psvi-supported() whent away? I've never
15:55:15 [MoZ]
understood how the system property and the function would ever be
15:55:17 [MoZ]
different.
15:55:39 [MoZ]
http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2008May/0134.html
15:56:00 [Norm]
Henry: The value of psvi support is a boolean, so there's never any possibility of confusion.
15:56:36 [Norm]
...But versions aren't booleans. As quoted the answer above doesn't really answer the question.
15:57:04 [Norm]
Mohamed: I think once you're dealing with an atomic value, there's no problem. But once you have a sequence, there is a difference.
15:57:51 [Norm]
Norm: Given that implementors have to implement a few functions, I don't see the harm in adding a few more.
15:57:59 [Norm]
Vojtech: What if you want to know all the versions.
15:58:14 [Norm]
Henry: I think having both the system property and the function is the right resolution to this issue.
15:59:06 [Norm]
Proposal: The p:version system property returns a space separated list. Add a p:version-available(xs:decimal) function and a p:xpath-version-avaialable(xs;decimal) function to query for specific versions.
15:59:20 [Norm]
Accepted.
15:59:41 [Norm]
Adjourned
15:59:46 [Zakim]
-Norm
15:59:47 [Zakim]
-Vojtech
15:59:48 [Zakim]
-Ht
15:59:51 [Norm]
RRSAgent, set logs world-visible
15:59:53 [MoZ]
s/xs;decimal/xs:decimal/
15:59:55 [Norm]
RRSAgent, draft minutes
15:59:55 [RRSAgent]
I have made the request to generate http://www.w3.org/2009/10/29-xproc-minutes.html Norm
15:59:58 [Zakim]
-MoZ
16:00:00 [Zakim]
XML_PMWG()11:00AM has ended
16:00:01 [Zakim]
Attendees were Norm, MoZ, Vojtech, Ht
17:28:59 [Zakim]
Zakim has left #xproc