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 Tue, 13 Nov 2001 18:54:48 GMT
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.

As we said, we can write the validation code in the application but this has
too problems:

1. More code to write and maintain.

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 ?

Tal

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


Mime
View raw message