[
Lists Home |
Date Index |
Thread Index
]
> Michael, your messages and examples are precise and compelling.
> Would you mind elaborating more upon what you see as
> the role of validation?
I see two main roles for validation:
(a) to protect the system from data that it cannot handle. If the system can
only handle 7 values for the "colour" attribute of a car, then it should
validate incoming data to check that it has one of those 7 values. It would
be better to design the system to handle more colours, but if you can't
afford to do that, then you must check that the incoming data fits within
the design limits of your system.
(b) to enforce a contract. If you have a contract with the supplier of a
news feed that all articles sent will carry either today's or yesterday's
date, then you should check that your supplier is keeping to the contract.
(You need to be very clear about what you plan to do when validation fails.)
There is also scope for reasonableness checks to catch data input errors.
But they belong as close to the user interface level as possible, not at the
information management level.
> Should there be levels of validation as I suggested last week?
In the sense that there are always layers of protocol, then yes. XML
well-formedness and validity checking can be seen as two such levels.
I think there is also room for validation processes that check data to see
if it conforms to business rules. But very often, that should result in some
kind of exception reporting, rather than rejection of the data. Often it
will be correct, valid data, revealing that the business rules have indeed
been breached.
Michael Kay
|
