- 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