Re: Variables/Parameters and Scoping

Norm,

> One concern I have is that XSLT, as a host language for XPath, can
> reasonable be expected (is, in fact, expected) to have all of the
> documents that it uses in memory. There's clear value in being able to
> shove documents through a pipeline that are bigger than practical
> memory limitations would allow one to load directly in XSLT.

Sure, but I really don't see how using the context node to set variables 
alleviates the problem.

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>

Either way, implementations have to examine the pipeline definition to 
work out which inputs are referenced and which aren't. Either way, 
implementations have to look at the variables used within XPath 
expressions to work out which documents they have to keep track of and 
which they can forget about.

I suspect that, not having done an implementation myself, I'm missing 
some details about what's involved. If anyone would care to illuminate 
me, I'd be very happy to stop banging on about it.


Also, FWIW, I'm not going to wail and gnash my teeth if we choose to 
make implementation simpler by saying we don't support comparisons 
between multiple documents or XPaths over document sequences in this 
version of XProc. These things are always going to be possible for users 
by bugging out to a custom component. My only concern is that it might 
lead to the next version of XProc being a lot more complex than it needs 
to be (specs, unlike code, can't be massively refactored when new 
requirements are tackled).

Cheers,

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

Received on Friday, 26 May 2006 09:54:47 UTC