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

+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
>

Received on Thursday, 27 November 2014 10:48:19 UTC