Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
xinclude regression: non-recursive, mutual xinclude fails #295
As I understand the xinclude spec, it is legal to xinclude for document's to xinclude from each other as long as they don't loop: https://www.w3.org/TR/xinclude/#loops
When I process either of the following documents with xmlcalabash version 1.22 and earlier, it resolves the xincludes successfully. However, beginning in xmlcalabash 1.23, I now receive the error "err:XC0029:XInclude document includes itself: b.xml". It's possible that the fix for #273 introduced this regression.
Process the following files with Calabash:
The pipeline should produce an xml file with the xincludes resolved:
<article xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude" version="5.1"> <title>Title of a.xml</title> <para xml:id="a">Para in a.xml</para> <para xml:id="b">Para in b.xml</para> </article>
No problem. Another data point about the non-recursive mutual xinclude: @raducoravu from Oxygen reports that he's patched the Xerces libraries they use so that it supports some, but not all, cases of non-recursive, mutual xincludes. He has reported the bug to Xerces: https://issues.apache.org/jira/browse/XERCESJ-1694
There is another issue that also cropped up between 1.1.22 and 1.1.23: In certain circumstances, resolving xincludes takes a very long time. I've posted an example doc at http://feline.thingbag.net/slow_xinclude.zip
For this document, resolving xincludes takes much longer in 1.1.23 than 1.1.22:
There isn't a noticeable performance hit for most other documents, but when there is a large source file (e.g. 5.3M) with many (e.g. 170) tables and different tables are xincluded into the book in different places, the performance problem crops up.
dcramer@anatine ~/projects/slow_xinclude $ cat xinclude.xpl <?xml version="1.0" encoding="UTF-8"?> <p:declare-step xmlns:p="http://www.w3.org/ns/xproc" xmlns:c="http://www.w3.org/ns/xproc-step" version="1.0" name="main"> <p:input port="source"/> <p:output port="result"> <p:pipe port="result" step="xinclude"/> </p:output> <p:xinclude fixup-xml-base="true" name="xinclude"/> </p:declare-step> dcramer@anatine ~/projects/slow_xinclude $ time java -jar ~/Downloads/xmlcalabash-1.1.23-97/xmlcalabash-1.1.23-97.jar -i slow_xinclude.xml -o out.xml xinclude.xpl real 83m7.465s user 80m23.892s sys 0m51.265s dcramer@anatine ~/projects/slow_xinclude $ time java -jar ~/Downloads/xmlcalabash-1.1.22-98/xmlcalabash-1.1.22-98.jar -i slow_xinclude.xml -o out.xml xinclude.xpl real 0m20.700s user 0m28.958s sys 0m1.881s
I think this is an illegal loop per 4.2.7 of the XInclude specification.
Even though the xpointers identify regions that aren’t explicitly recursive, the infoset expansion has to be completed before the xpointers can be resolved.
I don’t see any way to complete the infoset expansion without encountering the