- From: Costello, Roger L. <costello@mitre.org>
- Date: Tue, 4 Jan 2011 05:25:43 -0500
- To: "xmlschema-dev@w3.org" <xmlschema-dev@w3.org>
Hi Michael and Liam,
I greatly appreciate your comments.
It appears we may have a fundamental disagreement on the utility of "defining constraints on data." Let me attempt to articulate the two positions.
Here is my position on defining constraints on data:
Research and understand the operational constraints
on the data and then create a simpleType that constrains
the data to exactly those operational constraints, no
more and no less.
Thus, I determined that for my particular system, family
name values must consist of these characters:
- a-z and A-Z
- space
- period
- apostrophe
- dash
And I determined that for my particular system, family
name values are between 1 and 100 characters. These are
my operational constraints and I created a simpleType
that exactly expresses these constraints, no more and
no less. If my operational constraints change (e.g.,
I get users with family names longer than 100 characters)
then I will update my simpleType.
This is the simpleType that precisely meets my operational
constraints:
<simpleType name="English-language-family-name">
<restriction base="string">
<minLength value="1" />
<maxLength value="100" />
<pattern value="[a-zA-Z' \.-]+" />
</restriction>
</simpleType>
Here is what I "think" is your position (sorry, I don't mean to put words in your mouth; this may not be your position):
Operational constraints are constantly changing, so
any simpleType you create to express operational
constraints will be out-of-date almost as soon as
you've finished creating the simpleType. So, don't
constrain the data.
Instead of the above simpleType, use this:
<simpleType name="English-language-family-name">
<restriction base="string" />
</simpleType>
Essentially, this creates a synonym for the unconstrained
string data type.
Is this an accurate statement of your position?
/Roger
Received on Tuesday, 4 January 2011 10:31:20 UTC