Re: Variables/Parameters and Scoping

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). 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.

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.

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

Received on Sunday, 28 May 2006 11:51:09 UTC