[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Process following siblings that have no text into children.


Subject: Re: [xsl] Process following siblings that have no text into children.
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Thu, 16 Aug 2012 11:39:41 -0400

Dear Richard,

On 8/16/2012 9:58 AM, Kerry, Richard wrote:
My sample input was as follows (extract):

<row row="8">
<column column="1" cell="A8">Reference Standard</column>
<column column="2" cell="B8">0-11</column>
<column column="3" cell="C8">0=missing</column>
</row>

Thus I have column elements (within row), and also column attributes. (I agree that this may be confusing and I may change it)

I've done some more debugging and suspect the problem may be that the preceding-sibling is not bounded by the context node.
ie.  when I do select="following-sibling::element()[preceding-sibling::element()[column[1] = '']]"
the following-sibling axis runs from the context node to the end of the document, but the preceding-sibling axis doesn't just run back to my context node and end there (which I thought it did), but right back to the beginning of the document.  So I'm not just "looking back" to where I started and terminating when there is text in column 1, I'm looking right back to the start.

Or is that also wrong ?

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.

PPS. I'm still not seeing my own messages on the list. Is that normal or is there a setting I need ?

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
======================================================================


Current Thread
Keywords