See also: IRC log
No regrets given.
Norm wonders if Alex has any thoughts.
Alex: I generally like it.
Alex wonders if there are any controversial parts in the minds of others
Norm: Is there anyone on the call that thinks we shouldn't do this?
Michael: The fundamental idea seems good. Some of the special cases for defaulting are problematic.
Alex: When you have a p:pipeline, any inputs and outputs are additive, is that right?
Richard: Yes, as I framed it,
p:pipeline is just syntactic sugar for a declaration with a
p:input and a p:output.
... The advantage it gives is that there's a fully explicit syntax for things.
... If you want an abbreviated syntax, then p:pipeline is it, and the abbreviation seems to me to be very straightforward.
Alex: Can you point to a p:pipeline to import it.
Richard: I don't see why not.
In fact, you can point to all three, a p:pipeline, a p:declare-step, or a p:library.
Some discussion of the fact that this means you can point to a declare-step implemented by other means as well.
Let's consider the options in Richard's proposal:
1. How to refer to pipeline input ports within a subpipeline.
Norm: I have a preference for using the local name of the type.
Richard: That has an impact on option 3, since it will make some inputs totally unavaiable.
Alex: Why not make the type required.
Henry: You could do that, you could take 1 and 3 as a package solution.
Henry expresses a preference for requiring the type if we don't go with the absent step attribute shortcut.
Henry: The advantage of requiring all pipelines to be typed is that it means you can always import them.
Richard: And conversely, having untyped pipelines allows authors to prevent them from being reused without copying.
Mohamed: I prefer to use the local name as well. Omitting the name is just too complicated to understand.
So, for option 1, we'll use the local name of the step type.
2. Should the defaulted input and output on p:pipeline have referenceable names.
Richard: I think that if they don't have referencable names, how can you call the pipeline? That's compelling to me.
Norm: I feel a little odd because we've made the other choice elsewhere.
Richard: Yes, but no where else is it exposed externally.
Mohamed points out that you could still call them, as long as the call used the primary input port.
Richard: I think the point of the simplification is that it simplifies things for the author, it shouldn't constrain the user.
Ok, for 2, we'll use the names "source" and "result"
3. The type attribute is optional on p:pipeline.
Norm: I think at the moment I favor making it optional, the point of the default syntax is to make things simple and requiring a type you never use doesn't seem simple.
Henry: I think we should try that and see if we get pushback.
So, for 3, we leave it optional.
Norm summarizes the consequences of the choices.
Richard: I left the 'primary' off of my equivalence summary in email.
Mohamed: I'm wondering about the mandatory nature of input and output in the p:pipeline case.
Norm: I think pipelines that have no input or no output are going to be much less common.
<richard> It's not "do something extra if you want to reuse", it's "don't use this abbrevation if you want to reuse"
<scribe> ACTION: Norm to craft an editor's draft implementing these decisions [recorded in http://www.w3.org/2008/01/03-xproc-minutes.html#action01]
Norm: On closer inspection, I decided that these were editorial or clarifications.
Norm: Seems like we're done.
Henry: Time for a last call.
Richard: Do we want to introduce this renaming in a last call.
Norm muses about that.
Norm: I guess it's time to get an
editor's draft out that includes all of the decisions we've
... Anyone know of anything else that's outstanding?
Mohamed: At some point we talked about splitting the spec.
Richard: Having the step library separate, you mean?
Norm: I'll put that on the agenda for next week.