Re: Variables and parameters

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| Norm Walsh wrote:
|> / Jeni Tennison <jeni@jenitennison.com> was heard to say:
|> | A more flexible alternative would be to say that labelled documents are
|> | referencable as variables within the XPath expressions used to set parameters
|> | or variables.
|>
|> Yes, but it puts variables/parameters and input/output labels all into
|> the same "symbol space" which worries me a bit.
|
| It doesn't worry me. I think we want parameters and I/O labels to be in
| the same symbol space anyway so that we can support a directed syntax
| should we want to in the future.

I don't see the connection there...

|> | This is more flexible because it means that you can refer to more than one
|> | document within the XPath expression.
|>
|> Indeed. Is that valuable enough to justify the added complexity?
|
| I think it's simpler. The explanation goes:
|
|   The select attribute of p:param, p:variable, p:step/p:input and
|   p:pipeline/p:output holds an XPath expression that provides the value
|   of the parameter, variable, input or output. The value of a parameter
|   must be a string; it is set to the string value of the result of
|   evaluating the XPath expression. The value of an input or output must
|   be a node set containing only root (document) nodes [1]; it is an
|   error if the XPath evaluates to anything else.

I'm having a hard time getting my head around using select on
p:pipeline/p:output, but I think I get it.

|   When evaluating an XPath expression, the context node and the context
|   position are undefined: it is an error if the expression references
|   them [2]. The variable bindings for the expression are determined by
|   variable binding elements that precede the expression. These are:
|
|   - p:pipeline/p:input binds the variable with the name specified in the
|     name attribute to a node set containing the root (document) nodes
|     passed as that input.
|
|   - p:pipeline/p:param binds the variable with the name specified in the
|     name attribute to the (string) value passed as the value of the
|     parameter, or to the string value of the result of evaluating the
|     XPath in the select attribute if no value is passed for the
|     parameter.

Does anyone have any misgivings about requiring that parameters be strings?
Specifically, that they may not be documents?

|   - p:pipeline/p:variable binds the variable with the name specified in
|     the name attribute to the result of evaluating the XPath in the
|     select attribute.
|
|   - p:step, p:choose, p:for-each, ... bind multiple variables: one for
|     each of the <p:output> elements they contain. The variable's name is
|     given in the label attribute of <p:output> and its value is a node
|     set of root (document) nodes, determined by the component.
|
| This seems to me to be more coherent and less complex for the user than
| having to identify a single document to provide the context for an
| XPath expression each time you set a variable. It also has the
| advantage that it becomes very easy to perform XPaths over outputs and
| inputs that hold sequences of documents rather than single documents,
| for example to test whether any document contained a particular
| element:

If that's were consensus goes, I think I can probably live with it.

| [2] I think we'll want to set the context node and context position
| differently within a <p:for-each>.

Maybe, but that's not obvious to me. I had in mind that for-each would
bind an input to the first document in its input sequence and run the
steps it contains with that input. Then it would bind the input to the
second document in its input sequence and run the steps again. I didn't
expect to have XPath expressions referring directly to the current
input document inside for-each any more than elsewhere in the
pipeline.

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>

                                        Be seeing you,
                                          norm

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