See also: IRC log
-> http://www.w3.org/XML/XProc/2009/01/29-agenda
Accepted.
-> http://www.w3.org/XML/XProc/2009/01/22-minutes
Accepted.
No regrets given.
-> http://www.w3.org/TR/2008/WD-widgets-20081222/
<scribe> ACTION: Mohamed to review the spec and report back if he finds any issues [recorded in http://www.w3.org/2009/01/29-xproc-minutes.html#action01]
-> http://www.w3.org/XML/XProc/2008/11/cr-comments/#C074
Norm summarizes, and reports that his implementation would return <book/>
Vojtech: I'm more inclined to read the spec to say that the select is applied only when the default binding is used.
Norm: It seems to me that preserving the select expression is the safest thing.
Vojtech: That makes sense for the default, but it may make no sense if you pass in random input.
Mohamed: I agree with Vojtech.
<Zakim> ht, you wanted to agree with Vojtech
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.
... I would hope that the select appears only in the giving a
default case, and not in the vanilla declaration case.
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.
<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."
Mohamed: I think the note in 5.1.1 points in the same direction.
Norm: Proposal: the select on the declaration is only used if the default binding is used.
Accepted.
Mohamed: Can we add that the select cannot be used if there isn't a default binding.
<scribe> ACTION: Norm to clarify when the select applies. [recorded in http://www.w3.org/2009/01/29-xproc-minutes.html#action02]
-> http://www.w3.org/XML/XProc/2008/11/cr-comments/#C026
Norm summarizes the thread.
Vojtech: Someone on xproc-dev noted that if you allow cookies, then you sometimes need to preserve state.
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.
... Proposal: By default, http-request should follow redirects
and should preserve cookies (for the duration of that single
request)
Accepted.
Mohamed: Can we say something about preserving cookies for a longer period being implementation defined.
Proposal: Implementations MAY provide implementation-defined mechanisms to preserve cookies for longer periods of time, but are not required to do so.
Accepted.
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.
Henry: I think we have to be explicit about this for interop.
Mohamed: I think we should keep these instructions simple.
Vojtech: But at least redirect should be handled.
Henry: Absolutely. Do what standard libraries do, but nothing else.
Norm: Proposal: p:document, p:load, etc. follow redirects but do not preserve cookies, etc.
Vojtech: Do we need to say
something about steps like p:xsl-formatter?
... And other steps that can perhaps store to http URIs?
Norm: I don't think PUT and POST
support redirect...
... I think we've left the ability to write output as
implementation defined for security reasons, so we don't have
to say anything.
Accepted.
Norm: The last question is, do we want to support the ability to *not* follow redirects.
Some discussion about whether or not you need to provide options for all these possible features.
Mohamed: This is related to HEAD right, which doesn't follow redirects.
Norm: If that's the case, then I'm happy to leave the option out.
Alex: The spec says that GET and HEAD MAY follow redirects.
Norm: "May"? That's not useful.
Alex: There are a whole bunch of variations here.
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.
Proposal: No such option.
Accepted.
-> http://www.w3.org/XML/XProc/2008/11/cr-comments/#C036
Norm summarizes.
Norm: Allow source/result to accept sequences by default?
Mohamed: no.
Henry: Why?
Mohamed: Because I think it's and advanced feature and you should have to explicitly enable it.
Vojtech: I'm not sure it's really necessary to restrict sequences.
Norm: I think the reason may have been because serializing a sequences isn't something you can do with vanilla XML
Vojtech: On p:pipeline you could add your own output port and then you have a pipeline with two outputs.
Norm: I think James point that this will either be an FAQ or we should change it.
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.
Mohamed: In case you're testing on an error, it'll change.
Alex: I remember this being that basically p:pipeline was supposed to be the simple case.
Straw poll: Should we change p:pipeline to allow sequences on input and output?
Unanimity for no change.
Proposal: the status quo remains, we'll make no change here.
Accepted.
-> http://www.w3.org/XML/XProc/2008/11/cr-comments/#C040
Norm summarizes.
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."
Mohamed: I agree.
Proposal: The WG will not undertake this task.
Accepted.
-> http://www.w3.org/XML/XProc/2008/11/cr-comments/#C045
Norm summarizes.
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.
... I think the thread offers several solutions that are
sufficient.
Vojtech: I agree you can, but it is a bit annoying.
Norm hypothesizes about we might do, but doesn't want to do it.
Alex: Isn't XSLT sufficient here?
Norm: I think it is.
Vojtech: It's not that simple to do, there is a little bit of work involved.
Mohamed: I think it's worth letting exproc do this.
Alex: It's not that bad.
Norm: Does anyone want to argue that we should add a step for this?
None heard.
Proposal: No change, leave the status quo.
Accepted.
-> http://www.w3.org/XML/XProc/2008/11/cr-comments/#C051
Norm summarizes.
Norm: The question, I think, is if we can impose constraints on future working groups.
Henry: I'd be surprised if that
caused a problem.
... Like all restrictive covenants, it's subject to the will of
the court at the time when someone does violate the
constraint.
Norm: So the high order bit is, there's no precedent for getting bounced because of this point.
Henry: I think that's right. You can, for example, have a namespace document that says "frozen".
Norm: Proposal: leave the status quo
Accepted.
-> http://www.w3.org/XML/XProc/2008/11/cr-comments/#C068
Norm thinks this is editorial on furthe reflection and proposes we accept it.
Proposal: Accept the change, removing err:XC0016 in favor of err:XD0019.
Accepted.
Norm: The W3C Technical Plenary
will be held in Santa Clara, CA, US, 2-6 November, 2009.
... I propose that if we're still a chartered WG in 2009, we
agree to meet there as our next f2f.
Mohamed: Any word on charters?
Norm: No, not yet. But I'm not expecting any problems.
Mohamed: If the US immegration policy will allow Europeans into the company...
Norm: Yes, tentatively, that's where we'll plan to meet.
Adjourned