Hi Alexey, No one has got around to reviewing it yet.
Thanks. 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/15/2013 06:56:56 PM: > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
