XML Processing Model WG

Meeting 73, 28 Jun 2007


See also: IRC log


Norm, Henry, Alessandro, Rui, Paul, Richard, Andrew, Alex


Accept this agenda?

-> http://www.w3.org/XML/XProc/2007/06/28-agenda

Norm suggests discussing the defaulting story after review of the editor's draft


Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2007/06/21-minutes


Next meeting: telcon 5 July 2007

Richard give regrets for the next three weeks

Review of 25 June 2007 Editor's Draft

-> http://www.w3.org/XML/XProc/docs/langspec.html

Henry: I had one comment, but it probably comes up on the defaulting thread.
... In section 2, it says "each step declares its input and output ports"
... that's not true, they have bindings, but not declarations.
... editorially, I think it might be good to distinguish between steps and types of steps somewhere around here.

Norm: It sounds like it might be a little premature to publish this draft.

Henry: Assuming that whatever we decide about defaulting is judged by the editor to be straightforward, I'd be prepared to do a New Orleans vote for next week.

Norm: Yeah, maybe that's the way to go.
... So can we assume that we'll publish this draft, plus any defaulting story, next Friday if there are no objections.

No objections.

Paul: When's last call?

Some discussion of scheduling; Henry, Richard out for July

Henry: I'm happy to go to last call before I return.

Norm: Let's aim to have the last call go/no go vote on 26 July

Henry: I suggest a New Orlean's vote on the 26th too

More discussion

Last call before Extreme, CR in August, PR in September, if we have enough impls.


-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Jun/0171.html

Richard reviews the proposal

Richard: Only default inputs and outputs get connected up automatically.
... A disadvantage of defaulting in general is that it allows you to make mistakes.

Norm: How do folks feel about that?


Norm: A pipeline with no declared inputs gets a default one if the first step needs one.

Richard: Right. If you want a pipeline with no inputs, make sure the first step doesn't have an unbound default input.
... We do a similar thing for outputs.
... Unconnected default output on the last step becomes the pipeline output.
... We also propose that other default outputs not be left unconnected.
... The store component, for example, would be declared not to have a default output.
... So you'd have to connect that up exlicitly.

Henry: Inputs and outputs and defaulting are now completely symmetrical.
... A single input/output is the default, otherwise you have to specify.

Richard: I think this natural. The thing you think of as flowing through the pipeline will usually flow throw the default inputs and outputs.

<Zakim> ht, you wanted to request an independent decision about what, if it's allowed, is meant by "<p:input port="..."/>

Norm: Does anyone object to the proposal so far?


Henry: The first separable question is, should we continue to allow inputs with no bindings, and what should it mean?
... I think there are two choices: given that if you want an empty sequence, you write <p:empty>.
... First is, it's an error. You must give an input content.
... Alternatively, it means give me the default readable port.
... I marginally prefer the latter.

Richard: It let's you bind to the preceding step without using its name.

Henry: Ok.

Norm: I'm ok with this and I think it should bind to the default readable port.
... Anyone object to connecting a named, but unbound, input port to the default readable port?


<Zakim> ht, you wanted to suggest treating all containers alike wrt missing outputs

<ht> <p:pipeline><p:xinclude/></p:pipeline>

Henry: It seems like what we've said about pipelines ought to also work for other compound steps.

<ht> <p:choose><p:when test="..."><p:xinclude/></p:when><p:otherwise><p:identity/></p:pipeline>

Norm: I'm worried a little bit about the complexity of our story, but I do agree.

Henry: So I propose that we allow compound steps to get a default output.

Some discussion.

Henry: The names and cardinalities should remain the same, this is only for the case where none of the branches declare any outputs.

Norm: If any branch declares an output then they all have to declare them the same.

Henry: The spec should say that they all have to be the same.

Richard: What about the case where choose has multiple outputs because all of the branches have multiple outputs.

Henry: They must all be the same.

Norm: Any objections to this proposal?


<Zakim> Norm, you wanted to reintroduce p:sink

Norm: Can we p:sink, please?

Henry: Yes.
... Although it is the case that p:store could be used for this purpose if we invented a /dev/null URI, but it would be harder to optimize.

Richard: We now have possibility of pipelines themselves with unnamed inputs and outputs. It will be a question for implementations how they connect these up?

Norm: Anyone object to p:sink?


Proposal to add "group-by" option to p:wrap

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

Henry: I made a proposal, I stand by it.
... I know that Mohamed wants a subsidary XPath that identifies what you can ignore.
... I think that's the wrong end of the 80/20.

Norm: We can add that later, if we're convinced.
... Any objections to Henry's proposal?


Wrapper name in p:wrap-sequence?

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Jun/0190.html

Norm: We ought to make the wrapper a QName.

Alex: Yes.

Norm: Any objections?



-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Jun/0198.html

Norm outlines the state of play as he understands it.

Norm: I think we should make it explicitly allowed.
... Any objections?


Any other business?



Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/07/05 17:39:36 $