See also: IRC log
Norm suggests discussing the defaulting story after review of the editor's draft
Richard give regrets for the next three weeks
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
... So can we assume that we'll publish this draft, plus any defaulting story, next Friday if there are 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
Last call before Extreme, CR in August, PR in September, if we have enough impls.
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.
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
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.
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?
... 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?
Henry: I made a proposal, I stand
... 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
... Any objections to Henry's proposal?
Norm: We ought to make the wrapper a QName.
Norm: Any objections?
Norm outlines the state of play as he understands it.
Norm: I think we should make it
... Any objections?