commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tal Dayan" <...@zapta.com>
Subject RE: [digester] forcing a specific DTD
Date Wed, 14 Nov 2001 02:44:25 GMT


> 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.

Yes, the DTD is mostly for validating the context free aspect of the XML
dialect in use. The rest may be done in the application. Howevever, having a
validation against a DTD is already a great time saver and requires less
code in the 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.

I definitly don't want *all* the content, this is why I use Digester ;-)  My
point is that
even if you are ready to add validation to the application, it does not have
the ability to
do it 100% because Digester filters out some of the information. In any
case, I think a DTD
validation is the way to go for first level validation and then to perform
the rest
in the application.

Tal

>
> > 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>


--
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