See also: IRC log
-> http://www.w3.org/XML/XProc/2007/12/13-agenda
Accepted.
-> http://www.w3.org/XML/XProc/2007/11/29-minutes
Accepted.
No regrets given.
-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments
Henry: I think the motivation is
the crucial thing.
... It felt like we still hadn't found the sweet-spot in the
relationship between pipelines, steps, and
pipeline-libraries
... The crucial observation was that it suddenly made sense to
allow declare-step to contain a subpipeline
... That's precisely what we're doing when we put
<px:somename> in a pipeline as a call to the pipeline
with the type px:somename
... It made sense to use *declare-step* to do that.
... When I worked that all through, it seemed to me to have a
number of positive consequences.
... The single residual notion as the sort-of entry level way
of wrapping a subpipeline to run it, it didn't have to have a
name.
... Giving it a name is only necessary if you want to be able
to refer to its ports.
... There are two seperable parts: 1. Put a subpipeline in
declare-step and 2. let's make reference to the enclosing
top-level artifact easy by defaulting on p:pipe.
... I think that works very neatly, but its seperable from the
other proposal.
Norm: My big concern was the fact the you couldn't import two simple pipelines anymore, because there'd be a name clash.
Henry: We could (1) add an
optional name to p:pipeline, but that still doesn't help if you
don't own the pipeline.
... Or (2) alow a type attribute on p:import that is the type
of a naked imported pipeline.
... or an error if the imported library doesn't include it.
Norm: If we went with type, I think I'd want it to be an error if you don't import a naked pipeline.
Henry: Or you can workaround it with a really tedious set of nested libraries.
Some discussion
Norm: The other concern I have is much harder to quantify: are we making the language more like a static compile/run language and less dynamic and is it going to piss off our audience.
Richard: there isn't a pipeline and a declare-step for the pipeline, it's one or the other.
Henry observes that the type/p:import trick would bungle an attempt to import a recursive pipeline.
Alex: I don't see why requiring the p:declare-step in the recursive case is such a big deal.
Norm: I'm not *sure* it is, it just changes the way the language feels.
Richard: I thought we were going
to get rid of p:pipeline altogether, just putting them all in
p:declare-steps.
... Then we put pipeline back in as an abbreviation for a
common case of a declare-stpe with a subpipeline in it.
... We can then fiddle with what the abbreviation means to make
the common cases we care about easy.
... If you do it in those two stages, it seems more plausible
to me.
Norm: There's no point in repeating myself: there's a sense in which this makes the language feel more like java and less like a scrypting language and that worries me.
Henry: A question of how much a discontinuity arises when you want to write a recursive pipeline is an open question.
Alex: What if a pipeline is allowed to have a type declared. And you have to do that to use recursion.
Richard: If we made pipeline just be an abbreviation in that way, the only thing we've really changed is that you write pipelines with p:declare-step when you put them in libraries.
Henry: I get confused about what the state of play is wrt what attributes are allowed on p:pipeline at the moment.
Alex: It also fixes the defaulting problem for inputs and outputs of pipelines.
Henry: The other consequence is
that we could get rid of the situation where p:pipeline has
both an optional name and an optional type.
... Our users are never going to be anything other than
confused by that.
Norm: The way that was rectified was by allowing p:pipe to have no step and that means the enclosing pipeline.
Some discussion of the proposal that Norm had made earlier
Alex: I'd have to think about the defaulting story a bit more.
Richard: The thing that Henry's proposing isn't really defaulting, it's like giving the name of the pipeline the name "" and just letting you not say that.
Alessandro: I think it would help if someone could consolidate the proposal and post it with some examples. My reluctance now is coming more from lack of understanding that something being wrong with it.
Henry: I'll do that over the next 24 hours.
Norm: I think so.
Richard: The reason why it came up was that one branch had an XSLT and the other had Identity, so that doesn't work.
Norm: Yes, I see how that might be tedious.
Richard: Because you're allowed
to hook sequences to non-sequences, it doesn't really matter to
the implementor.
... We could say that if any branch produces a sequence, then
the p:choose does.
Norm: I can live with that.
Proposal: We accept Richard's suggestion above, an output of a choose or try is a sequence if any of the branches produces a sequence on that port.
Accepted.
Richard: I think Norm's right, it inherits the properties of the output on the last step.
Accepted.
Richard: The only effect that declaring something sequence=false has is that it prevents a sequence from slipping through.
Richard: We really did mean that the pipeline can inside the viewport can only have one output.
Norm: Yes, we meant that.
This is a significant editorial issue, but not a technical one.
The subpipeline must have one output and the result can be a sequence.
Richard: I think there may be similar editorial problems with p:for-each
The version was absent by mistake and yes, the XML decl should be present
Norm: Yes, they should be static.
Accepted.
None.