W3C home > Mailing lists > Public > xmlschema-dev@w3.org > January 2002

Re: Extension of the lexical space

From: <noah_mendelsohn@us.ibm.com>
Date: Wed, 16 Jan 2002 18:54:51 -0500
To: Walter.Waterfeld@softwareag.com
Cc: "'xmlschema-dev@w3.org'" <xmlschema-dev@w3.org>
Message-ID: <OFA7A162E1.36B55281-ON85256B44.00000E56@lotus.com>
Dr. Walter Waterfeld asks:

>> is it possible to extend the lexical space of 
>> simple datatype, without changing its value space?

As Jeni has responded the answer is no.  If we allowed you to do this, how 
would we make sure that processors around the world understood your 
extensions?  Schemas is, to a significant degree, designed to foster a 
high level of interoperability across organizations that may not have had 
prior contact with each other (e.g. to promote business to business 
electronic commerce.)  Extensions of the sort you propose seem unlikely to 
be understood without software upgrades.  In general, we have avoided 
features with that characteristic.

BTW: for similar reasons, we have avoided the very great temptation to 
allow extensible validation rules.  I'm sure mathemeticians would find a 
"prime number" type to be very useful, but we don't allow you to include 
in the schema the logic to ensure "primeness" in an interoperable way. You 
can easily establish a standard name for such types, and build specialized 
processors to do the additional validation if you like.  Given that you 
want extensions rather than restrictions (primes are a restriction of 
integers), that would be harder to do in an interoperable way, unless you 
arbitrarily defined your new date type as an extension of string. 

I hope this explains some of the reasons for the current design.  Thank 

Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
Received on Wednesday, 16 January 2002 19:07:57 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:55:54 UTC