Thanks for your prompt reply.
One Committee Member feels that NMTOKEN is ambiguous and deprecated, an assertion I have been unable to verify. He cites it as a hygiene issue going forward.
We could include our own definition:
<xs:simpleType name="NMTOKEN" id="NMTOKEN">
<xs:restriction base="xs:token">
<xs:pattern value="\c+"/>
<xs:whiteSpace value="collapse"/>
</xs:restriction>
</xs:simpleType>
But this seems a pointless exercise unless it has, indeed, been deprecated. Usually I can figure out where these comments come from, but this one I have some trouble with….
tc
"There are seldom good technological solutions to behavioral problems."
-- Ed Crowley
Toby Considine
TC9, Inc. | | Chair, OASIS OBIX Technical Committee Chair, OASIS WS-Calendar Technical Committee |
What is the justification for making a change?
NMTOKEN is a bizarre data type, but if it works, and if things are going to seriously break if you change, then it’s hard to see why you would want to change it.
You might be able to avoid compatibility issues by deriving your new type from NMTOKEN. But that depends on what those issues are.
I am currently nearing the end of a refresh cycle of a standard Schema (XSD) that has long used NMTOKEN. Systems using the specification are widely deployed in the world, so backward compatibility is highly desirable.
At the last moment, one commenter has thrown up the notion that NMTOKEN should no longer use NMTOKEN, but add specific facets instead. The rest of the specification currently makes no use of facets anywhere else.
Should we make this change? The new version, like the old, is likely to last another 10 years.
“The single biggest problem in communication is the illusion that it has taken place.”
– George Bernard Shaw.
| | Chair, OASIS OBIX Technical Committee Chair, OASIS WS-Calendar Technical Committee |
