Re: Variables/Parameters and Scoping

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
[...]
|> | This would not allow an expression that uses *both* input-1 and
|> | input-2, hence the proposal of introducing a function instead of the
|> | 'labelref' attribute (similar to the instance() function introduced by
|> | XForms):
|> |
|> |    <p:step>
|> |        <p:with-parm name="a" select="expression using
|> |            label('input-1') and label('input-2')"/>
|> |    </p:step>
|>
|> One of the reasons that I favor the approach of naming the document
|> with a separate attribute is that it prevents expressions with this
|> level of complexity.
|
| I don't get it: as you point out, users can still build expressions
| that are precisely this computationally complex:
|
|>   <p:variable name="a1" document="input-1" select="expr1"/>
|>   <p:variable name="a2" document="input-2" select="expr2"/>
|>   <p:with-param name="a" select="expression using $a1 and $a2"/>
|
| Is it that you just don't want to let them do it with a simple syntax?!?

My overriding concern is simplicity of design and implementation. I
want the simplest thing that could possibly get the job done 80% of
the time.

I think evaluating an XPath expression over a single document is
simpler. And I think it's all that's needed 80% of the time. And
there's an obvious way to deal with the other 20%.

If we say that XPaths are evaluated in the context of a single
document, then the XPath evaluator can be thought of as a little black
box. You pass it a document and an expression and it returns
something. (Granted, you have to replace variable and parameter
references with their current literal values before you call the black
box.)

If we introduce a mechanism that allows XPath expressions to refer to
multiple documents then the XPath evaluation has to be done by some
part of the system that has much more intimate knowledge of the state
of the pipeline execution, of the documents that are currently
identified by labels, and how to get access to them.

|>   <p:with-param name="otherName" select="otherExpression"/>
|>
|> Sets the parameter $otherName to the result of evaluating
|> otherExpression with the context node set to an empty document node.
|
| It seems a bit of a hack to have the context node set to an empty
| document node. I'd rather make it an error to reference the context
| node/position/size in this case (this is what happens in XPath 2.0
| when the context item is a undefined).

Yeah, I like that better.

                                        Be seeing you,
                                          norm

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