XInclude Implementation Problems

[Michael Glavassevich]

Hi everyone,

I was just looking at some of the changes which have gone into the XInclude implementation since the last release and I have some concerns about the support for content negotiation [1] (added in the latest working draft of XInclude).  Currently we're opening a URLConnection to set the Accept, Accept-Language, Accept-CharSet request properties and setting the input stream from this URLConnection on the input source in XIncludeHandler.  Since we're modifying the input source before the parser (or text reader in the case of text includes) has had a chance to see it this has the unfortunate side-effect of trampling code which needed to read the URLConnection. The parser currently needs the URLConnection to follow HTTP redirects. The text reader needs the URLConnection to determine the encoding of the text include. Because we process the URL too early this information is lost.  Another problem with opening a URLConnection this early is that we're doing it before consulting the user's entity resolver.  The include location specified in the instance document may not be the one we're actually loading, and if it's non-URL URI or some protocol Java doesn't support we're going to report a fatal error.  And if the user provides a new system id when the parser calls their entity resolver their content negotiation preferences won't be picked up.

Fixing the problem for text includes should be fairly straightforward.  I volunteer to do it.

For xml includes I think we should postpone providing support for content negotiation to a future release.  At the moment, I don't see how we can make it work cleanly since we spawn another parser to handle the includes.

[1] http://www.w3.org/TR/xinclude/#content-negotiation

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: [EMAIL PROTECTED]
E-mail: [EMAIL PROTECTED]