Yeah, I would be interested too in the official approach according to the Xerces authors. If it is the case that there is a downside to defining a custom URL protocol, then I would assume that there is another preferred way of doing it. As for putting path information into the SystemId, that is not an option for me, as our xml files are coming from external businesses, and requiring them to specify a path limits our ability to implement internally. I guess I am interested in the reason that the SystemId is changed -- is there some reason for this? If not, this would be easily fixed by returning the literal SystemId from the xml file.
Brad -----Original Message----- From: Milind Gadre [mailto:[EMAIL PROTECTED] Sent: Monday, February 19, 2001 2:39 PM To: [EMAIL PROTECTED] Subject: Re: Windows Paths Brad, > [...snip...] There was a thread that I started last week about the fact > that if someone references a dtd in their XML file, e.g. data.dtd, the > systemId passed in as a parameter (assuming the xml file is > "c:\test\data.xml") will have a value of "file:///test/data.dtd". This is a > problem for a couple of reasons -- first, it isn't the literal value present > in the XML file, so instead of evaluating what literally resides in the XML > file, the parser requires "intelligence" to be added to the resolveEntity > method beyond simply testing for the String present in the XML file. As I mentioned earlier, this is a bit of a pain. Here is another possible solution (which happened to be frowned upon in an unrelated posting by someone else). 1. Define your own URL protocol: call it 'brad:' for argument's sake. 2. Define your SYSTEM ID as: "brad://data.dtd". This will prevent the 'mangling' and your EntityResolver will see the systemId verbatim. 3. Attach an EntityResolver that specifically checks for the 'brad:' protocol and does the right thing. I have run into this a sufficient number of times to raise it again and see if any of the Xerces authors have any insights. Here is what I wanted to do: 1. Package all my DTDs in a distributable JAR file. 2. Specify the DTD as SYSTEM "/com/company/dtds/abc.dtd" 3. If systemId started with '/', then use the class loader rules to look for it - it would find it in the JAR file. Else return null to use the default Xerces rules. Kept getting stumped with the systemId being mangled *before* I got my hands on it. The possible solutions were A. Define a proprietary URL protocol called 'classpath:' - which was frowned upon for some reason that I cannot recall. This would prevent Xerces from mangling the systemId, and returning what I had specified verbatim. I would then check for 'classpath:', and do the needful, else return null. B. Use a PUBLIC id, and test for it as I suggested to Brad a few days ago. Apparently, this is related to something called DTD catalogs (XCatalog) about which I have not been able to find any further information. Suggestions, explanations etc would be welcome. Regards... Milind Gadre ecPlatforms, Inc 901 Mariner's Island Blvd, Suite 565 San Mateo, CA 94404 C: 510-919-0596 F: 815-352-0779 [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
