Re: Variables/Parameters and Scoping

Hi Mohamed,

Innovimax SARL wrote:
> On 5/28/06, *Jeni Tennison* <jeni@jenitennison.com 
> <mailto:jeni@jenitennison.com>> wrote:
>     Innovimax SARL wrote:
>      > Ok, you're right, it is an valid XPath 1.0 expression, but not a
>     *usual*
>      > XPath 1.0/XSLT 1.0 construction, because the variable is a
>     "result tree
>      > fragment" and cannot be bound to a nodeset in XSLT 1.0 (but in
>     XSLT 1.1
>      > and later). 
> 
> Again, I wrote it too fast
> I wanted too say << because the variable COULD be a "result tree 
> fragment" >>
> in the case of an inline document like this as already been proposed by 
> Norm in [1]
> 
>  <p:step name="p:xslt">
>     <p:input name="document">
>       <doc>
>        <p>Some data</p>
>       </doc>
>     </p:input>

This would only result in a result tree fragment if that's how we 
defined <p:input> to work. I'd strongly suggest that we said that if 
there was (an element) content to <p:input> then the input was set to a 
new document with a copy of the content of <p:input> as the content of 
the document. We don't have any need for the concept of "result tree 
fragments" (which are a purely XSLT 1.0 invention).

> And another problem for me is that, it was said that variable in Xproc 
> could be only Strings....so I cannot understand how they could be bound 
> to NodeSet !!
> 
> [1] 
> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Apr/0067.html 

[I think that you've referenced the wrong mail here: I can't see 
anything in this mail that talks about the values of variables (it's a 
mail about directed vs. generic syntax).]

I think that we've agreed that *parameters* should only take string 
values, but have said nothing about the values that XProc variables can 
be set to. I think it would be a mistake to allow them to only be bound 
to strings, because it's quite common to want to set a variable to an 
element and set other variables (or parameters) based on information 
about that element.

For example [here using your favoured syntax]:

   <p:variable name="glyphInfo" context="manifest"
               select="/glyphs_manifest/glyph[@filename = $filename]" />
   <p:variable name="glyphMnemonic"
               select="$glyphInfo/@mnemonic_string" />
   <p:variable name="glyphHeight"
               select="$glyphInfo/@height" />

It would be a lot more tedious to have to write:

   <p:variable name="glyphMnemonic" context="manifest"
               select="/glyphs_manifest
                         /glyph[@filename = $filename]
                           /@mnemonic_string" />
   <p:variable name="glyphHeight" context="manifest"
               select="/glyphs_manifest
                         /glyph[@filename = $filename]
                           /@height" />

In any case, even if the values of XProc variables (defined with 
<p:variable>) elements can only be set to strings, this has no bearing 
on whether we use <p:input> to bind XPath variables to node-sets (of 
root nodes).

> In fact that's why i'm againt use of  $var construct
>  
> because instead of making a $var and using it a lot latter
> 
> I would wrote it, without variable,
> <p:step name="my:process">
>  ...
>    <p:param name="stylesheet-pi" context="doc" 
> select="/processing-instruction('xsl-stylesheet')" />
>  ...
> </p:step>
> 
> which is for me a lot clearer (as user and as implementor)

OK, here's a more realistic example in your favoured syntax:

   <p:choose>
     <p:input name="input" ref="document" />
     <p:output name="output" ref="result" />
     <p:variable name="xsl-stylesheet-pi"
                 uses="input"
                 select="/processing-instruction('xsl-stylesheet-pi')" />
     <p:variable name="stylesheet-type-data"
                 uses="xsl-stylesheet-pi"
                 select="substring-after($xsl-stylesheet-pi, 'type=')" />
     <p:variable name="stylesheet-type-quote"
                 uses="stylesheet-type-data"
                 select="substring($stylesheet-type-data, 1, 1)" />
     <p:variable name="stylesheet-type"
                 uses="stylesheet-type-data stylesheet-type-quote"
                 select="substring-before(
                           substring($stylesheet-type-data, 2),
                           $stylesheet-type-quote" />
     <p:when uses="stylesheet-type"
             test="$stylesheet-type = 'text/xsl'">
       <p:variable name="stylesheet-href-data"
                   uses="xsl-stylesheet-pi"
                   select="substring-after($xsl-stylesheet-pi,
                                           'href=')" />
       <p:variable name="stylesheet-href-quote"
                   uses="stylesheet-href-data"
                   select="substring($stylesheet-href-data, 1, 1)" />
       <p:variable name="stylesheet-href"
                   uses="stylesheet-href-data stylesheet-href-quote"
                   select="substring-before(
                             substring($stylesheet-href-data, 2),
                             $stylesheet-href-quote)" />
       <p:step name="p:load">
         <p:param name="href" uses="stylesheet-href"
                  select="$stylesheet-href" />
         <p:output name="output" label="stylesheet" />
       </p:step>
       <p:step name="p:xslt">
         <p:input name="input" ref="input" />
         <p:input name="stylesheet" ref="stylesheet" />
         <p:output name="output" label="result" />
       </p:step>
     </p:when>
     <p:otherwise>
       <p:step name="p:xslt">
         <p:input name="input" ref="input" />
         <p:input name="stylesheet" href="default.xsl" />
         <p:output name="output" label="result" />
       </p:step>
     </p:otherwise>
   </p:choose>

If you really don't think that the uses attributes in the above are an 
unnecessary burden on users then we'll have to agree to differ.

>     I understand that we want to make things simple for the implementation,
>     but I think forcing the user to make the dependencies explicit is a
>     real
>     burden on the user for something that's relatively easy for the
>     implementation to work out for itself (all the implementation needs to
>     do is match the XPath expression with the regular expression
> 
>        ([^$'"]|('[^']*')|("[^"]*"))*\$(\i\c*) 
> 
>     and get the values of the fourth subexpression of each of the matches).
>     Generally, I am against forcing the user to make explicit things that
>     the implementation can work out for itself.
> 
> 
> I'm not sure a simple regex will be sufficient and what about case like
> $a/b[@d=$b/@d and @e=$c/@e]

Please see the attached XSLT 2.0 stylesheet, which takes an XPath 
expression as a 'xpath' parameter and gives you a list of the variables 
on which the XPath depends. It uses the regular expression that I gave 
above to identify the variable references in the XPath expression.

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com