docbook-apps

Hi Mathieu,
xmllint does not report this as an issue because it is valid DocBook, in that the
linkend value matches some id value in the document.

However, the stylesheet is trying to generate link text for the xref and is failing.
An xref requires that text be generated from the target element, but some elements do
not have a simple title or number to reference, and that is what you are seeing here.

The anchor you are linking to is an empty element so it is not suitable. For such
elements, the stylesheet looks at the parent element and tries to use that to generate
the text. The parent here is a para, which is also unsuitable because it can contain
unlimited text and many other elements, including block elements. So the stylesheet
goes up again, trying the listitem. Since this is an itemizedlist rather than an
orderedlist, such a listitem also does not have suitable text for a generated xref.
At that point, it gives up and issues the error message.

What is lost here is the id of the original target element. The recursion up the line
of ancestors should keep track of that. That's a bug that should be fixed. If you
care to file a bug report on the DocBook SourceForge site with your example, that
would be great.

My question is, what do you expect such an xref to display in the output? "bla"? If
so, you can use endterm to force the stylesheet to use the text of the para:

<itemizedlist>
<listitem>
<para id="mypara"><anchor id="myidx"/>bla</para>
</listitem>
</itemizedlist>
<xref linkend="myidx" endterm="mypara"/>

See this reference for more on the use of endterm:

http://www.sagehill.net/docbookxsl/CrossRefs.html#XrefEndterm

Bob Stayton
Sagehill Enterprises
bobs@sagehill.net

On Fri, Feb 19, 2010 at 6:20 PM, Bob Stayton <bobs@sagehill.net> wrote:
> Hi Mathieu,
> xmllint does not report this as an issue because it is valid DocBook, in
> that the linkend value matches some id value in the document.
>
> However, the stylesheet is trying to generate link text for the xref and is
> failing. An xref requires that text be generated from the target element,
> but some elements do not have a simple title or number to reference, and
> that is what you are seeing here.
>
> The anchor you are linking to is an empty element so it is not suitable. For
> such elements, the stylesheet looks at the parent element and tries to use
> that to generate the text.  The parent here is a para, which is also
> unsuitable because it can contain unlimited text and many other elements,
> including block elements.  So the stylesheet goes up again, trying the
> listitem.  Since this is an itemizedlist rather than an orderedlist, such a
> listitem also does not have suitable text for a generated xref. At that
> point, it gives up and issues the error message.
>
> What is lost here is the id of the original target element.  The recursion
> up the line of ancestors should keep track of that.  That's a bug that
> should be fixed.  If you care to file a bug report on the DocBook
> SourceForge site with your example, that would be great.

Here you go:
https://sourceforge.net/tracker/?func=detail&aid=2955077&group_id=21935&atid=373747

Let me know if you need more information.

Thanks a bunch for your clarification, I did not fully understood the
behavior. This is now crystal clear :)

> My question is, what do you expect such an xref to display in the output?

I was simply given a set of 70 XML docbook files, and my task was to
find the problematic <anchor/> elements...

Thanks,
--
Mathieu