Re: Variables and parameters

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| If parameter/variable names are in a different symbol space from
| inputs/outputs then we are allowing a situation where a parameter can
| have the same name as an input. For example:

Ah, yes.

|> I'm having a hard time getting my head around using select on
|> p:pipeline/p:output, but I think I get it.
|
| It's funny, I found it hard to get my head around p:pipeline/p:output
| being referenced by the final p:step/p:output. As Richard pointed out
| some time ago, the links between the ports could be represented in
| either direction. I think it makes more sense for *all* the step
| outputs to be referenced (thus having the pipeline output doing the
| referencing) rather than having some step outputs being referenced and
| some doing the referencing. I think it makes it easier to add steps at
| the end of the pipeline, and to create pipelines where an output is
| both a final output and an intermediate output.

Yes, I like the idea of having a consistent story about which
direction the arrows point.

| If parameters could be documents then I'd be left wondering what the
| difference was between an input document and a parameter document? Are
| there additional restrictions, such as parameter documents being
| static (not generated by the pipeline)? Or perhaps parameters can be
| left unset (and have a default) whereas inputs can't?

Yes, I think those are the two areas where we'd have to say something.
Actually, I'd be inclined to allow parameter documents to be generated
by the pipeline. The only distinction would be that parameters would
be optional.

The use case that keeps me wishing half-heartedly for parameter
documents is this one:

  <p:step name="xslt">
    <p:input name="document" ref="$input"/>
    <p:input name="stylesheet" href="style.xsl"/>
    <p:output name="result" label="result"/>
    <p:param name="parameters">
      <xsl:param name="base.dir" select="'/tmp'"/>
      <xsl:param name="chunk" select="1"/>
    </p:param>
  </p:step>

But maybe there are better ways to solve that problem.

|> I had in mind something like this:
|>
|>   <p:step name="xslt">
|>      ...
|>      <p:output name="result" label="styled-docs"/>
|>   </p:step>
|>
|>   <p:for-each ref="styled-docs">
|>     <p:input name="document" label="doc"/>
|>     <p:output name="result" label="result"/>
|>
|>     <p:step name="tidy">
|>       <p:input name="document" ref="doc"/>
|>       <p:output name="result" label="result"/>
|>     </p:step>
|>   </p:for-each>
|
| I'd be happy with that too, although I do think that having to declare
| the inputs/outputs of <p:for-each> (and the other flow-control
| elements) is a bit tedious.

I agree, but it makes them self-contained which feels like an awfully
nice feature. Especially if you consider reusing bits of pipeline.

| Presumably with the above syntax it's always the first input that gets
| bound to the individual documents in the selected document sequence?

I expect it's the input named "document". I don't want the relative
order of inputs/outputs/parameters to be relevant if we can avoid it.

| And presumably the outputs get set to the concatenation of the outputs
| they reference?

Yes, that's part of the semantic of for-each.

                                        Be seeing you,
                                          norm

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