Schema Datatype Limitations - Data Architecture Insights

["Magick, Brian" <Brian.Magick@COMPAQ.com>]

The more I work with XML Schemas the more I am discouraged by how
complicated it can be to work with the datatypes in terms of validation.

Case 1.  Monetary amounts.  Our source systems allow amounts to be
represented in a number of ways.  1,000.00 and 1000.00 are the same thing
and can be resolved by the receiving RDBMS.  This seems ridiculously
complicated to validate with XML Schemas as a pattern would need to be
written that accounts for the possible comma that can occur every three
digits out.  Does anyone have such a pattern written already?

Case 2.  Dates.  Dates are also too complicated to work with in many cases
with XML Schemas.  I won't get into this one but I'm sure many of you have
seen the issues surrounding custom dates (which is a big issue since dates
can be described in so many patterns). 

Perhaps rather than complaining about the limitations of XML Schema and its
datatypes it is worth taking a more constructive approach.  As we work in
our organizations to implement XML solutions and we come across dilemmas
like the ones above this allows us to take a second (or third in many cases)
look at the source and receiving systems that interact in our messaging
environment.  One must ask questions like "Why is there more than one
standard date format.....why does the receiving system have to translate
dates so that it can receive them in different formats from multiple
systems".  "Why are dollar amounts sent from different systems in different
formats?"  Perhaps XML is just what the doctor prescribed in terms of
revisiting your companies data architecture and gaining some ammunition for
revisiting some efforts with a more common set of data principles in hand.

Would anyone like to share their insights on XML's impact on Data
Architecture efforts?  Any success stories (or nightmares) related to data
architecture and XML?