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]


Reply via email to