RE: Should expansions be allowed in select/match strings ? (OR ca n you solve this without this !?)

Subject: RE: Should expansions be allowed in select/match strings ? (OR ca n you solve this without this !?)
From: Mark Birbeck <Mark.Birbeck@xxxxxxxxxxxxx>
Date: Fri, 26 Mar 1999 15:12:21 -0000
We had the same frustration with IE5, but can now achieve it with the
new context() function (in our case we wanted to jump from one node to
another when processing fragments and fragment contexts.) Your line
would become:

	<xsl:for-each select="../../../item[@name=(context()/@src})]">

I don't know if this is an MS-only extension or not, but it has allowed
us to implement loads of the rules that we just couldn't do before.

Regards,

Mark

> -----Original Message-----
> From: Alistair MacDonald 
> Sent: 26 March 1999 12:34
> To: xsl-list@xxxxxxxxxxxxxxxx
> Subject: Should expansions be allowed in select/match strings 
> ? (OR can
> you solve this without this !?)
> 
> 
> I'm trying to solve a problem in a stylesheet where I need to 
> reference another element based upon a match between 2 
> attributes. Easy enough - until you try to do the match at 
> run-time. Before I explain fully, I'll point out that I'm 
> using xt/xp, but as far as I can tell this is not clear from the WD.
> 
> Here is a sample ....
> -----
> <item .. name="foo">
>   <doc>
>     ...
>     <inline src="bar" />
>     ...
>   </doc>
> </item>
> <item .. name="bar" filename="wibble" />
> -----
> 
> What I need to do is get "filename" and insert it into the 
> stream when I get the <inline />. 
> 
> Note that I've only given parts of the file (ie not the 
> (common) parent elements) and that for various reasons the 
> names will be unique within a portion of the file (ie the bit 
> given), but not (necessarily) across the whole file. This 
> means that name  CANNOT be an id().
> 
> One way of dealing with this would be to do something like:
> 
> -----
> <xsl:for-each select="../../../item[@name={@src}]">
> ...
> </xsl:for-each>
> -----
> 
> However, you cannot include '{}'s, and therefore cannot 
> pre-expand attributes/elements/whatever. (Without the '{}'s 
> this would be interpreted as a request for an item whose name 
> & src attributes where equal)
> 
> So, we move onto macros. These appear promising because the 
> WD has examples of these showing the arg() function being 
> replaced in {}'s.
> Try rebuilding the input file slightly to include an explicit 
> reference to be used by the macro invocation and use the macro below :
> 
> -----
> <xsl:macro name="test">
>  <xsl:macro-arg name="xref" />
> 
>   <xsl:value-of select="arg(xref)" />
>   <xsl:for-each select="arg(xref)">
>     ...
>   </xsl:for-each>
> </xsl:macro>
> -----
> 
> This results in the expected string being output (from the 
> value-of), but the for-each gives an unexpected token. This 
> doesn't really surprise me, because, according to the WD,  
> 'arg()' is NOT a valid function for use in 'select' or 
> 'match' strings.
> 
> This leads me to the following questions:
> 
> 1) Should 'select' and 'match' allow the use of '{}' to 
> pre-expand items BEFORE they get applied to nodes ?
> 2) Should 'select' and 'match' accept the use of 'arg()' when 
> in a macro context ?
> 
> Alistair
> 
> 
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> 


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread