RE: RE: Should expansions be allowed in select/match strings

'fraid I can't help you with your relationship with your boss, but I
mentioned the things I did because the problem seems to me to be more to
do with context than expansion. According to the spec, the squiggly
brackets should allow us to do substitutions, although IE5 doesn't do
this yet. The problem we have - and I think lies at the root of your
problem too - is the need to specify a filter that deals with two
contexts, when both are variable. For example, if a document had only
one fragment context, and one fragment then things would be easy,
because the relationship between the two nodes is always the same:

<TheLot>
  <context>
    <a>
      <b>
        <fragment/>
      </b>
    </a>
  </context>
  <FragStuff>
    <name>Mark</name>
  </FragStuff>
</TheLot>

You could insert the fragment nodes into the context in lots of ways,
like:

<xsl:template match="fragment">
  <xsl:apply-templates select="//FragStuff/*"/>
</xsl:template>

But the minute you try something like:
<TheLot>
  <context>
    <a>
      <b>
        <fragment IDREF="1"/>
      </b>
      <b>
        <fragment IDREF="2"/>
      </b>
    </a>
  </context>
  <FragStuff ID="1">
    <name>Mark</name>
  </FragStuff>
  <FragStuff ID="2">
    <name>Alistair</name>
  </FragStuff>
</TheLot>

you just can't do it with ordinary filters - you need two contexts, one
for the point of insertion and one for what is to be inserted.

Anyway, as for 'should it be allowed'; as far as I can see we HAVE to
have something that gives context. If it's the squigglies then great,
but expansion seems to me to be less significant.

Regards,

Mark




> -----Original Message-----
> From: Alistair MacDonald 
> Sent: 29 March 1999 14:16
> To: xsl-list@xxxxxxxxxxxxxxxx
> Subject: Re: RE: Should expansions be allowed in select/match 
> strings ?
> (OR can you solve this without this !?)
> 
> 
> 
> 
> >>> Mark Birbeck <Mark.Birbeck@xxxxxxxxxxxxx> 03/26 3:12 pm >>>
> > 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.
> 
> This must be MS-specific since it isn't in the WD, isn't 
> supported by XT. It also looks very similar to my first 
> example (included again below).
> 
> However, it doesn't ANSWER the question - well, apart from 
> saying that MS do it - which was "SHOULD this be allowed ?". 
> I suppose the secondary question is "why ISN'T it allowed?" - 
> was it deliberate, or just an oversight ?
> 
> (Telling my boss that the only way to do what he wants is 
> rewrite large chunks of the files using java and/or load each 
> file into IE and then save it is unlikely to go down well ... 8-)
> 
> > -----Original Message-----
> > From: Alistair MacDonald 
> [...]
> > One way of dealing with this would be to do something like:
> > 
> > -----
> > <xsl:for-each select="../../../item[@name={@src}]">
> > ...
> > </xsl:for-each>
> > -----
> 
> 
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> 
> 
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> 


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