xmlcalabash1
xmlcalabash1 copied to clipboard
PIs causes empty base uris during XInclude resolving
Hi,
found a strange behavoir of resolving XInclude with p:xinclude
.
This is my main.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<root xmlns:xi="http://www.w3.org/2001/XInclude">
<xi:include href="module.xml"/>
</root>
This is the module.xml:
<?xml version="1.0" encoding="UTF-8"?>
<module>
<foo/>
<?pi?>
<bar/>
</module>
Note: the foo
element is before the PI, bar
comes later.
I process the main.xml with the following pipeline (main.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">
<p:input port="source" primary="true">
<p:document href="main.xml"/>
</p:input>
<p:output port="result"/>
<p:xinclude/>
<p:choose>
<p:when test="//foo/base-uri(.) = ''">
<p:error code="empty-base-uri">
<p:input port="source">
<p:inline><error>Foo element has no base-uri!</error></p:inline>
</p:input>
</p:error>
</p:when>
<p:when test="//bar/base-uri(.) = ''">
<p:error code="empty-base-uri">
<p:input port="source">
<p:inline><error>Bar element has no base-uri!</error></p:inline>
</p:input>
</p:error>
</p:when>
<p:otherwise>
<p:identity/>
</p:otherwise>
</p:choose>
</p:declare-step>
Logic summary: It loads the main.xml and processes the p:xinclude
step. At the end it throws an error if the foo
element has an empty base URI or if the bar
element has it. Otherwise it passes the document to the primary result port.
If I run it with the newest Calabash (1.4.1-100) I get the error:
main.xpl:0:empty-base-uri:Bar element has no base-uri!
If I move the PI before the foo
, I get the "foo-Error". If I move it after bar
, I get no error.
Conclusion: Elements after a PI seems to loose there base URI during XInculde resolving by p:xinclude
.
I added my example files (Maven based) including a sample for Saxon+XSLT which shows that it is a special Calabash issue.
That is definitely weird. I'll take a look.
The root cause is Saxon bug #5691 but I can work around it in the short term.
Fixed in 1.5.1, I believe.