sequential navigation problem (long)

I am working on a stylesheet that's fragmenting a big document into smaller
parts using GIs; the idea as well as navigation is very similar to the
DocBook stylesheets.

I need help to express concisely and efficiently the algorithms defined
below in XPath expressions.  Please, read on.

The approximative structure of the document is traditional:

BOOK
+- PART 1
  +- CHAP 1
    +- SECT 1
      +- ART 1
      +- ART 2
      +- ART 3
    +- SECT 2
    ...
    +- APPENDIX 1


In addition to the parent/next/prev sibling navigation, I want to add
sequential (in the book, page flicker sense) navigation as well, so that it
becomes possible to navigate the complete document only using "Next
fragment" or "Previous fragment" buttons.  So, basically every fragment
must know the ID of the sequentially preceding and following fragment.

For this I have defined the following algorithms:

for previous fragment:
1) test:      node's left sibling has a last child with a known GI and an
ID
              attr
2) else test: node has a left sibling with a known GI and an ID attr
3) else test: node has a parent with a known GI and an ID attr

for next fragment:
1) test:      node has a first child with a known GI and an ID attr
2) else test: node has sibling with a known GI and an ID attr
3) else test: node's parent has a sibling with a known GI and an ID attr


where a "known GI" is one in this list (this is to avoid fragmenting items
such as notes and subsections which won't have their own fragment, but have
an ID nevertheless):
"PART, CHAP, SECT, ART, SYMBOLS, APPENDIX, SART"

I have defined two named templates "tpl.next.fragment" and
"tpl.prev.fragment" which are called from the template responsible for
fragmenting, and are supposed to "return" the ID.  Thus, the current node
is available in these templates.  Please note, these templates are not yet
tested.

My problem now is that I am not sure how to efficiently and concisely write
the XPath test expression of what is defined in the algorithms.  The
following shows my approach, not tested.


<!-- ====================================================== -->
<xsl:template name="tpl.next.fragment">
  <xsl:param name="known.gis">
  PART | CHAP | SECT | ART | SYMBOLS | APPENDIX | SART
  </xsl:param>

  <xsl:choose>
    <!-- does this node have  a FIRST CHILD
         with an ID value and one of the GIs above? -->

    <xsl:when test="child::($known.gis)[@ID][1]">

    </xsl:when>

    <!-- does this node have a FOLLOWING SIBLING
         with an ID value and one of the GIs above? -->
    <xsl:when test="following-sibling::($known.gis)[@ID][1]">

    </xsl:when>

    <!-- does this node's PARENT DOES HAVE A NEXT SIBLING
         with an ID value and one of the GIs above? -->
    <xsl:when test="../following-sibling::($known.gis)[@ID]">

    </xsl:when>

    <!-- not interested -->
    <xsl:otherwise/>
  </xsl:choose>
</xsl:template>
<!-- ====================================================== -->


<!-- ====================================================== -->
<xsl:template name="tpl.prev.fragment">
  <xsl:param name="known.gis">
  PART | CHAP | SECT | ART | SYMBOLS | APPENDIX | SART
  </xsl:param>

  <xsl:choose>
    <!-- does this node's left sibling have a last child
         with an ID value and one of the GIs above? -->
    <!-- TOUGH ONE -->
    <xsl:when test="preceding-sibling::($known.gis)[@ID][ ???? ]">

    </xsl:when>

    <!-- does this node have a SIBLING with an ID
         value and one of the GIs above? -->
    <xsl:when test="preceding-sibling::($known.gis)[@ID][1]">

    </xsl:when>

    <!-- does this node's PARENT DOES HAVE A NEXT SIBLING
           with an ID value and one of the GIs above? -->
    <xsl:when test="parent::($known.gis)[@ID]">

    </xsl:when>

    <!-- not interested -->
    <xsl:otherwise/>
  </xsl:choose>
</xsl:template>
<!-- ====================================================== -->

Thanks for reading until here.  No, I am not expecting that you give me the
expressions ready-made, pret pour emploi, but an idea how to attack this
problem.  As this is a batch stylesheet, it doesn't really matter if it
takes a minute or two longer to process.  However, I am really interested
in conciseness, and elegance.

Thanks again.
Jakob Fix.


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