To further illustrate the issue, I have created a small test case - 5 XMLs included from each other. Each of the XMLs references an external file with the same base name (1.xml references 1.svg, 2.xml -> 2.svg, and so on). By the specification of xml:base, it is assumed that these references should refer to files in the same directory as the XML itself. The directory structure is:
1.xml [includes dir/2.xml] dir/2.xml [includes ../3.xml, 4.xml and dir2/5.xml] 3.xml dir/4.xml dir/dir2/5.xml Then, there is a stylesheet listrefs.xsl which outputs the resolved entities. To resolve references using xml:base, I copied the templates used by DocBook XSL stylesheets (1.78.0). Here is the output: [xsltproc 1.1.27 using libxml2 TOT without the fix] 1.svg dir/2.svg dir/3.svg dir/4.svg dir/dir2/5.svg [xsltproc 1.1.27 using libxml2 TOT with the fix] 1.svg dir/2.svg 3.svg dir/4.svg dir/dir2/5.svg So, with the fix 3.svg is now correctly resolved to point to "3.svg" rather than "dir/3.svg". Now, the weird thing: I also tried the same stylesheet with Saxon: [saxon HE 9.4.0.6J] Warning: at xsl:stylesheet on line 2 column 80 of listrefs.xsl: Running an XSLT 1 stylesheet with an XSLT 2 processor 1.svg dir/2.svg dir/3.svg dir/dir/4.svg dir/dir/dir2/5.svg It looks like Saxon outputs xml:base on each element relative to the top-level document, not to the containing included document. I wonder if Saxon's handling of xml:base fixup with XIncludes is completely broken, or libxml2 and DocBook XSL developers both misunderstood the xml:base specification. Regards, Alexey. On Monday, April 08, 2013 12:49:45 PM Alexey Neyman wrote: I think I know what is causing the issue. The code in xmlXIncludeLoadDoc looks at the url argument to see if it is relative path - to do so, it looks for slashes in the path. The problem is that xmlXIncludeLoadNode() passes down URIs that are relative to the top- level document, not to the most recent inclusion. Therefore, in the example below the url in xmlXIncludeLoadDoc() is just '3.xml', not '../3.xml' - and thus, the code wrongly considers it to be based in the same directory as the current included file. The attached patch solves this problem. It removes a premature check on the 'url' argument - even if does not contain slashes, it may be a relative URI. Instead, it proceeds to build a URI relative to current node's base, and only aborts xml:base insertion if that relative URI does not contain slashes. With this patch, the output from the test is: <?xml version="1.0"?> <top xmlns:xi="http://www.w3.org/2001/XInclude";> <elem1 xmlns:xi="http://www.w3.org/2001/XInclude"; xml:base="dir/2.xml"> <elem2 xmlns:xi="http://www.w3.org/2001/XInclude"; xml:base="../3.xml"> <a fileref="x.svg"/> </elem2> </elem1> </top> Regards, Alexey. On Monday, April 08, 2013 12:36:08 AM Alexey Neyman wrote: Hi all, I am encountering the following strange behavior with regard to xml:base. Here is an example: ----[ 1.xml ]---- <?xml version="1.0"?> <top xmlns:xi="http://www.w3.org/2001/XInclude";> <xi:include href="dir/2.xml"/> </top> ------------------ ----[ dir/2.xml ]---- <?xml version="1.0"?> <elem1 xmlns:xi="http://www.w3.org/2001/XInclude";> <xi:include href="../3.xml"/> </elem1> --------------------- ----[ 3.xml ]---- <?xml version="1.0"?> <elem2> <a fileref="x.svg"/> </elem2> ------------------ Now, if I process 1.xml with 'xmllint --xinclude', I get: $ xmllint --xinclude 1.xml <?xml version="1.0"?> <top xmlns:xi="http://www.w3.org/2001/XInclude";> <elem1 xmlns:xi="http://www.w3.org/2001/XInclude"; xml:base="dir/2.xml"> <elem2> <a fileref="x.svg"/> </elem2> </elem1> </top> The question is, why is xml:base missing on elem2? It is included from a different location than its ancestor, elem1. Is it a bug in libxml2, or am I missing something in the XInclude specification? As far as I can see, XInclude says: "Each element information item in the top-level included items which has a different base URI than its include parent has an attribute information item added to its attributes property." In this case base URI for elem2 is different than that for elem1 - so I think xml:base should be present.
testcase.tgz
Description: application/compressed-tar
_______________________________________________ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
