Hi Michael, Indeed, it looks like the issue.
But, that bug report has a patch attached to it. Why hasn't it been integrated? Thanks, Alexey. On Wednesday, May 15, 2013 01:27:52 PM Michael Glavassevich wrote: > Hi Alexey, > > It's very likely that you've hit XERCESJ-1102 [1] where the xml:base > values are not being computed correctly. This is a long standing issue in > the XInclude implementation. > > Thanks. > > [1] https://issues.apache.org/jira/browse/XERCESJ-1102 > > Michael Glavassevich > XML Technologies and WAS Development > IBM Toronto Lab > E-mail: [email protected] > E-mail: [email protected] > > Alexey Neyman <[email protected]> wrote on 05/14/2013 05:03:36 PM: > > Hi, > > > > I've noticed an issue with the xml:base fixup performed by Xerxes-J > > parser: it > > looks like Xerxes generates xml:base attribute relative to the top-level > > > > document rather than relative to the base of the including nodeset. As > > far as > > > I understand the XInclude specification, it requires xml:base be > > relative to > > > the including nodeset (otherwise, the resulting nodeset cannot itself be > > > > included from a document with a different base). My understanding > > ofXInclude > > > was also confirmed on the DocBook XSL mailing list: > https://lists.oasis-open.org/archives/docbook-apps/201305/msg00052.html > > > "The XInclude spec says that xml:base attributes must be relative > > to the closest ancestor xml:base. I'm pretty sure that is how Saxon 6 > > behaves. If Saxon9 is generating xml:base attributes always relative > > to the top level, then that is not what the XInclude spec says, nor > > what the DocBook stylesheet expects." > > > > The issue is manifested in both Saxon and Xalan. Attached is a > > smalltestcase > > > that illustrates the issue. > > > > The expected output from the testcase is: > > > > 1.svg > > dir/2.svg > > 3.svg > > dir/4.svg > > dir/dir2/5.svg > > > > Xerces-based XSLT processors produce: > > > > 1.svg > > dir/2.svg > > dir/3.svg > > dir/dir/4.svg > > dir/dir/dir2/5.svg > > > > Note the extra "dir/" prepended to lines 3..5 - that's because > > thesefiles are > > > referenced from XMLs included from dir/2.xml. This is a result of > > inclusion: > > <elem1 xmlns:xi="http://www.w3.org/2001/XInclude";> > > > > <a fileref="1.svg"/> > > <elem2 xml:base="dir/2.xml"> > > > > <a fileref="2.svg"/> > > <elem3 xml:base="dir/../3.xml"> > > > > <a fileref="3.svg"/> > > > > </elem3> > > <elem4 xml:base="dir/4.xml"> > > > > <a fileref="4.svg"/> > > > > </elem4> > > <elem5 xml:base="dir/dir2/5.xml"> > > > > <a fileref="5.svg"/> > > > > </elem5> > > > > </elem2> > > > > </elem1> > > > > As you may see, the xml:base are inserted relative to the top-level > > document > > > base. > > > > Is it a bug in Xerxes? > > > > Regards, > > Alexey. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected]
