[
https://issues.apache.org/jira/browse/XERCESC-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852089#action_12852089
]
Boris Kolpackov commented on XERCESC-1918:
------------------------------------------
Keith, thanks for the patch. I would like to commit it, however, the project's
charter[1] requires me to get the answers to the following questions from you
before I can do this:
a) Name and employer
b) Are you the author of the code being contributed?
c) Do you have the right to grant the copyright and patent licenses for the
contribution that are set forth in the ASF v.2.0 license
(http://www.apache.org/licenses/LICENSE-2.0)?
d) Does your employer have any rights to code that you have written, for
example, through your contract for employment? If so, has your employer given
you permission to contribute the code on its behalf or waived its rights in the
code?
e) Are you aware of any third-party licenses or other restrictions (such as
related patents or trademarks) that could apply to your contribution? If so,
what are they?
If you can provide the answers as a comment for this issue, that would be great.
[1] http://xerces.apache.org/xerces-c/charter.html
> XInclude broken with multiple level includes
> --------------------------------------------
>
> Key: XERCESC-1918
> URL: https://issues.apache.org/jira/browse/XERCESC-1918
> Project: Xerces-C++
> Issue Type: Bug
> Components: Non-Validating Parser
> Affects Versions: 3.0.0
> Environment: linux, windows
> Reporter: keith mcneill
> Attachments: xerces-c-xinclude.diff, xinclude-bottom.xml,
> xinclude-middle.xml, xinclude-top.xml
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
