W3C home > Mailing lists > Public > xmlschema-dev@w3.org > February 2005

RE: Default and Fixed Values of attributes

From: Hans Teijgeler <hans.teijgeler@quicknet.nl>
Date: Mon, 14 Feb 2005 17:57:23 +0100
To: <noah_mendelsohn@us.ibm.com>, "'Michael Kay'" <mike@saxonica.com>
Cc: "'Paap, Onno'" <onno.paap@ezzysurf.com>, "'XML-Schema Developers Forum'" <xmlschema-dev@w3.org>
Message-ID: <000901c512b6$4256f4b0$0300a8c0@hans>

Dear Noah,

Thanks! It's clear now (although still a nuisance, but you can't have it


-----Original Message-----
From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org]
On Behalf Of noah_mendelsohn@us.ibm.com
Sent: Monday, February 14, 2005 4:57 PM
To: Michael Kay
Cc: 'Hans Teijgeler'; 'Paap, Onno'; 'XML-Schema Developers Forum'
Subject: RE: Default and Fixed Values of attributes

Hans Teijgeler writes:

>> Can you explain the rationale for the
>> split between specialization
>> (typing)_by_extension and 
>> specialization_by_restriction? From 
>> a data modelling point of view that is 
>> illogical, because adding an attribute 
>> or child element also constitutes an extra 
>> constraint, and besides that it is highly 
>> inconvenient and causes a lot of hassle.
Michael Kay writes:

>> Others would be better qualified than me to comment on the rationale.

I can't speak officially for the schema WG, but I can give one member's 
opinion.  Both restriction and extension establish an "intensional" 
relationship between base and derived types. So, even if you don't add 
anything in an extension or remove anything in a restriction, you are 
saying "this type derives from that".  Mechanisms like xsi:type and 
substitution groups key on that.  However, in the case of restriction,
are making a guarantee that you are not giving with extension: every 
member of the derived type will be valid per the base.  This makes it 
possible to write software that knows only about the base types.
one common idiom is to write software that knows only about the schema 
built in or primitive types, and deals with the others by finding a
in or primitive ancestor.  You can do that for many purposes with 
restriction, and more rarely with extension.

Extension was included in part to allow for modeling the serializations
certain object-oriented data structures.  It only allows what boils down

to single inheritance, and with some limitations at that.   There are
other uses for it.

You are correct that there are times when it doesn't matter whether E 
extends R or R restricts E.  On the other hand, it's very often useful
distinguish intentionsionally:  t1 is a subtype of t2.  In that respect,

the two forms are very different. 

Note that in object oriented programming systems, you usually have
invocation mechanisms that launch methods.  These methods can use active

code to hide the differences between class data hidden in the base or 
derived types.  In data systems like XML, you have no such active code. 
The data is out there, and you can see it's order and the field names. 
This makes it more important to call out the special case where the 
derived will always be usable in place of the base.

Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
Received on Monday, 14 February 2005 16:57:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:15:27 UTC