IRC log of xproc on 2009-01-29

Timestamps are in UTC.

15:43:40 [RRSAgent]
RRSAgent has joined #xproc
15:43:40 [RRSAgent]
logging to
15:43:44 [Zakim]
Zakim has joined #xproc
15:43:46 [Norm]
Zakim, this will be xproc
15:43:46 [Zakim]
ok, Norm; I see XML_PMWG()11:00AM scheduled to start in 17 minutes
15:56:33 [Norm]
Meeting: XML Processing Model WG
15:56:34 [Norm]
Date: 29 Jan 2009
15:56:34 [Norm]
15:56:34 [Norm]
Meeting: 136
15:56:34 [Norm]
Chair: Norm
15:56:36 [Norm]
Scribe: Norm
15:56:38 [Norm]
ScribeNick: Norm
15:56:40 [Norm]
Regrets: Paul
15:58:05 [Norm]
Zakim, what's the passcode?
15:58:05 [Zakim]
the conference code is 97762 (tel:+1.617.761.6200 tel:+ tel:+44.117.370.6152), Norm
15:58:18 [Zakim]
XML_PMWG()11:00AM has now started
15:58:27 [Zakim]
+ +1.646.378.aaaa
15:59:28 [Norm]
Zakim, who's here?
15:59:28 [Zakim]
On the phone I see +1.646.378.aaaa
15:59:31 [Norm]
Where's my working group?
15:59:32 [Zakim]
On IRC I see RRSAgent, Norm, MSM
16:00:12 [Norm]
Zakim, aaaa is Norm
16:00:12 [Zakim]
+Norm; got it
16:01:38 [Zakim]
16:03:29 [Norm]
Hmm. Where's my working group?
16:04:14 [MoZ]
MoZ has joined #xproc
16:04:28 [Zakim]
16:04:38 [MoZ]
Zakim, what is the code ?
16:04:38 [Zakim]
the conference code is 97762 (tel:+1.617.761.6200 tel:+ tel:+44.117.370.6152), MoZ
16:06:58 [alexmilowski]
alexmilowski has joined #xproc
16:07:49 [Norm]
Are you going to be able to join soon, MoZ ?
16:08:10 [ht]
ht has joined #xproc
16:08:21 [ht]
zakim, please call ht-781
16:08:22 [Zakim]
ok, ht; the call is being made
16:08:23 [Zakim]
16:08:43 [Norm]
Present: Norm, Vojtech, Alex, Henry
16:08:51 [Norm]
Topic: Accept this agenda?
16:08:51 [Norm]
16:08:55 [Norm]
16:08:58 [Norm]
Topic: Accept minutes from the previous meeting?
16:08:58 [Norm]
16:09:01 [Norm]
16:09:03 [Zakim]
16:09:08 [Norm]
Topic: Next meeting: telcon 5 Feb 2009?
16:09:08 [Norm]
Topic: Next meeting: telcon 5 Feb 2009?
16:09:18 [Norm]
No regrets given.
16:09:23 [Norm]
Topic: Review of Widgets 1.0: Packaging and Configuration
16:09:23 [Norm]
16:09:23 [Norm]
Topic: Review of Widgets 1.0: Packaging and Configuration
16:09:23 [Norm]
16:10:03 [Norm]
ACTION: Mohamed to review the spec and report back if he finds any issues
16:10:13 [Norm]
Topic: 074. Select expression in input declaration
16:10:13 [Norm]
16:11:12 [Norm]
Norm summarizes, and reports that his implementation would return <book/>
16:11:25 [Norm]
Vojtech: I'm more inclined to read the spec to say that the select is applied only when the default binding is used.
16:12:32 [Norm]
Norm: It seems to me that preserving the select expression is the safest thing.
16:12:46 [ht]
q+ to agree with Vojtech
16:12:53 [Norm]
Vojtech: That makes sense for the default, but it may make no sense if you pass in random input.
16:12:58 [Norm]
Mohamed: I agree with Vojtech.
16:13:11 [Norm]
ack ht
16:13:11 [Zakim]
ht, you wanted to agree with Vojtech
16:13:51 [Norm]
Henry: My argument would be that the documentation distinguishes two cases, when there's a default and when there isn't. Historically, there used to be three different tableaux.
16:14:09 [Norm]
...I would hope that the select appears only in the giving a default case, and not in the vanilla declaration case.
16:15:44 [Norm]
Norm: The tableaux in the spec does allow it, but that's because it no longer distinguishes between the case where you can provide a default and when you don't.
16:17:03 [ht]
More to the point, the following: "If a binding is provided in the declaration, then select may be used to select a portion of the input identified by the p:empty, p:document, p:data, or p:inline elements in the p:input."
16:17:13 [Norm]
Mohamed: I think the note in 5.1.1 points in the same direction.
16:17:50 [Norm]
Norm: Proposal: the select on the declaration is only used if the default binding is used.
16:18:26 [Norm]
16:18:42 [Norm]
Mohamed: Can we add that the select cannot be used if there isn't a default binding.
16:19:19 [Norm]
ACTION: Norm to clarify when the select applies.
16:19:45 [Norm]
Topic: 026. New http-request test
16:19:45 [Norm]
16:21:08 [Norm]
Norm summarizes the thread.
16:21:50 [Norm]
Vojtech: Someone on xproc-dev noted that if you allow cookies, then you sometimes need to preserve state.
16:22:40 [Norm]
Norm: I think we should do cookies within a single http-request step, but that saving cookies over a longer period should be implementation-defined.
16:23:21 [Norm]
Norm: Proposal: By default, http-request should follow redirects and should preserve cookies (for the duration of that single request)
16:23:42 [Norm]
16:24:12 [Norm]
Mohamed: Can we say something about preserving cookies for a longer period being implementation defined.
16:24:38 [Norm]
Proposal: Implementations MAY provide implementation-defined mechanisms to preserve cookies for longer periods of time, but are not required to do so.
16:24:57 [Norm]
16:26:06 [Norm]
Norm: The next question is p:document, p:load, etc. I think we should say that those instructions follow redirects but do not support cookies or other advanced user-agent features.
16:26:15 [Norm]
Henry: I think we have to be explicit about this for interop.
16:26:34 [Norm]
Mohamed: I think we should keep these instructions simple.
16:26:42 [Norm]
Vojtech: But at least redirect should be handled.
16:26:50 [Norm]
Henry: Absolutely. Do what standard libraries do, but nothing else.
16:28:11 [Norm]
Norm: Proposal: p:docuemnt, p:load, etc. follow redirects but do not preserve cookies, etc.
16:28:42 [MoZ]
16:28:59 [Norm]
Vojtech: Do we need to say something about steps like p:xsl-formatter?
16:29:08 [Norm]
...And other steps that can perhaps store to http URIs?
16:29:16 [Norm]
Norm: I don't think PUT and POST support redirect...
16:30:24 [Norm]
Norm: I think we've left the ability to write output as implementation defined for security reasons, so we don't have to say anything.
16:30:43 [Norm]
16:31:29 [Norm]
Norm: The last question is, do we want to support the ability to *not* follow redirects.
16:32:52 [Norm]
Some discussion about whether or not you need to provide options for all these possible features.
16:34:02 [Norm]
Mohamed: This is related to HEAD right, which doesn't follow redirects.
16:34:26 [Norm]
Norm: If that's teh case, then I'm happy to leave the option out.
16:34:29 [Norm]
16:35:15 [Norm]
Alex: The spec says that GET and HEAD MAY follow redirects.
16:35:27 [Norm]
Norm: "May"? That's not useful.
16:36:11 [Norm]
Alex: There are a whole bunch of variations here.
16:37:03 [Norm]
Norm: Ok, I've lost all personal interst in persuing this. I don't want to add more compexity here. We can add it in 1.1 if the 1/2 of 1% of people who might ever care, do in fact care.
16:37:08 [Norm]
Proposal: No such option.
16:37:14 [Norm]
16:37:31 [Norm]
Topic: 036. Multiple inputs/outputs
16:37:32 [Norm]
16:37:34 [Norm]
Norm summarizes.
16:38:31 [Norm]
Norm: Allow source/result to accept sequences by default?
16:38:34 [Norm]
Mohamed: no.
16:38:37 [Norm]
Henry: Why?
16:38:57 [Norm]
Mohamed: Because I think it's and advanced feature and you should have to explicitly enable it.
16:39:14 [Norm]
Vojtech: I'm not sure it's really necessary to restrict sequences.
16:40:47 [Norm]
Norm: I think the reason may have been because serializing a sequences isn't something you can do with vanilla XML
16:41:33 [Norm]
Vojtech: On p:pipeline you could add your own output port and then you have a pipeline with two outputs.
16:42:07 [Norm]
Norm: I think James point that this will either be an FAQ or we should change it.
16:42:35 [Norm]
Henry: I think, on balance, I'm in favor of making this change because it imposes no change on any who's been using the steps but will allow more functionality.
16:42:41 [Norm]
Mohamed: In case you're testing on an error, it'll change.
16:43:18 [Norm]
Alex: I remember this being that basically p:pipeline was supposed to be the simple case.
16:43:25 [Norm]
Zakim, who's on the phone?
16:43:25 [Zakim]
On the phone I see Norm, Vojtech, Alex_Milowski, Ht, MoZ
16:44:00 [Norm]
Straw poll: Should we change p:pipelien to allow sequences on input and output.
16:44:05 [Norm]
16:44:08 [Norm]
16:44:41 [Norm]
Unanimity for no change.
16:44:55 [Norm]
Proposal: the status quo remains, we'll make no change here.
16:45:06 [Norm]
16:45:18 [Norm]
Topic: 040. Schematron for XProc validation
16:45:18 [Norm]
16:46:13 [Norm]
Norm: I'd like to respond, "Yes, it might. And if you write it, we'll put it somewhere that the public can see it."
16:46:17 [Norm]
Mohamed: I agree.
16:46:32 [Norm]
Proposal: The WG will not undertake this task.
16:46:38 [Norm]
16:46:50 [Norm]
Topic: 045. Using p:variable
16:46:50 [Norm]
16:47:41 [Norm]
Norm summarizes.
16:48:15 [Norm]
Mohamed: I think the use case is not that simple. Just saying that you want to have the variable on the output doesn't mean you know the structure you need.
16:48:23 [Norm]
...I think the thread offers several solutions that are sufficient.
16:48:35 [Norm]
Vojtech: I agree you can, but it is a bit annoying.
16:49:32 [Norm]
Norm hypothesizes about we might do, but doesn't want to do it.
16:50:22 [Norm]
Alex: Isn't XSLT sufficient here?
16:50:26 [Norm]
Norm: I think it is.
16:50:33 [Norm]
Vojtech: It's not that simple to do, there is a little bit of work involved.
16:50:43 [Norm]
Mohamed: I think it's worth letting exproc do this.
16:50:59 [Norm]
Alex: It's not that bad.
16:51:37 [Norm]
Norm: Does anyone want to argue that we should add a step for this?
16:51:39 [Norm]
None heard.
16:51:45 [Norm]
Proposal: No change, leave the status quo.
16:51:52 [Norm]
16:52:14 [Norm]
Topic: 051. 2.13 flawed?
16:52:14 [Norm]
16:52:42 [Norm]
Norm summarizes.
16:52:54 [Norm]
Norm: The question, I think, is if we can impose constraints on future working groups.
16:53:00 [Norm]
Henry: I'd be surprised if that caused a problem.
16:53:30 [Norm]
...Like all restrictive covenants, it's subject to the will of the court at the time when someone does violate the constraint.
16:54:06 [Norm]
Norm: So the high order bit is, there's no precedent for getting bounced because of this point.
16:54:26 [Norm]
Henry: I think that's right. You can, for example, have a namespace document that says "frozen".
16:54:33 [Norm]
Norm: Proposal: leave the status quo
16:54:54 [Norm]
16:55:05 [Norm]
Topic: 068. err:XC0016 and err:XD019
16:55:06 [Norm]
16:55:53 [Norm]
Norm thinks this is editorial on furthe reflection and proposes we accept it.
16:56:12 [Norm]
Proposal: Accept the change, removing err:XC0016 in favor of err:XD0019.
16:56:21 [Norm]
16:56:39 [Norm]
Topic: Any other business?
16:57:00 [Norm]
Norm: The W3C Technical Plenary will be held in Santa Clara, CA, US, 2-6 November, 2009.
16:57:42 [Norm]
Norm: I propose that if we're still a chartered WG in 2009, we agree to meet there as our next f2f.
16:57:59 [Norm]
Mohamed: Any word on charters?
16:58:28 [Norm]
Norm: No, not yet. But I'm not expecting any problems.
16:58:41 [Norm]
Mohamed: If the US immegration policy will allow Europeans into the company...
16:58:55 [Norm]
Norm: Yes, tentatively, that's where we'll plan to meet.
16:59:24 [Norm]
16:59:26 [Zakim]
16:59:30 [Zakim]
16:59:32 [Zakim]
16:59:34 [Zakim]
16:59:34 [Zakim]
XML_PMWG()11:00AM has ended
16:59:35 [Zakim]
Attendees were +1.646.378.aaaa, Norm, Vojtech, Alex_Milowski, Ht, MoZ
16:59:35 [Norm]
RRSAgent, set logs world-visible
16:59:39 [Norm]
RRSAgent, draft minutes
16:59:39 [RRSAgent]
I have made the request to generate Norm
17:00:09 [Norm]
About Spec Explorer?
17:00:13 [MoZ]
17:00:25 [Norm]
It's in my inbox, but unread. Big push to get a project ready for user testing next week.
17:00:29 [Norm]
I'll get to it asap.
17:00:33 [MoZ]
17:00:51 [MoZ]
17:00:55 [ht]
Bother -- I can't find any tool which a) automatically redirects for GET and b) supports HEAD
17:01:56 [Norm]
17:01:59 [Norm]
17:07:05 [ht]
can't make wget do HEAD
17:07:13 [ht]
[forgot, if I ever knew]
17:07:40 [ht]
I misread the curl docs -- curl treats GET and HEAD the same way wrt redirect, so we're good
17:07:43 [ht]
I think
18:53:30 [Zakim]
Zakim has left #xproc
20:43:52 [Norm]
Norm has joined #xproc
21:17:35 [Norm]
Norm has joined #xproc
22:20:42 [Norm]
Norm has joined #xproc
22:34:00 [MoZ]
MoZ has joined #xproc
22:45:07 [Norm]
Norm has joined #xproc