- From: <bugzilla@wiggum.w3.org>
- Date: Fri, 28 Sep 2007 20:04:23 +0000
- To: www-xml-schema-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=3251 ------- Comment #4 from mike@saxonica.com 2007-09-28 20:04 ------- I think primeInteger is an unfortunate example: its value space is a subset of xs:integer so it clearly should not be primitive. A better example might be gHourMinute to allow times in the format HH:MM. I think that when users see a type in a vendor namespace they will know they are using an extension and they will not complain when they find that it isn't supported by other vendors. Equally, a third-party implementor of such extensions will not expect all schema processors to offer the same extensibility API. These facts don't mean that extensibility is bad: it is generally my experience that allowing vendor extension to a specification is uniformly good for vendors, for users, and for the health of the specification itself, since (a) it reduces pressure to standardize things that are needed only by a minority, and (b) it allows new features to prove themselves in the market before they are added to the standard. It can often lead to a virtuous circle in which one vendors' extensions if popular are copied by other vendors and then added to the standard at a later version. It's better to define extensibility points within a language, rather than encouraging people to define variants of the language that are non-conformant, in the way that you suggest. Once you start doing the latter, people start getting very creative in the "improvements" they make to the spec, leading quickly to a complete loss of interoperability (as witness the SQL experience).
Received on Friday, 28 September 2007 20:04:32 UTC