W3C

- DRAFT -

XML Processing Model WG

Meeting 135, 29 Jan 2009

Agenda

See also: IRC log

Attendees

Present
Norm, Vojtech, Alex, Henry, Mohamed
Regrets
Paul
Chair
Norm
Scribe
Norm

Contents


Accept this agenda?

-> http://www.w3.org/XML/XProc/2009/01/29-agenda

Accepted.

Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2009/01/22-minutes

Accepted.

Next meeting: telcon 5 Feb 2009?

No regrets given.

Review of Widgets 1.0: Packaging and Configuration

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

074. Select expression in input declaration

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

026. New http-request test

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

036. Multiple inputs/outputs

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

040. Schematron for XProc validation

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

045. Using p:variable

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

051. 2.13 flawed?

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

068. err:XC0016 and err:XD019

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

Any other business?

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

Summary of Action Items

[NEW] 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]
[NEW] ACTION: Norm to clarify when the select applies. [recorded in http://www.w3.org/2009/01/29-xproc-minutes.html#action02]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2009/01/29 19:10:21 $