[jdom-interest] Still more Verification

bob bob at accurev.com
Wed Aug 23 10:44:12 PDT 2000

> At 02:48 PM 8/23/2000 +0200, Tako Schotanus wrote:
> >And in what way would it be made "difficult"?  Because I sure as hell 
> >wouldn't like it if I would be forced to use slower code just because to 
> >force correctness on lazy programmers.  And the fastest code should be 
> >just as easy to use in my opinion.
> In most cases, the best answer is to make the checking code be on by 
> default, but then to have a means of turning it off that is not 
> horrendous.  

Well, for XML parsers, isn't DTD validation off by default?  Likewise,
I've read (somewhere) that DTD validation, at least, is a great and
wonderful thing for pre-production, while you are still checking to
make sure your inputs are correct.  But that it's wise to turn off
in production code (unless you'll be getting inputs from sources
out of your control.)

Likewise, the project I'm working on uses XML to communicate purely
between 1 client and 1 server, both of which Do The Right Thing, and
I don't want any extra validation occurring, either DTD or this
new stuff.  We *already* have some slight performance issues, and
yes, they are related to XML parsers.  I'd like not to add more.

Our client queries a server database, which returns Huge, already-verified 
documents.  Sure, we don't do the queries that often, so in real-world-time,
there isn't that much of a slowdown.  But, when the query is performed,
the user is left tapping his fingers waiting for a little while.  I
don't want to increase finger-tapping time at all.  (I'm already getting
pressure to not use XML for communication between client/server due
to performance.)

On a side note, would JDOM possibly take a page from the SAX-features
book, enabled features described by URIs?  If you want Rusty's validation,
then you could setFeature("http://jdom.org/validation", true).
Plus, by setting once, from a string, it allows a run-time change, and
doesn't introduce extra flavors of methods with a boolean flag.


More information about the jdom-interest mailing list