ease of use - allow p:variable scoped to step

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

ease of use - allow p:variable scoped to step

James Fuller-2
--
Another in the 'ease of use' category is the possibility for loosening
the rules of where one can define a p:variable so it easier to scope it
to a step.

Romain Deltour's email [1] motivated the WG to consider how we could achieve
this, taking his p:group as an example for discussion.

<p:group>
  <p:variable name=“count” select=“count(//elem)”>
    <p:pipe step=“earlier-step” port=“result” />
  </p:variable>
  <px:my-step option=“fx:function($count)” />
</p:group>

One approach was the idea of allowing a p:variable to be defined as a
child within the step itself. One could imagine the following
construction;

<px:my-step>
    <p:variable name="count" select="count(//elem)"/>
    <p:with-option name="option" select="fx:function($count)"/>
</px:my-step>

where the p:variable would automatically connect to the primary input
port and use that as its context for the select xpath. One would still
be free to use a p:pipe to explicitly choose some other step/port.  

At first glance this seems to neatly address scoping a variable to a step
though admittedly things get a bit slippery after that, for example
using avt in options could look a bit strange.

<px:my-step option="fx:function($count)">
    <p:variable name="count" select="count(//elem)"/>
</px:my-step>

Where it 'looks' like the p:variable is defined after the option is
declared. Maybe thats not such a big deal.

To make things potentially more complicated (and very much shooting from my own
hip) one could envisage some kind of shortcut for defining a p:variable
using attributes on the step itself.

<px:my-step count="count(//elem)" option="fx:function($count)"/>

which would be semantically equiv. to the previous examples.

One would have to use the more explicit p:variable to use a variable
named the same as an option ... which reminds me that the rules for
shadowing and precedence would all need to be worked out (along with
other details).

In summary, I think there is value in this line of enquiry though a bit
unsure how far we go.

thoughts ?

Jim Fuller



[1]- http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2014Nov/0021.html

Reply | Threaded
Open this post in threaded view
|

Re: ease of use - allow p:variable scoped to step

Romain Deltour
+1, great to see progress in that direction!

I feel that the shortcut solution may be too confusing (it makes it hard to read what's an option and what's a variable, without extensive knowledge of the step signature). Maybe feasible with a namespaced attribute.
I'm not too worried about the "reading order" issue when AVTs come to play anyway, I still find it quite readable.

Side question: will the XPath context change in v2 to allow reading from an sequence output port ? Is there any reason why the default collection of the dynamic context is not set to the sequence of docs ? I suspect streaming is the answer, but I'm wondering if that limitation can be somehow loosened.

Romain.

Le 26 nov. 2014 à 20:09, Jim Fuller a écrit :

> --
> Another in the 'ease of use' category is the possibility for loosening
> the rules of where one can define a p:variable so it easier to scope it
> to a step.
>
> Romain Deltour's email [1] motivated the WG to consider how we could achieve
> this, taking his p:group as an example for discussion.
>
> <p:group>
>  <p:variable name=“count” select=“count(//elem)”>
>    <p:pipe step=“earlier-step” port=“result” />
>  </p:variable>
>  <px:my-step option=“fx:function($count)” />
> </p:group>
>
> One approach was the idea of allowing a p:variable to be defined as a
> child within the step itself. One could imagine the following
> construction;
>
> <px:my-step>
>    <p:variable name="count" select="count(//elem)"/>
>    <p:with-option name="option" select="fx:function($count)"/>
> </px:my-step>
>
> where the p:variable would automatically connect to the primary input
> port and use that as its context for the select xpath. One would still
> be free to use a p:pipe to explicitly choose some other step/port.  
>
> At first glance this seems to neatly address scoping a variable to a step
> though admittedly things get a bit slippery after that, for example
> using avt in options could look a bit strange.
>
> <px:my-step option="fx:function($count)">
>    <p:variable name="count" select="count(//elem)"/>
> </px:my-step>
>
> Where it 'looks' like the p:variable is defined after the option is
> declared. Maybe thats not such a big deal.
>
> To make things potentially more complicated (and very much shooting from my own
> hip) one could envisage some kind of shortcut for defining a p:variable
> using attributes on the step itself.
>
> <px:my-step count="count(//elem)" option="fx:function($count)"/>
>
> which would be semantically equiv. to the previous examples.
>
> One would have to use the more explicit p:variable to use a variable
> named the same as an option ... which reminds me that the rules for
> shadowing and precedence would all need to be worked out (along with
> other details).
>
> In summary, I think there is value in this line of enquiry though a bit
> unsure how far we go.
>
> thoughts ?
>
> Jim Fuller
>
>
>
> [1]- http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2014Nov/0021.html
>