Re: What can a step implementation ask the pipeline processor?

/ Alessandro Vernet <avernet@orbeon.com> was heard to say:
| On 5/22/07, Norman Walsh <ndw@nwalsh.com> wrote:
|> Having the options available to the XSLT step as variables through the
|> XPath context wouldn't have any effect on the variables or parameters
|> available to the stylesheet. The XSLT spec specifies the initial context
|> for stylesheet evaluation.
|
| I was commenting on the following:
|
| On 5/17/07, Henry S. Thompson <ht@inf.ed.ac.uk> wrote:
|>  [Wrt step implementations] The XPath context for evaluation of
|>  user-authored xpath expressions evaluated by step implementations
|>  SHOULD include at least all the *in-scope options* in the step
|>  environment visible as bound (XPath) variables, along with
|>  appropriate bindings for p:episode and p:document-position.
|
| To me, this is saying that when a step evaluates an XPath expression,
| options available in the scope for that step are exposed as variables
| to the XPath expression. So if an XSLT step evaluates an XPath
| expression $foo, and that the pipeline has a foo option, then that
| $foo evaluates to the value of the option.

That would be true if the XSLT step evaluated any XPath expressions, but
it doesn't. It transforms an input document with an XSLT stylesheet and
that stylesheet starts with the XPath context as defined in the XSLT
Recommendation which doesn't say anything about any inherited context.

I think I understand your concern (and I agree with you: the options
that are available as in-scope variables in the XPath context passed
to an XSLT step must not contribute to the default values of parameters
or variables used by the stylesheet that the step uses to transform
its input), but I don't think it actually applies to the XSLT step.

Consider the p:episode() function: no stylesheet can possibly use that
function (even though it's passed to the step) because functions that
the XSLT stylesheet can use have to be declared in the stylesheet.

| I don't like this, and hopefully I am misreading Henry's comment.
|
|> I'd like to avoid making the availability of the options conditional
|> if at all possible.
|
| I don't think that it is "availability" that matters. What matter is
| if the step expose options to XPath expression or not, and how
| (variables vs. function).

That's what I meant by availability.

I think the spec should say "The [whatever we decide] are made available
to steps evaluated by the pipeline".

I *do not* want to have to say "The [whatever we decide] are made
available to p:matching-documents, p:insert, p:delete, etc. steps
evaluated by the pipeline but not to p:xslt1, p:xslt2, etc. steps"

Above and beyond the fact that this would be confusing, it would also
mean that any extension steps would have to be able to declare whether
or not they expeced those bindings to be in effect.

I like Henry's proposal and I don't think it introduces any negative
consequences in practice.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | You look wise. Pray correct that
http://nwalsh.com/            | error.--Charles Lamb