commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jon Steelman" <>
Subject RE: [Digester] How to digester.register(String publicId,StringentityURL) for local dtd file?
Date Thu, 16 Jun 2005 04:52:43 GMT
Yes, I saw those postings- thanks. Unfortunately I don't control that
incoming xml having SYSTEM but I must somehow handle it. Sorry, being
new to Digester and XML processing, I might sometimes stumble into
asking the same thing when I re-read your posts on that
other thread, they make perfect sense! :-) Looks like I might have to
roll my own custom EntityResolver.


-----Original Message-----
From: Simon Kitching [] 
Sent: Thursday, June 16, 2005 12:35 AM
To: Jakarta Commons Users List
Subject: Re: [Digester] How to digester.register(String
publicId,StringentityURL) for local dtd file?

On Thu, 2005-06-16 at 00:13 -0400, Jon Steelman wrote:
> Digester's documentation shows the following as an example of how to
> tell Digester where to find a local copy of a dtd, in this case a
> config file:
> URL url = new
> digester.register("-//Apache Software Foundation//DTD Struts
> Configuration 1.0//EN", url.toString());
> For a Struts file that begins with these 2 lines:
> <?xml version="1.0" encoding="ISO-8859-1" ?>
> <!DOCTYPE struts-config PUBLIC
>        "-//Apache Software Foundation//DTD Struts Configuration
>               "">
> Now, in my case, for an xml file that starts with these 2 lines:
> <?xml version="1.0"?>
> <!DOCTYPE cardActionVendor SYSTEM "cardActionVendor.dtd">
> Apparently SYSTEM and PUBLIC differ and I'm not sure how to go about
> in this case. How would you do the equivalent to tell Digester where
> find the local copy? If I drop a copy of the dtd into the directory
> where Java is executing, it works, but I need to specify a different
> directory either relative or absolute.

SYSTEM is a totally non-portable identifier that is really only useful
on the same machine the document was created on.

PUBLIC is a portable identifier that is essentially a key used to look
up the real location of the corresponding resource. An application
receiving a document from a remote source is expected to register local
copies of the relevant document by public id, so the lookup returns a
local copy.

A document that is meant to be used across machines which omits the
PUBLIC identifier is broken.

Have you not seen the replies to your earlier question on this topic
from Thomas and myself?

Mapping system ids through to other URLs is just plain wrong; properly
designed XML documents should always have a PUBLIC id. This is why
Digester.register does not support mapping SYSTEM ids. However it
appears from Thomas' email that the entity resolver does
support this (ie helps people with broken xml documents) so that's one



To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message