Re: [docbook-apps] Re: Xref is only supported to listitems in an orderedlist:

[Mathieu Malaterre <mathieu.malaterre@gmail.com>]

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