After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 96925 - IDs not resolving through entity includes with docbook XRef
IDs not resolving through entity includes with docbook XRef
Product: libxslt
Classification: Platform
Component: general
Other All
: Normal normal
: ---
Assigned To: Daniel Veillard
Daniel Veillard
Depends on:
Reported: 2002-10-26 19:40 UTC by Ralph Giles
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---

docbook xml files showing the problem (44.05 KB, application/octet-stream)
2002-10-26 19:46 UTC, Ralph Giles

Description Ralph Giles 2002-10-26 19:40:24 UTC
I have a medium-sized docbook document that fails to parse in xsltproc when
the individual sections are imported through the entity include mechanism.
Most (but not all) of the docbook <xref/> elements fail thus:

    Error: no ID for constraint linkend: vorbis-spec-codec.
    XRef to nonexistent id: vorbis-spec-codec

Where the id "vorbis-spec-codec" that is the target of the xref linkend
attribute plainly exists inside another included entity. The <xref/>
elements that do not generate the error result in the generation of the
correct text for the reference. Furthermore, the <link/> element, which
also takes a 'linkend="id"' attribute but does not generate cross-reference
text always resolves correctly.

The same file parses as expected in Saxon 6.5.2.

The issue goes away if entity includes are not used and the sections are
concatenated into the top-level file. The problem also seems to be related
to document size of tree depth; a simple three-file example does not show
the problem.

It looks like this same problem was reported to the list last year:

but never resolved.

I've verified the problem with the latest library release:

    $ xsltproc --version
    Using libxml 20426, libxslt 10022 and libexslt 713
    xsltproc was compiled against libxml 20426, libxslt 10022 and libexslt 713
    libxslt 10022 was compiled against libxml 20426
    libexslt 713 was compiled against libxml 20426

The fileset in question is the Vorbis I specification. The docbook version
is only available through cvs:

see for anonymous cvs checkout instructions.
Comment 1 Ralph Giles 2002-10-26 19:46:23 UTC
Created attachment 11856 [details]
docbook xml files showing the problem
Comment 2 Ralph Giles 2002-10-26 19:54:16 UTC
I've attached the docbook xml files showing the problem. The tarball
doesn't include the figures, but they aren't necessary for
reproduction. Command line is:

    xsltproc --xinclude --output Vorbis_I_spec.html spec-html.xsl

This is DockBook XML 4.2, with version 1.57.0 of the official
docbook-xsl stylesheets.
Comment 3 Ralph Giles 2002-10-27 14:44:48 UTC
Additional information:

using xinclude instead of SYSTEM entities avoids the problem. However,
a single entity inclusion (e.g for the 'colophon'/footer.xml at the
end) causes errors with other sections. (in fact, more errors than
with all entity includes)

More of the errors occur with the FO docbook stylesheets than with the
html docbook stylesheets.

Running the top-level document through 'xmllint --noent' is another
(faster) work around.
Comment 4 Daniel Veillard 2002-11-16 15:38:53 UTC
Okay, I got it ... a fairly complex but annoying bug in libxml2
XPath implementation. Basically the id lookup in docbook stylesheet
don't use the DTD IDs but build a key for //* nodes with an attribute
called id instead (that's recent I think). And this //* computation
was missing some top level nodes in included entities, all the
missing ID were hosted by top level elements in external entities.
It works correcly now, I'm commiting the fixes to libxml2 CVS, just
wait for the next version:

paphio:~/tmp/Vorbis_I_spec-20021026 -> xsltproc --xinclude --output
Vorbis_I_spec.html spec-html.xsl Vorbis_I_spec.xml
paphio:~/tmp/Vorbis_I_spec-20021026 ->

  thanks for the report and the detailed example,

Comment 5 Daniel Veillard 2002-11-17 19:20:13 UTC
This should be closed in the last releases,