Lists Home |
Date Index |
Michael Kay wrote:
> Incidentally, it happens less often nowadays, but
> just yesterday I made an online purchase from a
> US supplier who required me to enter a two-letter
> code in the "State" box and a numeric value in the
> "postal code" box, despite the fact that I had
> entered UK as the country; so of course I lied,
> and they now have my state recorded as "ZZ" and
> the postal code as 12345. They also required a
> ten-digit phone number. Which reinforces another
> of my arguments: the more validation you do, the
> more you force people to supply incorrect information.
I believe this makes a good point for understanding the differences between
the use of elements vs. attributes.
(not trying to start a holy war here, trying to make a contextual point)
My use of attributes is only as needed to "scope" one or more elements with
a variant theme. Whereas element laden folks might write something like
Or the attribute laden result (to save space on the wire, presumably):
<address street = "714 my Street" city="my City" state="my State"
zipcode="00666" country="us" />
Which is a rigid (and USA is the only address type - how arrogant)
structure. Probably one of those IT folks who wrote the schema while their
business analyst was getting requirements.
But the flexibility of XML is that it can be heterogenous. . . and how to
understand when you will get what structure is the purpose of attributes. .
. so the more context sensitive XML modeler (who understands the
requirements first) might use:
for US address, and the the following for UK addresses:
I am not aware of a way to use Schema to enforce a substructure based on a
value in an attribute, but from the short look at CAM that I have done, this
seems to be exactly what it was designed to do. . . combine snippets of
variants together into a complete document that is very context aware.
David, did I get that right?
XMS - a self constructing transactional XML management system.
No DBA required! Download it for free today: