#132 HTML: TOC of a qandaset with nested qandaentries

output: HTML
closed-fixed
XSL (122)
5
2006-09-06
2006-06-20
Daniel Leidert
No

Hello,

Following the docbook DTD it is possible to have
construct like the following one

<qandaset>
<qandaentry>
<question>...</question>
<answer>
<para>...</para>
<qandaentry>
<question>...</question>
<answer>...</answer>
</qandaentry>
</answer>
</qandaentry>
</qandaset>

Wouldn't it be nice, if the qandaset ToC could handle
this? ATM it only handles the top-level qandaentries,
but misses all the sub-qandaentries. I've attached a
patch for this situation to apply to qandaset.xsl. It
should work with the DocBook V5.0b6 too. The patch is
really simple and the output then is:

1. foo
1.1 foo sub
1.2 foo next
2. bar
...

Regards, Daniel

Discussion

1 2 > >> (Page 1 of 2)
  • Daniel Leidert
    Daniel Leidert
    2006-06-20

    Logged In: YES
    user_id=1102637

    Sorry. Seems I forgot the patch.

     
  • Daniel Leidert
    Daniel Leidert
    2006-07-29

    Logged In: YES
    user_id=1102637

    Now I attached a patch. Please have a look at it.

     
  • Daniel Leidert
    Daniel Leidert
    2006-07-29

    Logged In: YES
    user_id=1102637

    Maybe a parameter should be added to control this behaviour.

     
  • Logged In: YES
    user_id=118135

    A fix for this issue has been added to the current codebase.
    Please test the fix with the latest snapshot from:

    http://docbook.sourceforge.net/snapshots/

     
  • Logged In: YES
    user_id=118135

    Applied patch and added new qanda.nested.in.toc param for
    controlling the behavior. It's off by default. Setting a
    non-zero value for qanda.nested.in.toc turns it on.

     
    • assigned_to: nobody --> xmldoc
    • status: open --> pending-fixed
     
  • Daniel Leidert
    Daniel Leidert
    2006-08-05

    Logged In: YES
    user_id=1102637

    Thanks. I thought, that I hit qandaset/qandaentry with this
    code too (Docbook 5 allows qandaset inside answer, but not
    qandaentry), but it seems I fail. The xsl-stylesheets in
    this case respect the generate.toc parameter, but my code
    fails to create a TOC for the sub-sets. I tried this code,
    which also fails:

    html/qandaset.xsl:
    [..]
    <xsl:template match="answer" mode="qandatoc.mode">
    <xsl:if test="child::qandaentry">
    <dd>
    <xsl:call-template name="process.qanda.toc"/>
    </dd>
    </xsl:if>
    <xsl:if test="child::qandaset">
    <xsl:apply-templates select="child::qandaset"
    mode="qandatoc.mode"/>
    </xsl:if>
    </xsl:template>

    <xsl:template match="qandaset" mode="qandatoc.mode">
    <dd>
    <xsl:call-template name="process.qanda.toc"/>
    </dd>
    </xsl:template>
    [..]

    If the output for Docbook 4 and Docbook 5 differs and we/I
    do not find a solution, I suggest to remove my patch, so the
    behaviour is consistent.

    I'm really sorry, but I was sure, this works for Docbook 5
    too. Seems I made a mistake.

    Regards, Daniel

     
  • Daniel Leidert
    Daniel Leidert
    2006-08-05

    • status: pending-fixed --> open-fixed
     
  • Logged In: YES
    user_id=118135

    Daniel,

    Please upload a test case (your DocBook XML source).

    The current code does seem to me to correctly generate TOCs
    for nested DocBook5-valid answer/qandaset instances. I
    guess it just doesn't generate them where I guess you're
    expecting to find them.

     
  • Daniel Leidert
    Daniel Leidert
    2006-08-05

    Logged In: YES
    user_id=1102637

    I would expect the following:

    In an article-toc containg qandasets, all question should
    appear (currently this only happens for answer/qandaentry,
    not answer/qandaset). Inside the qandaset, it is possible to
    put all questions into the top-toc (currently
    answer/qandanetry) or in every qandaset (currently
    answer/qandaset with generate.toc="qandaset toc"). This
    isn't IMO a big difference, although I would normally prefer
    all questions inside a top-toc and optional a toc per
    (sub-)qandaset. But a conistent and complete TOC in an
    article-toc would be important.

    You can have a look at the difference by processing the
    attached testcase in difference to the qandaset.006.xml
    testcase.

    Regards, Daniel

     
  • Daniel Leidert
    Daniel Leidert
    2006-08-05

    test case to show the difference between DocBook 4 and 5

     
    Attachments
  • Daniel Leidert
    Daniel Leidert
    2006-08-05

    result for testcase 6, Docbook 4

     
    Attachments
  • Daniel Leidert
    Daniel Leidert
    2006-08-05

    result for testcase 7 (I know, case 1 in tests/5.0/), Docbook 5

     
    Attachments
    • status: open-fixed --> pending-fixed
     
  • Logged In: YES
    user_id=118135

    Daniel,

    I made a change that I think will give you what you want.
    Please test with the latest snapshot and let me know.

     
  • Logged In: YES
    user_id=118135

    A fix for this issue has been added to the current codebase.
    Please test the fix with the latest snapshot from:

    http://docbook.sourceforge.net/snapshots/

     
  • Daniel Leidert
    Daniel Leidert
    2006-08-05

    Logged In: YES
    user_id=1102637

    Thanks. First, I'm sorry. I found, why my test all failed: I
    had the code I suggested still in the customization layer
    and so, all my changes to the real stylesheets were ignored
    (stupid, I know).

    Then: Your changes work except one thing: They only catch
    the first instance occurance of a qandaset element inside
    another qandaset element (I've attached a testcase to show
    you the result - the questions 221 and 222 are not shon in
    the ToC) - independent if DocBook 4 or 5 (both only show the
    first 2 levels).

    Then one thing, I would like to control (at least via your
    qanda.nested.in.toc parameter) too: the occurance of theses
    sub-sets in the article-toc. In my customization layer I use:

    <xsl:template match="section" mode="toc">
    <xsl:param name="toc-context" select="."/>

    <xsl:call-template name="subtoc">
    <xsl:with-param name="toc-context" select="$toc-context"/>
    <xsl:with-param name="nodes"
    select="section|bridgehead[$bridgehead.in.toc !=
    0]|qandaset/qandaentry/question"/>
    </xsl:call-template>
    </xsl:template>

    <xsl:template match="question" mode="toc">
    <xsl:param name="toc-context" select="."/>

    <xsl:call-template name="subtoc">
    <xsl:with-param name="toc-context" select="$toc-context"/>
    <xsl:with-param name="nodes"
    select="following-sibling::answer/qandaentry/question|following-sibling::answer/qandaset/qandaentry/question"/>
    </xsl:call-template>
    </xsl:template>

    <xsl:template match="question" mode="titleabbrev.markup">
    <xsl:value-of select="."/>
    </xsl:template>

    For me this works with both DocBook 4 and 5.

     
  • Daniel Leidert
    Daniel Leidert
    2006-08-05

    • status: pending-fixed --> open-fixed
     
  • Daniel Leidert
    Daniel Leidert
    2006-08-05

    extended testcase for nested qana* elements

     
    Attachments
  • Daniel Leidert
    Daniel Leidert
    2006-08-05

    Logged In: YES
    user_id=1102637

    The issue is related to the check in process.qanda.toc. This
    check seems to result in a second issue: if the param is set
    to 0, no ToC for qandaset is output, which is not expected.
    I've attached a patch to fix this issue (restores the
    default behaviour and correct behaviour with enabled
    nested-qanda-toc).

    HTH

     
  • Daniel Leidert
    Daniel Leidert
    2006-08-05

    possible patch to finally fix the qandaset-toc code

     
    Attachments
  • Logged In: YES
    user_id=118135

    A fix for this issue has been added to the current codebase.
    Please test the fix with the latest snapshot from:

    http://docbook.sourceforge.net/snapshots/

     
  • Logged In: YES
    user_id=118135

    Applied patch. Re-open if you notice further problems.

     
1 2 > >> (Page 1 of 2)