RE: Using XPATH axis within a recursive structure to

Thanks: it's a faulty optimization.

Saxon is rewriting 

d-or-self::node()/child::load except
d-or-self::node()/child::gui/descendant::load

as

d-or-self::node() / (child::load except child::gui/descendant::load())

which isn't the same at all.

This leads to some interesting questions about what exactly are the
circumstances under which the set operators (union, intersect, except) are
distributive with respect to "/".

[//A | //B] translates nicely to [/descendant-or-self::node()/(child::A |
child::B)] but you've now got me worried! I suspect that union distributes
correctly into any path expression but intersect and except don't - but I'm
not sure I can prove it. Any set theorists out there who can help?

Michael Kay
http://www.saxonica.com/

 

> -----Original Message-----
> From: Pawson, David [mailto:David.Pawson@xxxxxxxxxxx] 
> Sent: 22 February 2005 10:37
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: RE:  Using XPATH axis within a recursive 
> structure to match a descendent node
> 
> Mike, I can't get this to work using saxon 8.3
> 
> xml
> <gui>
>      <load>                                        
>  ........................*0
>         something
>      </load>
>      <p> blah
>            <b>
>                  blah
>                     <load>                                 
>  ........................*1
>                        else
>                     </load>
>                     <gui><load>                                 
>  ........................*2
>                              <again/>
>                           </load>
>                     </gui>
>            </b>
>      </p>
>  </gui>
> 
> 
> XSL
> 
>  <xsl:template match="gui">
>     <!-- <xsl:apply-templates 
> select=".//load[ancestor::gui[1] is current()]" />  <br /> -->
>     <p> <xsl:apply-templates select=".//load except 
> .//gui//load" />  </p>
>   </xsl:template>
> 
> 
>   <xsl:template match="load" >
>     [<xsl:value-of select="."/>] <br />
>   </xsl:template>
> 
> 
> The commented out version works, 
> but the one shown (gui template) doesn't, and I can't see why 
> it shouldn't?
> 
> 
> Any suggestions why please?
> regards DaveP
> 
> 
> 
> 
> 
>  
> 
>     -----Original Message-----
>     From: Michael Kay [mailto:mike@xxxxxxxxxxxx] 
> 
> 
>     In XPath 2.0,
>     
>     .//load except .//gui//load
>     
>     or 
>     
>     for $this in . return $this//load[ancestor::gui[1] is $this]
>     
>     
>     In XSLT (1.0 or 2.0) you could write
>     
>     .//load[ancestor::gui[1] is current()]
>     
>     
>     Michael Kay
>     http://www.saxonica.com/
>     
>     
>     
>      
>     
>     > -----Original Message-----
>     > From: ben senior [mailto:ben@xxxxxxxxxxxxx]
>     > Sent: 21 February 2005 15:15
>     > To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
>     > Subject:  Using XPATH axis within a recursive 
>     structure to match 
>     > a descendent node
>     > 
>     > I'm afraid I couldn't think of a better title!
>     > 
>     > Take a look at the xml below. The goal is to match the 
>     load tags of 0 
>     > and 1, but NOT 2.
>     > I need an expression which matches ALL load tags that are 
>     descendents 
>     > of the current gui tag, but not contained within 
>     descendent gui tags! 
>     > Does that make sense to anybody?
>     > 
>     > i.e. descendant::load will also match 2, which I do not want. 
>     > How might
>     > I approach this? Any ideas?
>     > 
>     > <gui>
>     >     <load>                                        
>     > ........................*0
>     >        something
>     >     </load>
>     >     <p> blah
>     >           <b>
>     >                 blah
>     >                    <load>                                 
>     > ........................*1
>     >                       else
>     >                    </load>
>     >                    <gui>
>     >                          <load>                                 
>     > ........................*2
>     >                             <again
>     >                          </load>
>     >                    </gui>
>     >           </b>
>     >     </p>
>     > </gui>
>     > 
>     > Kindest Regards,
>     > 
>     > Ben
>     
>     
> 
> -- 
> DISCLAIMER:
> 
> NOTICE: The information contained in this email and any 
> attachments is 
> confidential and may be privileged.  If you are not the intended 
> recipient you should not use, disclose, distribute or copy any of the 
> content of it or of any attachment; you are requested to notify the 
> sender immediately of your receipt of the email and then to delete it 
> and any attachments from your system.
> 
> RNIB endeavours to ensure that emails and any attachments generated by
> its staff are free from viruses or other contaminants.  However, it 
> cannot accept any responsibility for any  such which are transmitted.
> We therefore recommend you scan all attachments.
> 
> Please note that the statements and views expressed in this email and 
> any attachments are those of the author and do not 
> necessarily represent
> those of RNIB.
> 
> RNIB Registered Charity Number: 226227
> 
> Website: http://www.rnib.org.uk