This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: Re: XPath riddle
- To: <xsl-list at lists dot mulberrytech dot com>
- Subject: RE: [xsl] Re: XPath riddle
- From: "Nikolaos Giannadakis" <ngiann at csd dot uoc dot gr>
- Date: Thu, 5 Jul 2001 11:28:13 +0300
- Reply-To: xsl-list at lists dot mulberrytech dot com
> I cannot understand why you exclude a node in your second example
> -- this node
> perfectly matches your definition of the result node-set.
>
This node is defined inside F and may have some other type (as would be
defined in a schema).
The generic problem is "how to select the node you want inside a possibly
recursive xml file, when the
the same pattern may appear somewhere in between in anonther context....
>
> > Can you tell what the XPath expression that:
> > "selects all C elements that come after A and have a D parent" is.
> >
>
> (//A/following::C | //A/descendant::C)[parent::D]
>
> > That is, there might be a schema, which declares the unwanted
> instances of C
> > as integers, while
> > the other C declared has some anonymous complexType.
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <A>
> > <B>
> > <C/>
> <!-- DO NOT
> select this -->
> > <D>
> > <!-- recursion is introduced here -->
> > <C>
> <!-- select this
> -->
> > <B>
> > <C/>
> <!-- DO NOT
> select this -->>
> > <D>
> > <C/>
> <!-- select this
> -->
> > </D>
> > </B>
> > </C>
> > </D>
> > </B>
> > </A>
>
> > /A//D/C (/A/descendant::D/C) would suffice, or, better, /A//B/D/C
> > (/A/descendant::B/D/C). But this would not rule out the
> possibility of the
> > B/D/C pattern appearing somewhere after A in another context.
> ^^^^^^^^^^^^^^^^^^
> ??????????
>
> What "context"? You do not define any particular "context" in
> your original
> definition of the wanted result set. There's something you
> haven't told us.
>
> Please, explain this statement.
>
> > I cannot find
> > any XPath feature that would handle recursion.
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <A>
> > <B>
> > <F>
> > <B>
> > <D>
> > <C/>
> <!-- this would
> be selected incorrectly -->
>
> Why, it exactly matches your definition -- this is a "C" node
> that follows "A" and
> has a "D" parent.
>
>
> > </D>
> > </B>
> > </F>
> > <D>
> > <!-- recursion is introduced here -->
> > <C>
> <!-- select this
> -->
> > <B>
> > <C/>
> <!-- DO NOT
> select this -->
> > <D>
> > <C/>
> <!-- select this
> -->
> > </D>
> > </B>
> > </C>
> > </D>
> > </B>
> > </A>
> >
> > Using /A/B/D/C | /A/B/D/C//B/D/C would overcome this, but you
> can see how I
> > could create another problematic example...
> > How does one find one's way around this, using a generic XPath
> approach?
> > I am not saying this is good XML design. To the contrary! ...
> it is legal,
> > nonetheless ...any ideas?
>
> Once again, could you provide a correct definition of your result
> set? The node you
> want excluded in your second example matches exactly your
> definition of the result
> set.
>
> Cheers,
> Dimitre Novatchev.
>
>
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail
> http://personal.mail.yahoo.com/
>
> XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
>
>
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list