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, you 
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.  Indeed, 
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 built 
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 of 
certain object-oriented data structures.  It only allows what boils down 
to single inheritance, and with some limitations at that.   There are some 
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 to 
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 dynamic 
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
1-617-693-4036
--------------------------------------

Received on Monday, 14 February 2005 16:00:03 UTC