Hi Neil,
In answer to 1), yes, setting the IDs to null isn't right. I'll admit I'm
not familiar with custom entity resolves, and just assumed that they would
resolve the expanded system ID without testing it. Your solution of using
XMLEntityManager.expandSystemId() is the correct way, and I'll be sending a
fix for that mixed in with some other changes that I'm finishing up.
I believe 2) and 3) have already been answered by someone more
knowledgeable than myself.
Cheers,
Peter McCracken/Toronto/IBM
"Neil Pitman"
<[EMAIL PROTECTED] To: <[EMAIL PROTECTED]>
atico.ca> cc:
Subject: xinclude funnies
08/23/2003 09:35
AM
Please respond to
xerces-j-user
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
file:///c:/work/proj/main.xml
file:///c:/work/proj/part1/subpart1/abc.xml
file:///c:/work/proj/part1/subpart1/helper.xml
With the elharo xincluder, main.xml had <xi:include
href="part1/subpart1/abc.xml"/> and abc.xml contained <xi:include
href="methods.xml"/>. 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="part1/subpart1/abc.xml" within "main.xml" to try to resolve
"part1/subpart1/abc.xml" and href="helper.xml" 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
_________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
