I'll preface this with "I'm a bit new to digging
around in Xerces and XInclude". (Xerces always worked, but then I wasn't
using new, beta features.)
I'm trying to make Saxon 7.6.5 (XSLT) work with
Xerces 2.5.0 (tarball not recent cvs) using XInclude and SAX with my
own XMLEntityResolvers/EntityResolvers. Saxon has it's own issues but
that's for another mailinglist. Once upon a time, I would preprocess my
files with Elliot Rusty Harold's Xincluder from SourceForge into a separate
XML. Now I'd like to stream it in situ. (that means that the input
files are understandable by elharo's implementation so they are less
suspect). The trick is to change the OS based file references into
arbitrary key references.
Here is what I understand. My questions
follow.
Soon after hitting the include element,
org.apache.xerces.xinclude.XIncludeHandler.handleIncludeElement(XMLAttributes attributes) is called. He creates a XMLResourceIdentifier with an
explicit null public id and an explicit null expanded system id
(the literal system id is retrieved from the href and represents a relative
"file". This is what I used to use with XIncluder).
When he determines
that there is, indeed, a resolver, he calls EntityResolverWrapper holding my
resolver. First the wrapper checks that the public id and system id (the
expanded one) are not null. They are so he exits
immediately.
I "fixed" this using
XMLEntityManager.expandSystemId() to produce the expanded system id in
handleIncludeElement where the XMLResourceIdentifier is first
created.
Now with the EntityResolverWrapper getting a
reasonable system id, my resolver gets a reasonable id and it attempts to
load the first xinclude. The system id's are now a mixture of my keys and
file bases. My entity resolver is completely memory based so the file
based URI's are confusing. For example:
In the old system running from the file system
there were three files
With the elharo xincluder, main.xml had
<xi:include
href=""/> and abc.xml contained <xi:include href=""/>. My Resolver
receives file:///c:/home/npitman/part1/subpart1/abc.xml. It gets the "file:///c:/home/npitman/"
part from the running location of the application. XMLEntityManager
noticed that the base system id of "main.xml" was null so he assumed that he
would need a real URI and that should be based on the current working
directory. In the memory-based situation, the hrefs are not so
much URI's as keys. I'm expecting just "part1/subpart1/abc.xml".
This is what I find in the literal system id.
Unfortunately, this helps little because the first include xincludes a
second. This has an href of "helper.xml". In my key system, I'd
expect to see "part1/subpart1/helper.xml".
Questions:
1) What is going on in
org.apache.xerces.xinclude.XIncludeHandler.handleIncludeElement? Setting the id's to null can't be
right.
2) Is there a way to accept a blank base system
id?
I'd like href="" within "main.xml" to try to
resolve "part1/subpart1/abc.xml" and href="" within
"part1/subpart1/abc.xml" to try to resolve "part1/subpart1/help.xml".
3) Alternately, is the there an extension
mechanism, like the EntityResolver, to externalize expandSystemId()?
I suppose that the fallback would be to set the base system id of
main.xml to an abitrary scheme like "npitman://" and the look up
"npitman://part1/subpart1/abc.xml" and
"npitman://part1/subpart1/helper.xml"
Thanks for your patience
in reading.
_________________________________________
Neil Pitman [EMAIL PROTECTED] +1.514.863.5465 ICQ#: 21101052 _________________________________________ |
- xinclude funnies Neil Pitman
- Re: xinclude funnies Bob Foster
- Re: xinclude funnies Peter McCracken
- Re: xinclude funnies Neil Pitman