David/Wendell
Thanks for your thoughts.
I think I'm having some trouble articulating my problem without
reproducing huge reams of code to demonstrate the levels of
inconsistency/variation/complexity. A sample of my code may
demonstrate the hoops I'm jumping through just to get a string output
in one part of my breadcrumb links at the page top:
<xsl:choose>
<xsl:when test="ancestor::exp-level-1">
<xsl:value-of select="(if
(ancestor::exp-level-1/heading[(_at_)type =
'electronic-only']) then ancestor::exp-level-1/heading[(_at_)type =
'electronic-only'] else ancestor::exp-level-1/heading[(_at_)type =
'running-head'])"/>
</xsl:when>
<xsl:when test="ancestor::misc-level-1">
<xsl:value-of
select="ancestor::misc-level-1/heading[1][(_at_)type !=
'running-head']"/>
</xsl:when>
<xsl:when test="ancestor::law">
<xsl:value-of select="ancestor::law/heading[(_at_)type =
'electronic-only']"/>
</xsl:when>
<xsl:when test="ancestor::reg">
<xsl:value-of select="(if (ancestor::reg/heading[(_at_)type =
'electronic-only']) then ancestor::reg/heading[(_at_)type =
'electronic-only'] else ancestor::reg/heading[(_at_)type =
'running-head'])"/>
</xsl:when>
<xsl:when test="ancestor::group">
<xsl:value-of select="(if
(ancestor::group[1][not(descendant::misc-level-1 or
descendant::exp-level-1)]/heading[(_at_)type = 'electronic-only']) then
ancestor::group[1]/heading[(_at_)type = 'electronic-only'] else
ancestor::group[not(descendant::misc-level-1 or
descendant::exp-level-1)][heading[1]]/heading[1])"/>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="parent::*/heading[1]"/>
</xsl:otherwise>
</xsl:choose>
It may be that I just need to analyse the data a little more carefully
to see if I can avoid such long-windedness which quickly bloats my
code significantly. However, this is where my problem partly lies,
with data that I don't believe is always tightly controlled by the dtd
and has too much unnecessary structural flexibility/alternatives. I
also have no control over the data creation though the use of flags is
an interesting idea in other scenarios. As Wendell says, I do at least
have the option with XSLT to build, review and rebuild fairly easily
so that I can improve the output over time.
Having read your comments, I think maybe I need to try and focus on
exactly where I split the data ie. at which generalised level, say
<xsl:template match="*/*/group | */*/law | */*/exp-level-1 |
*/*/exp-level-2" priority="2"> rather than just relying on a general
template match for "law" or "group".
It might also simplify things for me if I try to use variables/keys
for storing some details rather than repeating complex patterns. I'll
have to think about that one.
I think at least you have given me some confidence that my approach is
not totally wrong and that basically I may just need to put in more
donkey work to pinpoint what data I need to pull out and when. As my
boss likes to tell me, "That's why they call it work" ;-))
Cheers
Mark
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--