Re: Variables/Parameters and Scoping

On 5/28/06, Jeni Tennison <jeni@jenitennison.com> wrote:
>
>
> Hi Mohamed,
>
> 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>

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


We should take care to make not to much innovations in the
> > first version of XProc, in order to not make the user lost :
> > imagine a pure XSLT 1.0/XPath 1.0 fan, he will be allowed to use
> > variable bounded in a nodeset in Xproc 1.0 but not in XSLT 1.0 which he
> > uses in his pipeline....
>
> Erik has already corrected this misconception, so I won't repeat what he
> said.
>
> >     I wonder if I'm misunderstanding what people mean when they say
> this. As
> >     far as I can tell, in both cases, you have to parse the XPath
> >     expression
> >     "$validity = 'partial' or $validity = 'none'" to tell that the
> condition
> >     is dependent on the 'document' input. Isn't that what people mean
> when
> >     they talk about dependency graphs?
> >
> > For my vision of dependendy graph, Conditions are just labels
> > Because the real dependence is about *documents*
> > We need to know which documents are needed in each part of the process
>
> I don't understand what you mean by "conditions are just labels", but
> let's use another example that doesn't have conditions in it:
>
>    <p:variable name="doc" context="document" select="." />
>    <p:step name="my:process">
>      ...
>      <p:param name="stylesheet-pi"
>        select="$doc/processing-instruction('xsl-stylesheet')" />
>      ...
>    </p:step>
>
> I think that this is OK under the syntax that's being proposed. Please
> someone correct me if I'm wrong.
>
> Now, my:process is dependent on 'document' because the 'stylesheet-pi'
> parameter is dependent on 'document'. The only way you can work
> that out is to look at the content of the XPath expression of the
> 'stylesheet-pi' parameter, which means you have to do some (rudimentary)
> analysis of the XPath expression.
>
> >      > And last but not least because if we handle different kind of
> >     XPath in
> >      > the future (streamable, Xpath 2.0, etc.) it will not be necessary
> to
> >      > handle all those kinds of XPath
> >
> >     I don't understand the point you're making here. Could you expand?
> >
> > AFAIK, we can usel in a single XPath 2.0 expression multiple documents.
> > So if for a V.next of XProc, we allow to use XPath 2.0, then an XProc
> > 1.0 dependency graph or designer should parse XPath 2.0 to know on which
> > documents it depends
> > I prefer to see a fallback construct which make explicit the dependency
> > about the documents
> > in the V.next, "context attribute" should then become a sequence of
> qnames
>
> You seem to be suggesting that the 'context attribute' should be a way
> of the user explicitly indicating the dependencies of XPath expressions
> on inputs, intermediate documents, parameters and variables. If it were
> to be used in that way, then you'd need a syntax like:
>
>    <p:variable name="doc" context="document" select="." />
>    <p:step name="my:process">
>      ...
>      <p:param name="stylesheet-pi" context="doc"
>        select="$document/processing-instruction('xsl-stylesheet')" />
>      ...
>    </p:step>
>
> Note the contex attribute on the <p:param> element.


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)

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]


> That's the simpler case
> >
> > Now a harder one,
> > XProc V.next.next will allow another type of path language (a streamable
> > one for example), which will have a totally different grammar (it's an
> > hypothesis)
> >
> > The context attribute will still allow XProc parser to construct a
> > dependendy graph
>
> I'm sympathetic to concerns about future versions of XProc, but (a) I
> think it's really unlikely that a future version will adopt a different
> query language without a major overhaul of the XProc syntax generally --
> if we need something like this, then we can add it then;


fair enough


and (b) if we
> did, other languages are much more likely to support the notion of
> variables than of context nodes.
>
> Cheers,
>
> Jeni
> --
> Jeni Tennison
> http://www.jenitennison.com
>
>
>
>
>


-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 8 72 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €