Re: Here's a tricky one

On 5/14/07, Norman Walsh <ndw@nwalsh.com> wrote:
> Steps that take fragments of XPath as options need to have the literal,
> uninterpreted strings passed to them. The step will interpolate them
> when it's running.

That part is fine, but what surprises me is XPath expression itself:
"$p:episode". The step receives this as a string. When it evaluates
that expression why would there be a $p:episode variable? This is not
an XPath expression evaluated by the pipeline engine, but by a
component. For this to work, the pipeline engine would need somehow to
expose the state variables to the component, and the component to
expose those states variables as XPath variables when evaluating XPath
expressions.

First, if something like this happens, it needs to be said
specifically in the specification of the relevant component. Which is
not the case right now. Second, I don't like having state variables or
options passed to components and exposed automatically as variables by
components. I prefer this to be done explicitly. Either with
parameters, or in this case by using a select so the expression is
evaluated by the pipeline engine.

This seems to be the same issue that Jeni discusses towards the end of
this message:
http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007May/0170.html

Alex
-- 
Orbeon Forms - Web 2.0 Forms for the Enterprise
http://www.orbeon.com/

Received on Monday, 14 May 2007 13:04:32 UTC