As close to the fringes of the system as possible. That varies, but in most cases, yes - I think it is the responsibility of the software using the higher level API.
If I have a stream of data that I want to feed to the PD APIs and I already KNOW that it is well-formed, I shouldn't have to pay the cost of validating it again. If it is NOT known to be valid, then I can insert validation prior to my submission to the PD api. And my validation process will be appropriate to my system. All that said, common sense has to reign. I'm speaking here in broad generalities. -----Original Message----- From: Johannes Koch [mailto:[email protected]] Sent: Wednesday, February 24, 2010 3:06 PM To: [email protected] Subject: Re: Check for allowed values in setters? Martinez, Mel - 1004 - MITLL schrieb: > The general rule of thumb is to validate as close to the source of input as > possible so that the corrective responses are most appropriate / contextual > with the way the data is input. I think a setter in a higher-level API (like the PD... classes) is pretty close to the input. Or do you mean the software using the higher-level API is responsible for validation? -- Johannes Koch Fraunhofer Institute for Applied Information Technology FIT Web Compliance Center Schloss Birlinghoven, D-53757 Sankt Augustin, Germany Phone: +49-2241-142628 Fax: +49-2241-142065
smime.p7s
Description: S/MIME cryptographic signature
