From: james@...
Date: 2002-06-11T04:20:16+09:00
Subject: RE: ANN: REXML 2.3.5 && 2.2.3

> >  I tend to believe that
> > you can't have enough validation.
>
>
> I agree.


What I've found, though, is that that cost of incessant validation is often
much greater than the cost of recovering from an exception when bad data or
markup is allowed too far along a processing path.  It is, in some ways,
similar to static types in a programming languages.

If you're passing along financial information then perhaps obsessive
validation is a good thing (though even then the validation should focus on
amounts and account information, i.e. the data, not the markup).  If you're
processing less-critical XML-RPC requests, then its arguably simpler to let
bad requests simply fail somewhere along the processing path.  For most of
what I've worked on, so long as the XML was well-formed, and had some
minimum amount of data, it was worth trying to do something with it.
Regular expressions served as the most practical form of validation;
anything remotely like a schema was overkill.


Larry Wall once said that systems should be generous in what they accept,
and strict in what they emit.
http://www.oreilly.com/catalog/opensources/book/larry.html

It's a rather broad statement, but I've taken to mean that the burden of
correctness is on the sender.  The receiver needs only do enough to balance
the cost of a possible problem with the cost of problem prevention.  One
system I worked on received XML requests for hotel reservations.  Now, the
code could have a) checked the request against a schema, and then b) move
on to extracting the data and processing.  Or just do (b).  If the data or
markup was bad, then just doing (b) meant an exception was raised after
some wasted processing (i.e., the work done until the bad data or markup
was encountered was fruitless)

However, 99.999% of the time the request was fine.  So, had we done
"proper" validation, far more wasted processing would have occurred.

Preventing a problem may be more of a problem then the problem you're
trying to prevent.

James