commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject RE: [digester] forcing a specific DTD
Date Tue, 13 Nov 2001 19:26:00 GMT


On Tue, 13 Nov 2001, Tal Dayan wrote:

> Date: Tue, 13 Nov 2001 10:54:48 -0800
> From: Tal Dayan <tal@zapta.com>
> Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> Subject: RE: [digester] forcing a specific DTD
>
> Hi Arun,
>
> When I used the Tomcat example, this was from the view point of the user
> that
> write the XML file. How Tomcat does it is an implementation issue that can
> be changed at anytime.
>
Tomcat doesn't actually do a validating XML parse (against a DTD) of the
server.xml file.  This is because the set of attributes for the various
elements like <Valve> and <Logger> are open-ended.  It is not possible to
write a complete DTD for server.xml that will cover everything.

> As we said, we can write the validation code in the application but this has
> too problems:
>
> 1. More code to write and maintain.
>

DTDs are all right for some purposes, but they are by no means sufficient
to perform what I think of as validation.  For example, there's no way I
can say in a DTD, going back to Tomcat as an example again, that "the
servlet name referenced in this <servlet-mapping> must have already been
defined in a <servlet> definition".  XML Schema is getting closer to this,
but there are still going to be things that you can only validate in the
actual application.

> 2. I am not sure if the application that uses Digester has all the
> information about the XML, at least not from what I saw after a brief usage
> of the rules. For example, if the user misspelled the name of an option tag,
> does the Digester pass it at all to the application ?
>

No.  Digester is a pattern matching application that silently ignores
everything that doesn't match the patterns for which you have registered
rules.  If you want *all* the content, you should parse the document
yourself.

> Tal
>

Craig


> > -----Original Message-----
> > From: Arun M. Thomas [mailto:AMammenT@yahoo.com]
> > Sent: Tuesday, November 13, 2001 9:56 AM
> > To: Jakarta Commons Developers List
> > Subject: RE: [digester] forcing a specific DTD
> >
> >
> > Tal,
> >
> > Note that you can register a local copy of
> > the dtd against which you'd like to process
> > a document using the digester.register()
> > method.  You can also require that the user
> > supply the correct PUBLIC Id (as per your
> > documentation or template) simply by checking
> > the public id via the digester.getPublicId()
> > method.
> >
> > (I haven't actually had a need to do this,
> > but it does seem to be possible :)
> >
> > It doesn't satisfy all your requirements; e.g.
> > the user must still ensure that a public and system
> > id are present in the XML file.  However, this can
> > probably be handled simply by documenting the
> > required Public ID.  Also, validating against a
> > dtd other than that visible to the user in the
> > XML file is misleading to the user if there is
> > an error occuring.
> >
> > However, note that the Tomcat example you provided
> > is slightly at odds with what I understand you're
> > trying to accomplish.  Tomcat parsing simply defers
> > all validation to the application itself.  As you
> > said, the Tomcat implementation does the magic of
> > validation.  Here, you're hoping to have the digester
> > do some of that magic so that your particular
> > application code doesn't need to do so.   If you're
> > willing to code all the validation rules into
> > your application, you wouldn't need to use a
> > validating parser.
> >
> > Cheers,
> > -AMT
> >
> > -----Original Message-----
> > From: Tal Dayan [mailto:tal@zapta.com]
> > Sent: Tuesday, November 13, 2001 9:05 AM
> > To: commons-dev@jakarta.apache.org
> > Subject: [digester] forcing a specific DTD
> >
> >
> >
> > We plan to use Digester for parsing XML based configuration files
> > and would
> > like
> > to use a DTD to save some validation code. From the Digester documentation
> > it seems that the DTD based validation works as follows, the user
> > specifies
> > an arbitrary DTD, and digester.parse() makes sure the XML document matches
> > the user's specified DTD.
> >
> > We have two problems with this approach:
> >
> > 1. When we parse a file, we know what DTD it should conform to so there is
> > not need require the user to type it (e.g. when Tomcat reads
> > server.xml, the
> > user does not care about the DTD, it should be up to Tomcat to do
> > the magic
> > of validating it).
> >
> > 2. The user can specify arbitrary DTD but we want to validate against a
> > *specific* DTD. It does not help us much if we know that the XML
> > conforms to
> > some arbitrary DTD the user specified (this reminds me an old
> > joke, a man is
> > asked by the bank manager to identify himself, he pull a picture
> > of from his
> > pocket and says 'that's me').
> >
> > Any idea how to address these issues ?
> >
> > A good solution would be example a digester.forceSpecificDTD(...) method
> > that forces a specific DTD for that instance of the parser. This
> > makes sense
> > since the digester is configured anyway (via the set of rules) to parse a
> > specific type of XML document.
> >
> > Thanks,
> >
> > Tal
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> > <mailto:commons-dev-help@jakarta.apache.org>
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message