W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > July to September 2007

[Bug 3251] need for precisionDecimal

From: <bugzilla@wiggum.w3.org>
Date: Fri, 28 Sep 2007 20:04:23 +0000
CC:
To: www-xml-schema-comments@w3.org
Message-Id: <E1IbM4V-0003VT-BJ@wiggum.w3.org>

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:07 UTC