web services. everything's a service now, which means you're moving data in and out of various services and, thus, through a zillion ways for storing data (xml, json, mysql, oracle, whatever) the problem with spaces and dashes is how those various languages and databases handle spaces, dashes, special characters.
dont know if that counts as a "stupid" reason for you? it's not a user issue since we all know that users find it much easier to use the dashes and spaces than not. usability-wise, they probably should create three fields as is customary so you have one field for area code, one field for exchange, one field for the last four digits.
two issues happened today for just the resons i've described here. someone pulls a zip code off a word doc, pops it into a field in a legacy tool. The copy paste yanks the proprietary code for a space from Word, drops it in the field on a coldfusion-based legacy product with no error check that strips bad or useless data. Since the customer service rep was using this ancient tool for some bizarre reason, the customer couldn't find the product in search results on his zip code. The space fucked with the zip code for the product, excluding it from a search on the zip. If you searched on some other attribute, you could find it.
another issue today had to do with data not converted safely for processing in XML. Working with a third party API, we got errors indicating that the third party service simply croaked. XML error, since XML is effed: One piece of bad data, it dies. Customer had entered an ampersand into the field and the third party service hadn't associated the xml schema with an entity set. ooopsy.
>Ten years since I've been in IT and I don't miss it. I still get
>emails from recruiters for Tibco work. Anybody want me to forward
>them?
>
>
>--
>Andy
>___________________________________
>http://mailman.lbo-talk.org/mailman/listinfo/lbo-talk
-- http://cleandraws.com Wear Clean Draws ('coz there's 5 million ways to kill a CEO)