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

/ ht@inf.ed.ac.uk (Henry S. Thompson) was heard to say:
| This thread just emphasises that we _must_ carefully define what the
| XPath context is for every place in our spec. where an XPath appears,
| and for component execution.
|
| If we do that, isn't your problem solved?

Well, yes and no. Yes, if we do that, the problem is solved.

Now, exactly what do we want to say is in the context?

| So, e.g., we say something like
|
|  [Wrt p:option . . . select=XPE] The XPath context for evaluation of
|  XPE has the document II of the infoset determined by the content of
|  the p:option as the current node, and all the *in-scope options* in
|  the inherited environment of the surrounding step visible as bound
|  (XPath) variables, along with appropriate bindings for p:episode and
|  p:document-position.
|
| and
|
|  [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

Why should? Why "at least"?

|  environment visible as bound (XPath) variables, along with
|  appropriate bindings for p:episode and p:document-position.

I'm happy to resolve this issue along these lines. It blurs the line
slightly between what the pipeline processor is doing and what the step
is doing (establishing the appropriate context requires quite a bit of
cooperation at the boundary), but I think it makes the expressions the
simplest to write.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | All the good maxims already exist in
http://nwalsh.com/            | the world; we just fail to apply
                              | them.-- Pascal