Re: Naming steps or naming outputs

/ Alessandro Vernet <avernet@orbeon.com> was heard to say:
[...]
| Say you read a document, validate it, transform it, and save it. It
| makes more sense to give name to the steps (read, validate, transform)
| rather than the outputs of the steps (document-read,
| document-validated, document-transformed).
|
| With the pipe construct, we wouldn't have to name anything in the
| those linear cases. So we are left with the other cases, where in my
| experience it is more natural to name outputs.

I hope that we wind up with a syntax where it is possible to be fully
explicit, to say what all the inputs and outputs are without any
defaulting or implicit links.

If we agree that that's a goal, I'd be inclined to try to devise that
syntax and come back to the question of what sort of defaulting we can
do to make the pipeline documents shorter. Partly, I'll admit, this is
because I'm not convinced that making inputs or outputs implicit
simply to make the pipeline document shorter is really a valuable
goal. That said, I'm also not sure how it works, if it is a goal.

| d) Having both <with-input> and <with-output> is more consistent and
| more explicit. It is easier for someone who reads the pipeline to
| understand what the input/outputs of each step are.
|
| Am I missing something?

No, I don't think so. I can see both sides of this issue and don't
have a good answer for which is better.

Like the question of whether we use <p:step type="xslt"> or <p:xslt>,
it's on the one hand not technically important which decision we make,
as I'm sure we can all see that they're essentially isomorphic. And on
the other, deeply important because it has a dramatic impact on the
syntax.

I wonder if we should simply pick one and try to press forward,
agreeing that we might come back and try the other one after we've
worked out some of the deeper technical issues.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.