Another patch ping...

It's been almost two weeks since the original email. Is this list alive?

Regards,
Alexey.

On Thursday, April 11, 2013 10:54:18 PM Alexey Neyman wrote:


Patch ping...

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.

This affects DocBook stylesheets: when they attempt to insert the references to 
external graphics (e.g. fo:external-graphic for XSL-FO output), they analyze 
xml:base 
on all of the element's ancestors. With inclusion like this, it incorrectly 
resolves the file 
reference like a/@fileref above to point to dir/x.svg. Any workarounds?

I am using 2.9.0 now, haven't tried with the "bleeding edge" yet.

Regards,
Alexey.






_______________________________________________
xml mailing list, project page  http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml

Reply via email to