Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.


#1183 Link to bridgehead causes spurious error messages

output: HTML
XSL (1066)
John Maddock

If I link to a bridgehead which contains any XML child elements at all, I see two error messages per link:

Request for title of element with no title: link
Request for title of element with no title: link

Replace "link" in the above with the name of the first child element in the bridgehead.

Here's the test case:

<?xml version="1.0"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "">

<article xmlns:rev="" id="math_toolkit" rev:last-revision="$Date: 2011/06/23 10:13:51 $">
<title>Math Toolkit</title>
<anchor id="math_toolkit.policy.pol_ref.policy_defaults.boost_math_assert_undefined_policy"/>
Determines how discrete quantiles return their results: either as an integer,
or as a real value, can be set to one of the enumerated values: <computeroutput xmlns:xi=""><phrase role="identifier">real</phrase></computeroutput>, <computeroutput xmlns:xi=""><phrase role="identifier">integer_round_outwards</phrase></computeroutput>,
<computeroutput xmlns:xi=""><phrase role="identifier">integer_round_inwards</phrase></computeroutput>,
<computeroutput xmlns:xi=""><phrase role="identifier">integer_round_down</phrase></computeroutput>, <computeroutput xmlns:xi=""><phrase role="identifier">integer_round_up</phrase></computeroutput>, <computeroutput xmlns:xi=""><phrase role="identifier">integer_round_nearest</phrase></computeroutput>.
Defaults to <computeroutput xmlns:xi=""><phrase role="identifier">integer_round_outwards</phrase></computeroutput>.
<bridgehead renderas="sect5" id="math_toolkit.policy.pol_ref.policy_defaults.boost_math_assert_undefined_policy-heading">
<link linkend="math_toolkit.policy.pol_ref.policy_defaults.boost_math_assert_undefined_policy">BOOST_MATH_ASSERT_UNDEFINED_POLICY</link>
<link linkend="math_toolkit.policy.pol_ref.policy_defaults.boost_math_assert_undefined_policy-heading">Determines</link> whether functions that are mathematically undefined for a specific
distribution compile or raise a static (i.e. compile-time) assertion. Defaults
to <computeroutput xmlns:xi=""><phrase role="keyword">true</phrase></computeroutput>: meaning that any
mathematically undefined function will not compile. When set to <computeroutput xmlns:xi=""><phrase role="keyword">false</phrase></computeroutput> then the function will compile but
return the result of a domain error: this can be useful for some generic
code, that needs to work with all distributions and determine at runtime
whether or not a particular property is well defined.


If I remove the link to the bridgehead then the errors go away.
If I remove the child elements from the bridgehead then the errors also go away.

Please note that the code generating these messages is generated automatically, and there are potentially hundreds of such links with all the associated messages, so this is a big issue for me.

The XSL processor is xsltproc BTW.

John Maddock.


  • It appears that the following is needed:

    <xsl:template match="link" mode="title.markup">
    <xsl:apply-templates mode="title.markup"/>

    Can you please test this?

    If the fix is added to the stock stylesheets, it should go into common/titles.xsl.

  • John Maddock
    John Maddock

    I've worked around the issue in my code for now, so I no longer have a test case other than the one given above.... so if it does the right thing in that case, then that's good enough for me ;-)

  • Robert Stayton
    Robert Stayton

    Two questions:

    1. Are you using olinks, and running with the param collect.xref.targets set to 'yes'?

    2. Do you see anything wrong with your output?

  • Robert Stayton
    Robert Stayton

    I hit Update before I completed that last comment. I was going to say that I think this error message appears during the collection of olink data. It is a spurious error message, and I think it has been fixed in SVN (but I will confirm). That's why I asked if you saw any consequences in your output.

  • John Maddock: is this still a problem?

  • John Maddock
    John Maddock

    I don't know, sorry: as I mentioned before I've worked around the problem so we no longer see the issue. If the original test case is handled correctly, then it's fixed as far as I'm concerned. If not it's not. Sorry I can't be more helpful!