Port references (Was: Re: Syntax noodling)

Hi,

I was quite enamoured of naming steps and using some syntax to refer to 
the particular output port, as in:

 > <p:step name="p:load" xml:id="load-style">
 >   <p:input href="style.xsl"/>
 > </p:step>
 >
 > <p:step name="p:load" xml:id="load-doc">
 >   <p:input href="document.xml"/>
 > </p:step>
 >
 > <p:step name="p:xslt10" xml:id="style">
 >   <p:input ref="#load-doc/stdout"/>
 >   <p:input name="style" ref="#load-style/stdout"/>
 > </p:step>

However, I think I've decided against it. It struck me that most 
components are only going to have one output port anyway, so naming the 
steps doesn't really ease the burden on users to make up names. Also it 
places a burden on us to come up with a syntax for naming output ports, 
when users could easily use their own if they wished.

A more convoluted reason is that labelling output ports provides a 
reason for the <p:output> element. If the output ports are labelled via 
the step, we have a situation where many most <p:output> elements would 
be essentially meaningless (in that they would convey no extra 
information about the pipeline). I dislike having syntax that users are 
forced to include simply to expose the inner workings of the pipeline, 
but omitting the <p:output> (as Norm did in the above example) makes it 
look as though the step has no output. I think the pipeline ends up 
being easier to understand if the outputs are explicitly labelled.

So I prefer:

 > <p:step name="p:load">
 >   <p:input href="style.xsl"/>
 >   <p:output label="style"/>
 > </p:step>
 >
 > <p:step name="p:load">
 >   <p:input href="document.xml"/>
 >   <p:output label="doc"/>
 > </p:step>
 >
 > <p:step name="p:xslt10">
 >   <p:input ref="doc"/>
 >   <p:input name="style" ref="style"/>
 >   <p:output label="styled"/>
 > </p:step>

On the other hand, if there were a reason to name steps for other 
purposes (e.g. to refer to them when indicating out-of-band dependencies 
between steps) then I might change my mind again. :)

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Wednesday, 10 May 2006 12:28:26 UTC