RE: section 14.1

Thanks a lot for your response! I am a little confused about the global
variable solution that you describe though. It seems like it would work
great with XSLT 2.0, but is not that useful for XSLT 1.0 because the root
node '/' would be stored in the variable as a "result tree fragment", which
means that child-nodes of that root node could not be referenced via the
variable (at least, that is my interpretation of section 11.1 of the XSLT
1.0 specification: "In particular, it is not permitted to use the /, //, and
[] operators on  result tree fragments."). 
But, it is not a big deal since we are talking about the 2.0
specification...
Thanks again.

ps. I was reading section 14.3.2 of the XSLT 2.0 spec on the key() function,
and the definition of its function within a context document, and use in
referencing other documents is really clear and great! 

Marc Zbyszynski
System Architect
DoubleClick Inc.
450 West 33rd St.
New York, NY 10001
mzbyszynski@doubleclick.net


-----Original Message-----
From: Kay, Michael [mailto:Michael.Kay@softwareag.com]
Sent: Tuesday, April 02, 2002 7:47 AM
To: Zbyszynski, Marc; 'xsl-editors@w3.org'
Subject: RE: section 14.1


> One 
> concern that I
> have that does still not seem to be addressed is the ability to reference
> nodes in the principal source document while processing a 
> node-set loaded using the document() function.

The conventional (XSLT 1.0) solution to this is to declare a global
variable:

<xsl:variable name="root" select="/"/>

which means that the principal source document can be referenced anywhere as
$root. This solution remains available in XSLT 2.0.

We have also been looking at the possibility of providing a function called
input() which provides access to the "input collection" (which may default
to being simply the principal source document, or may be a generalization of
this concept). The semantics of this still need a little work.

> 
> ps. it would also be great if there were some way to modify 
> variable values
> in process (such as within a for-each loop)... But I am sure 
> I am not the first person who has asked for that...
>
We're not intending to make this major change, which would turn the language
from a declarative language into a sequential, procedural one.

Thanks for the feedback,

Michael Kay
Software AG

Received on Wednesday, 3 April 2002 11:25:16 UTC