Re: Variables/Parameters and Scoping

Hi Jeni,

On 5/26/06, Jeni Tennison <jeni@jenitennison.com> wrote:
>
>
> Hi Mohamed,
>
> > On 5/26/06, *Jeni Tennison* <jeni@jenitennison.com
> > <mailto:jeni@jenitennison.com>> wrote:
> >
> >     Doesn't:
> >
> >        <p:variable name="validity" context="document"
> >                    select="/*/@validity" />
> >        <p:when test="$validity = 'partial' or $validity = 'none'">
> >          ...
> >        </p:when>
> >
> >     provide just the same challenges for the implementation, in terms of
> >     tracking dependencies through XPaths and keeping documents in
> >     memory, as:
> >
> >        <p:variable name="validity" select="$document/*/@validity" />
> >        <p:when test="$validity = 'partial' or $validity = 'none'">
> >          ...
> >        </p:when>
> >
> > As Richard pointed this out in last telcon, I'm in favor of the first
> > notation
> > First, because the second is NOT a valid XPath 1.0 expression
>
> Erm, are you saying that you don't think that "$document/*/@validity" is
> a valid XPath 1.0 expression? It *is* a valid XPath 1.0 expression; why
> do you think it isn't?


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

> Then, because we don't need to parse the full XPath to make a dependency
> > graph of the pipeline (for a wysiwig editor, for example)
>
> 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

> 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.0dependency 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


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

So to make a summary

For XProc 1.0, I prefer

>        <p:variable name="validity" context="document"
>                    select="/*/@validity" />
>        <p:when test="$validity = 'partial' or $validity = 'none'">
>          ...
>        </p:when>

and for V.next, allowing in select the use of $document, but the context
attribute must still be set

>        <p:variable name="validity" context="document"
>                    select="$document/*/@validity" />
>        <p:when test="$validity = 'partial' or $validity = 'none'">
>          ...
>        </p:when>

Cheers

Mohamed

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