Hi Peter, I guess you can ignore my patch then.
Thanks. _________________________________________ Neil Pitman [EMAIL PROTECTED] +1.514.863.5465 ICQ#: 21101052 _________________________________________ ----- Original Message ----- From: "Peter McCracken" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, August 27, 2003 10:46 AM Subject: Re: xinclude funnies > > > > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
