Cart
[Home] [By Thread] [By Date] [Recent Entries]
Dear Richard,
On 8/16/2012 9:58 AM, Kerry, Richard wrote: My sample input was as follows (extract): No, that's correct. Or rather, that is exactly your problem, with the caveat that following-sibling:: and preceding-sibling:: don't look all the way through the document (like following:: and preceding::) but only among siblings. Yet, exactly as you say, once you're at a following sibling, looking for its preceding siblings you get all of them, irrespective of whether they precede (or follow, or happen to be) your original starting point. In XSLT 2.0 (which you must be using if you're considering the grouping approach) there are a couple of ways to work around this. For example, following-sibling::*[ ... ]/preceding-sibling::*[ ... ][. >> current()] using the current() function (which returns the original context node) and the >> operator, which compares the position of two nodes in document order. But it can be tricky to make this scale nicely to complicated cases. At that point I'll often prefer to use the grouping approach (which can be quite elegant when done right) or use an improved 2.0 variant of "tree-walking" (or "sibling recursion"), perhaps encapsulated in a stylesheet function. Cheers, Wendell Puzzledly, Richard. You should see your own messages, but check your filter settings. (Annoyingly, my own messages to the list don't turn up in the right place these days.) -- ====================================================================== Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================
|
