Re: Parameters and options

On 4/16/07, Norman Walsh <Norman.Walsh@sun.com> wrote:
>
> Consider:
>
>   <p:declare-step type="px:debug">
>     <p:parameter name="*"/>
>     <p:option name="opt1"/>
>     <p:option name="opt2"/>
>   </p:declare>
>
> Then, I believe our intent is that the following is legal:
>
>   <p:load name='loader'>
>     <p:input port="source">
>       <p:inline>
>         <doc/>
>       </p:inline>
>     </p:input>
>   </p:load>
>
>   <px:debug>
>     <p:parameter name="elemcountplus1" select="$elemcount+1"/>
>     <p:parameter name="elemcount" select="count(//*)">
>       <p:pipe step="loader" port="result"/>
>     </p:parameter>
>   </px:debug>
>
> And it's up to implementations to make sure that parameters get
> evaluated in the right order and that there are no circular
> dependencies. (In this case, elemcount=1 and elemcountplus1=2.)
>
> I assume that options and parameters are in entirely different
> namespaces, so:
>
>   <px:debug>
>     <p:parameter name="opt1" value="3"/>
>     <p:parameter name="opt2" select="$opt1+1"/>
>     <p:option name="opt1" value="5"/>
>     <p:option name="opt2" value="$opt1+1"/>
>   </px:debug>
>
> Means the px:debug component gets two parameters, opt1 and opt2, with
> the values 3 and 4, respectively, and two options, opt1 and opt2, with
> the values 5 and 6, respectively.



I would prefer it that sibling parameter values are not available as
variables
inside other XPath expressions.  They should only be available to
expressions
on children.

Then to do the above, you'd have wrap it in a p:group.


-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics