Closed kraptor closed 2 years ago
With the help of @tomschr, I tried to discard issues by running xmllint and xlstproc manually.
Here are the results for the following commands:
xsltproc --xinclude --output /tmp/xslt-resolved.xml ../daps-xslt/common/reduce-from-set.xsl xml/MAIN.DAPS.xml
xslt-resolved.xml.txt
xmllint --noent --postvalid --xinclude --output /tmp/xinclude-resolved.xml xml/MAIN.DAPS.xml
xinclude-resolved.xml.txt
Apparently, both utilities (compiled against 1.1.35 and latest libxml2) work correctly.
I'm not sure why, but the issue remains the same: the XML file within .profiled lacks href
attribute in xi:includes
Greetings,
I would like to comment about this issue, that I seem to encounter also while building DAPS for Debian GNU/Linux (I package DAPS for official Debian). Please, bear with me while I show everything I do:
First, software versions (Debian unstable, latest):
Now, build:
The MAIN.DAPS.xml file mentioned by @kraptor is effectively missing the href attribute:
And then, I compile:
What is interesting is that looking at the failing files:
There are many <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"/>
identical instances.
What might be the cause for this weird behaviour ?
I am ready to provide more details on request, as I really would like this fine piece of software to be included in the next stable release of Debian.
Sincerely,
Filippo Rusconi
@lopippo Do you mind to reformat your comment a little bit?
Besides that, I've been on/off trying to find the issue but I couldn't, so we need a DAPS developer to step in. :(
Thanks @lopippo for your detailed report.
Do you mind to reformat your comment a little bit?
I've updated Filippo's comment. It should be now more readable. :slightly_smiling_face:
Greetings @tomschr ! Long time no hear :-) Sorry, I was trying to fix the formatting also. Hope, the mixed results are readable :-) Cheers, Filippo
Greetings @lopippo! :wave: Hehe, that's true.
I've used <details>
tag to make the long listings foldable. To unfold it, use the arrow. All fine. :slightly_smiling_face:
Greetings @lopippo! wave Hehe, that's true.
I've used
<details>
tag to make the long listings foldable. To unfold it, use the arrow. All fine. slightly_smiling_face
Thank you :-)
Sorry for not having looked into this issue before. ATM there is no libxslt1 1.1.35 package available for openSUSE. @tomschr and me will first try to update the existing 1.1.34 package for openSUSE to see whether the problem exists on openSUSE as well (I assumke it does).
@lopippo and @kraptor : In case you have DocBook5 sources with xi:includes available, would you mind checking if the problem occurs with DocBook5 as well? You can use the git checkout of DAPS as described at the bottom of https://github.com/openSUSE/daps/blob/main/INSTALL.adoc. (The DAPS doc sources are DocBook4. In case this is a libxslt upstream error and this does not occur with DocBook5, I would convert the sources to DocBook5 and stop supporting DocBoook4, I do not belive anyone still uses DocBook4 anyway).
@fsundermeyer there is a package, but it was rejected when I sent to Factory as it was breaking DAPS:
Download and test from here: https://build.opensuse.org/package/show/devel:libraries:c_c++/libxslt
Confirming the same problem for openSUSE.
@tomschr Seems it either is an upstream bug introduced in libxslt 1.1.35 or an unnoticed error in our profiling stylesheets that only surfaced with this libxslt version. See https://ftp.fau.de/gnome/sources/libxslt/1.1/libxslt-1.1.35.news for the upstream changelog
During profilng the href attribute of xi:includes gets lost, resulting in e.g.
<xi:include href="common_authors.xml"/> -> <xi:include/>
<xi:include href="book_daps_user.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/> -> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"/>
Could you investigate further?
@fsundermeyer: thank you for your answer.
@lopippo and @kraptor : In case you have DocBook5 sources with xi:includes available, would you mind checking if the problem occurs with DocBook5 as well? You can use the git checkout of DAPS as described at the bottom of https://github.com/openSUSE/daps/blob/main/INSTALL.adoc. (The DAPS doc sources are DocBook4. In case this is a libxslt upstream error and this does not occur with DocBook5, I would convert the sources to DocBook5 and stop supporting DocBoook4, I do not belive anyone still uses DocBook4 anyway).
I tried running the process you mention, but I still need to have DocBook4:
configure: error: No DocBook 4 DTD not found
When I install the docbook-xml package (DocBook4.5), and then run make
, I get the same error as described in detail above.
How do I prevent running the code that builds the documentation? That would allow me to go through the build process only with DocBook5 and then I could test my own software user manual code (see http://msxpertsuite.org/user-manuals/pdf/minexpert2-doc.pdf).
Ah, by the way, you mention:
Debian, Fedora, Ubuntu
Not available, yet. Help is appreciated.
Once we have fixed the package build, reference the official daps package for Debian and Ubuntu: see here: https://qa.debian.org/developer.php?login=lopippo@debian.org
Thank you again for this wonderful package !
Sincerely, Filippo
With the libxslt 1.1.35 package being available for openSUSE I was able to test DocBook4 and DocBook5. the error occurs with both versions.
I've tried to build it for openSUSE Leap 15.3, but it failed. :cry: At the moment, I can't reproduce it on my machine.
Seems it either is an upstream bug introduced in libxslt 1.1.35 or an unnoticed error in our profiling stylesheets that only surfaced with this libxslt version. See https://ftp.fau.de/gnome/sources/libxslt/1.1/libxslt-1.1.35.news for the upstream changelog
The profiling stylesheets (if you mean daps-xslt/profiling/*-profile.xsl
) hasn't been changed for a while (last change was 2020 by Stefan, but that wasn't related to the mentioned files). The respective part which is important is this template:
# File daps-xslt/profiling/base-profile.xsl
<xsl:template match="xi:include/@href|
xi:include/@xpointer|
xi:include/@accept|
xi:include/@accept-language|
xi:include/@parse|
xi:include/@encoding" mode="profile">
<xsl:attribute name="{local-name()}">
<xsl:value-of select="."/>
</xsl:attribute>
</xsl:template>
It creates the respective attribute node and fills it with the value. This is standard XSLT, nothing strange. It worked so far, so I suspect this could be an upstream bug.
With the libxslt 1.1.35 package being available for openSUSE I was able to test DocBook4 and DocBook5. the error occurs with both versions.
At least you could confirm it. Thanks Frank!
@lopippo Have you reported that upstream?
@tomschr:
@lopippo Have you reported that upstream?
Well, no ; my first approach was to try and have a clearer view on that apparent bug... Which is starting to occur in this thread.
@tomschr Could you put together a simple test case/script for this and veryify that it behaves differently with 1.1.34 and 1.1.35? We could then use it to ask upstream and/or report a bug
@tomschr Could you put together a simple test case/script for this and veryify that it behaves differently with 1.1.34 and 1.1.35? We could then use it to ask upstream and/or report a bug
I've tested it in one of my already installed virtual machines (openSUSE Leap 15.4). I've started with the following versions:
libxml2-tools-2.9.12-150400.3.4.x86_64
libxslt1-1.1.34-150400.1.7.x86_64
libxslt-tools-1.1.35-lp154.134.1.x86_64
With the above versions it worked. Actually it was a mistake as I only partially updated the packages. For example, I was not able to update libxml2 to 2.9.14 due to some repo glitch. So I've updated to libxslt1-1.1.35-lp154.134.1. Additionally, I got libexslt0-1.1.35-lp154.134.1.x86_64.rpm installed as an additional dependency. With this combination I got your error message from above.
However, although I made a mistake at first, it seems the above error is rooted in libxslt1, not libxml2. When I have finished my other tasks, I can create a small test example.
I am on an up-to-date Tumbleweed. When I install libxslt1-1.1.35 (which does not pull in any dependencies or updates) I get the error. As soon as I replace it with libxslt1-1.1.34 the error is gone.
A new version of libxslt (1.1.36) was released. Tried to build DAPS against the new version, still broken.
Here you can see the build results and errors:
failed
status to see full build error).Here you can download 1.1.36 rpm to test/debug the issue:
Any news here? If we can't update libxslt we'll be missing security fixes.
I debugged this a bit. The XSL has:
<xsl:template match="xi:include/@href|
xi:include/@xpointer|
xi:include/@accept|
xi:include/@accept-language|
xi:include/@parse|
xi:include/@encoding" mode="profile">
<xsl:attribute name="{local-name()}">
<xsl:value-of select="."/>
</xsl:attribute>
</xsl:template>
<!-- Remove any non-XInclude attributes -->
<xsl:template match="xi:include/@*" mode="profile" />
So the xi:include/@href
attribute matches both of those rules. https://www.w3.org/TR/2001/WD-xslt11-20010824/#conflict states that the matching template with the highest priority is used. If there are multiple with the highest priority, the one defined last wins. With xsltproc
's --verbose
option it's visible that both templates get the same priority:
> /usr/bin/xsltproc --verbose --stringparam filename "MAIN.DAPS.xml" --stringparam show.comments "0" --stringparam profile.os "osuse;noquick" --stringparam profile.arch "x86;amd64;em64t" /home/abuild/rpmbuild/BUILD/daps-3.3.1/daps-xslt/profiling/docbook45-profile.xsl /home/abuild/rpmbuild/BUILD/daps-3.3.1/doc/xml/MAIN.DAPS.xml
...
added pattern : 'xi:include/@href' mode 'profile' priority 0.500000
added pattern : ' xi:include/@xpointer' mode 'profile' priority 0.500000
added pattern : ' xi:include/@accept' mode 'profile' priority 0.500000
added pattern : ' xi:include/@accept-language' mode 'profile' priority 0.500000
added pattern : ' xi:include/@parse' mode 'profile' priority 0.500000
added pattern : ' xi:include/@encoding' mode 'profile' priority 0.500000
xsltParseStylesheetTemplate: mode profile
xsltCompilePattern : parsing 'xi:include/@*'
xsltCompilePattern : parsed xi:include/@*, default priority 0.500000
added pattern : 'xi:include/@*' mode 'profile' priority 0.500000
...
Before libxslt 1.1.36 (https://github.com/GNOME/libxslt/commit/b0074eeca3c6b21b4da14fdf712b853900c51635), it took the template above instead.
I'm not sure whether it's correct to give all those patterns the same priority, but if that is the case the fix is to explicitly give the fallback rule a lower priority, i.e.
<!-- Remove any non-XInclude attributes -->
<xsl:template match="xi:include/@*" mode="profile" priority="0"/>
With that, daps builds successfully.
Thanks Fabian for your help. Much appreciated.
So the xi:include/@href attribute matches both of those rules.
Yes, seems xi:include/@*
and xi:include/@href
has the same priority (0.5). I would have expected the more specific pattern ( xi:include/@href
) has a higher precedence.
The XSLT spec in 5.5 Conflict Resolution for Template Rules says:
An XSLT processor may signal the error; if it does not signal the error, it must recover by choosing, from amongst the matching template rules that are left, the one that occurs last in the stylesheet.
For some reason, libxslt has chosen to signal an error. It could have chosen a different conflict resolution strategy.
Just a hint of caution: That is an old working draft and is for XSLT 1.1. If I'm not mistaken, the libxslt library still supports XSLT 1.0 only. We shouldn't refer to old working drafts, although for our specific case, it doesn't seem to matter.
I'm not sure whether it's correct to give all those patterns the same priority
Theoretically you could add priority
attributes for every template rule. However, that's not a good idea. You would circumvent the default selection which should be better left to the XSLT processor. You use the priority
attribute only if you have to overwrite the standard selection as an exception, not as a default.
For our specific use case, it's fine to add this single priority
attribute for xi:include/@*
, but not for every template rule. I will create a PR with your suggestion (see #685).
Thanks Fabian!
@kraptor Would you like to test our fix in PR #685 ?
Greetings,
thank you sooo much for the fix! I will thus patch the source code for version 3.3.1 and make a Debian package out of it. That is very cool because a number of packages had to be removed from Debian testing because of that issue.
daps rocks!
Filippo
@kraptor Would you like to test our fix in PR #685 ?
I confirm it works for me and I already sent an updated package to openSUSE. Thanks!
Problem description
When compiling with libxslt 1.1.35 it fails while validating some XML (MAIN.DAPS.xml).
After some investigation and comparing to when that file is created using 1.1.34, the issue seems related to missing hrefs in xi:includes, but I didn't find/know how the mechanism to build these files work.
Here are the differences.
<!DOCTYPE set PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">