[XERCESC-1918] XInclude broken with multiple level includes

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.0.0
• Fix Version/s: 3.1.1, 3.2.0
• Component/s: Non-Validating Parser
• Environment: linux, windows
• Assignee: Boris Kolpackov
• Reporter: keith mcneill
• Created: 31/Mar/10 17:14
• Updated: 11/Apr/10 17:36
• Resolved: 11/Apr/10 17:36

Description

If you use xinclude on multiple levels (> 2) with relative path names. XInclude will break with an error something like "no scheme".
I tracked this down to a problem in XIncludeUtils::doDOMNodeXInclude.

When an includeDoc was found it created a DocumentFragment to hang the new copied nodes off of. At the end of processing it would paste the DocumentFragment on to the document. The problem was that DocumentFragment lost the absolute path in its getBaseURI(). This absolute path also contained the scheme.
This diff fixes XInclude by not using a DocumentFragment. We just use insertBefore() to insert the new nodes in the destination document in order. This way the getBaseURI() is never lost.
I've also included a fix to XIncludeLocation.prependPath(). PrependPath used to slam a new path on the beginning of the current path without checking to see if the current path already had a scheme. For example you could end up with paths like: file:///new/parent/file:///old/child. Now it will produce file:///new/parent/old/child. XIncludeLocation probably needs to get smarter about dealing with schemes & URI's in general.

I've included a diff an example files that can be run with the XInclude sample.

Note that with these fixes the xerces c++ xinclude behaves more like the java xinclude support.