Next meeting: telcon 5 July 2007

Review of 25 June 2007 Editor's Draft

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.

Defaulting

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?

Accepted.

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?

Accepted.

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?