[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Fallacies of Validation, version #2

• To: Jonathan Robie <jonathan.robie@d...>
• Subject: Re: Fallacies of Validation, version #2
• From: Frank Manola <fmanola@a...>
• Date: Fri, 27 Aug 2004 10:07:09 -0400
• Cc: xml-dev@l...
• In-reply-to: <412E46BA.4040602@d...>
• References: <200408261412.i7QECKS10981@s...> <1093547898.412e377a2996d@h...> <412E46BA.4040602@d...>
• User-agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)

Part of the problem, though, is when the people defining the constraints 
think they know the requirements of actually performing the activity the 
program is supposed to help implement, but really don't;  or in the 
example you cite, think the address constraints they define will 
actually help deliver the goods, but they actually get in the way.  I 
experience this problem quite frequently.  My street "number" (some 
other street "numbers" in our neighborhood do too) has a letter in it: 
50A Butters Row (don't ask me why:  I'm not responsible for how 
addresses are assigned here).  Sometimes a program accepting addresses 
won't allow me to enter the letter (or the letter magically becomes an 
apartment number, which it isn't;  this is a single-family house), 
because the writers of the constraints think they know how addresses are 
supposed to look.  Not having a street number that matches the actual 
address of the house doesn't help delivery very much.

--Frank

Jonathan Robie wrote:
>  >From Michael Kay:
> 
>  > The strategy (validating the user's address) assumes that
>  > you know better than your customers what constitutes a
>  > valid address. Let's face it, you don't, and you never
>  > will. A much better strategy is to let them (the user) express
>  > their address in their own terms. After all, that's what they
>  > do in old-fashioned paper correspondence, and it seems
>  > to work quite well.
> 
> In old-fashioned paper correspondence, addresses are interpreted by 
> human beings, and this is a perfectly fine strategy in an application 
> that formats addresses so that they can be read by human beings.
> 
> But if I have a program that needs to be able to identify customers in a 
> given region, or that needs to be able to compute the shipping costs 
> before sending an item, then my program needs to know how to read the 
> address. I'm not asking the customer to provide an address in a format 
> that they might recognize, I'm asking the customer to provide an address 
> in a format that my program can use. In that context, even if the 
> customer finds it a little painful, I'm going to make them communicate 
> at least the basic information.
> 
> For addresses, many applications have a certain middle ground. They 
> insist on knowing the country and postal code, and perhaps street name 
> and number, but allow other information to be added in a way that the 
> program might not recognize. One more useful application of partial 
> understanding.
> 
> Jonathan
> 

• Follow-Ups:
  • Re: Fallacies of Validation, version #2
    • From: w3c@d...

• References:
  • Fallacies of Validation, version #2
    • From: "Roger L. Costello" <costello@m...>
  • Re: Fallacies of Validation, version #2
    • From: Bryan Rasmussen <bry@i...>
  • Re: Fallacies of Validation, version #2
    • From: Jonathan Robie <jonathan.robie@d...>

• Prev by Date: RE: Fallacies of Validation, version #2
• Next by Date: XML Validation in Fortran
• Previous by thread: Re: Fallacies of Validation, version #2
• Next by thread: Re: Fallacies of Validation, version #2
• Index(es):
  • Date
  • Thread