Re: Are pipelines in the same library visible to each other?

Norman Walsh wrote:
> / Jeni Tennison <jeni@jenitennison.com> was heard to say:
> | Personally, I would be happy to drop the constraint that atomic step
> | types must be defined before pipelines. The processor can still report
> | errors when it finds atomic step types that are used without being
> | defined, just has to wait until it's read everything to do so.
> 
> That suggests that you think there would be some value in allowing
> p:declare-step elements to be sprinkled throughout a pipeline or
> pipeline-library.
> 
> I like the conceptual neatness of putting them all at the top,
> independent of the fact that this means the processor sees the
> declarations first.
> 
> I like Henry's argument advanced in support of p:input*,p:output*,p:param*
> (as opposed to (p:input|p:output|p:param)*): if the order is irrelevant,
> pick one and enforce it.

I agree with that rule of thumb (see Tommie Usdin's Extreme 2002 paper 
'When "It Doesn't Matter" means "It Matters"'[1]), but I think it's 
being misapplied here. The order is not irrelevant.

I'd argue that order has meaning in programs as well as rhetoric. 
Programs aren't object serialisations, but (highly constrained) narrative.

The order I use for the templates in my XSLT stylesheets has 
significance for me. I would be upset if you rearranged them. I have a 
conventional order for the top-level elements in XSLT (like global 
parameters, variables and key definitions), but I would be very 
frustrated if XSLT constrained the order of top-level elements more than 
it does. (I'm so naughty... when it makes rhetorical sense to do so, 
rather than putting global variables at the very beginning of a 
stylesheet, I put them immediately before the template that uses them!)

So I don't think order is irrelevant in programs, and my maxim here 
would be that if there's no requirement to constrain order, then don't. 
On the content of steps, perhaps some pipelines would be easier to 
understand if I could do:

<p:pipeline>
   <p:input name="doc1">...</p:input>
   <p:param name="option-for-doc1">...</p:param>
   <p:output name="result-for-doc1">...</p:output>

   <p:input name="doc2">...</p:input>
   <p:param name="option-for-doc2">...</p:param>
   <p:output name="result-for-doc2">...</p:output>
   ...
</p:pipeline>

FWIW, this is the argument that swayed me in favour of Alex's insistence 
that the order that steps were specified within a pipeline should not 
constrain their scope.

Cheers,

Jeni

[1] 
http://www.idealliance.org/papers/extreme/proceedings/html/2002/Usdin01/EML2002Usdin01.html
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Wednesday, 21 March 2007 16:12:59 UTC