Re: Inputs and outputs

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| 1. We need to name the steps rather than using the kind attribute as
| the name in the reference (otherwise, what if you had two 'validate'
| steps: which one would 'validate.result' point to?). So <p:step> needs
| a name attribute.

Oh, absolutely. That was just careless on my part. I intended for them
to have names.

| 2. The <p:declare-output> and <p:output> pairings are a bit confusing.
| At the pipeline level, we have the output declaration pointing to the
| output of a step:
[...]
| At the choice level, we have the output of steps pointing to the
| output declaration:
[...]

If you look at some of the earlier examples in my first message,
you'll see that I offered that as an explicit possibility. The
important thing is that you know where the pipes go. It doesn't really
matter if the port says what pipe goes in it or the pipe says what
port it goes in (or both even).

If the consensus is to nail it down exactly one way, that is fine with
me, I just wasn't striving very hard to achieve that at the time.

| 3. I know we're not supposed to be talking about defaulting, but
| perhaps it should be possible for path in the ref attribute to default
| to starting at the enclosing p:pipeline/p:choose etc. So (using a /
| separator instead, for variety) you'd have:
|
| <p:pipeline name="pipe">
|   <!-- accept a document, a schema, and a stylesheet. -->
|   <!-- validate, transform, and return the result -->
|   <p:declare-input port="document"/>
|   <p:declare-input port="schema"/>
|   <p:declare-input port="stylesheet"/>
|   <p:declare-output port="result"/>
|
|   <p:step kind="validate" name="validate">
| |   <p:input port="document" ref="document"/>
| |   <p:input port="schema" ref="schema"/>
|     <p:output port="result"/>
|   </p:step>

I find that quite a bit more confusing, actually. (And I'm hoping that
the eventual defaulting story, if there is one, does away with more
than just a few characters in the ref attribute.)

| 4. For what it's worth, I think non-technical users will balk at
| having to include all the extra "pipework", such as declaring all the
| inputs for the choice (so that it can standalone) and having a
| bitbucket for unused inputs so that it passes static processing. I
| don't think it scales very well when you have lots of branches that
| use different inputs, or nested choices.

Yeah, I don't expect to get my way on that one, but I still think it's
nice. I think of it something like a function declaration. You
wouldn't refer to global variables from inside your function, would
you? :-)

But with a little analysis, I can probably manufacture the
declarations myself. (From the point of view of my particular
implementation, I expect to get considerable benefit from the
self-contained nature of choose.)

| Enough for now,

Thanks, Jeni!

                                        Be seeing you,
                                          norm

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