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

Re: Fallacies of Validation, version #2


two middle initials
Frank,

Which reminds me - 7% of the US population has two middle initials in their
name.

So why does most every computer system stateside insist on allowing only one
middle initial?

I get around this by putting in my first name as 'David RR' since there is no
checking on spaces in First names!

I emphasize on street addresses.  I've never quite figured out why the USA
decided on 4 digit house numbers. In Europe you start from 1 and proceed.  Very
few streets have more than 9,999 houses on them!!

The UPU has actual developed very good rules for all this stuff - but as I noted
earlier - there is no incentive - or means - for the schema-herd to avail
themselves of all this good work.

Notice how automation itself tries to impose artificial constraints to make the
life easier for the developers (another of my pet peeves).  So instead of
permitting and managing edge conditions - they simply attempt to bulldoze them
away - aka only allowing a single middle initial is "good enough for most
people".

In Venezula mail is still sorted by hand - this means that addresses have very
flowery and creative formats - depending on which part of town mail is for. 
E.g. business district, posh part, or scruffy.  In England you used to be able
to get mail delivered by putting just the Postal Code (which gets you to the
street, and side of the street) and then putting things like, 'third house on
the left, with pink shutters, past the 'Rose and Crown'.  This of course is
very useful if you want to send a 'Thank You' note to the kind people who let
you sleep in their coal shed after a heavy session in the aforementioned
hostelry!  But we digress...

Having constraint systems that can manage local contextual needs is clearly the
answer IMHO.

Cheers, DW

 Quoting Frank Manola <fmanola@a...>:

> 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
> > 
> 
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
> 
> 



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.