See also: IRC log
-> http://www.w3.org/XML/XProc/2007/06/28-agenda
Norm suggests discussing the defaulting story after review of the editor's draft
Accepted.
-> http://www.w3.org/XML/XProc/2007/06/21-minutes
Accepted.
Richard give regrets for the next three weeks
-> 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?
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?
Accepted.
<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?
Accepted.
<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?
Accepted.
-> 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?
Accepted.
-> 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?
Accepted.
-> 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?
Accepted.
None.
Adjourned