RE: Relax p:variable restrictions

Hi Norm,

Trying to get closer to xsl:variable. Nice.

I am not sure about the need for rule 4, though. The moving of steps is an internal detail. In your last example, the two ex:foo variables have the same name, but they are actually two *different* variables (as I infer from the text of rule 4). With that in mind, I can imagine an implementation that assigns variables internal unique ids which makes it then possible to move steps and/or variables around (with restrictions given by the dependency graph, of course) without introducing lexical scoping problems. A less sophisticated implementation might be more conservative when reordering steps that depend on variables - but that is fine.

Regards,
Vojtech

--
Vojtech Toman
Consultant Software Engineer
EMC | Information Intelligence Group
vojtech.toman@emc.com
http://developer.emc.com/xmltech


> -----Original Message-----
> From: Norman Walsh [mailto:ndw@nwalsh.com]
> Sent: Monday, September 30, 2013 3:39 PM
> To: public-xml-processing-model-wg@w3.org
> Subject: Relax p:variable restrictions
> 
> Hi folks,
> 
> In line with our focus on usability, I think we should relax the
> restriction that p:variable can only occur at the top a subpipeline. We
> did it so that implementors would not have to analyze every XPath
> expression for variable references. I propose new rules:
> 
> 1. p:variable can go anywhere a step can go 2. p:variables are
> lexically scoped in the obvious way 3. It's an error if the xpath-
> context of a p:variable relies, directly
>    or indirectly, on the output from any step that uses the variable 4.
> It's an error if reordering the steps in the pipeline moves any step
>    into the "shadow" of a different variable with the same name
>    (breaks the lexical scoping)
> 5. p:variables are invisible for the purposes of computing the default
>    readable port
> 
> Assume for the moment that p:identity has a 'ref' option. Consider:
> 
>   <p:variable name="ex:foo" select="1">
>     <p:xpath-context><p:empty/></p:xpath-context>
>   </p:variable>
> 
>   <p:identity name="one" ref="{$ex:foo}"/>
> 
>   <p:variable name="ex:foo" select="2">
>     <p:xpath-context><p:empty/></p:xpath-context>
>   </p:variable>
> 
>   <p:identity name="two" ref="{$ex:foo}"/>
> 
> The identity named 'one' sees ref=1, the identity named 'two' sees
> ref=2.
> 
>   <p:variable name="ex:foo" select="1">
>     <p:xpath-context><p:pipe name='two'/></p:xpath-context>
>   </p:variable>
> 
>   <p:identity name="one" ref="{$ex:foo}"/>
> 
>   <p:variable name="ex:foo" select="2">
>     <p:xpath-context><p:empty/></p:xpath-context>
>   </p:variable>
> 
>   <p:identity name="two" ref="{$ex:foo}"/>
> 
> Error: The first ex:foo indirectly depends on the output of the
> identity step that uses it.
> 
>   <p:variable name="ex:foo" select="1">
>     <p:xpath-context><p:empty/></p:xpath-context>
>   </p:variable>
> 
>   <p:identity name="one" ref="{$ex:foo}">
>     <p:input port="source">
>       <p:pipe step="two"/>
>     </p:input>
>   </p:identity>
> 
>   <p:variable name="ex:foo" select="2">
>     <p:xpath-context><p:empty/></p:xpath-context>
>   </p:variable>
> 
>   <p:identity name="two" ref="{$ex:foo}">
>     <p:input port="source">
>       <p:inline><doc/></p:inline>
>     </p:input>
>   </p:identity>
> 
> Error. Step 'one' has to be "moved" to after 'two'. That moves it into
> an area with a different lexical $ex:foo.
> 
>                                         Be seeing you,
>                                           norm
> 
> --
> Norman Walsh
> Lead Engineer
> MarkLogic Corporation
> Phone: +1 512 761 6676
> www.marklogic.com

Received on Monday, 30 September 2013 14:36:57 UTC