- 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>
Dear Noah, Thanks! It's clear now (although still a nuisance, but you can't have it al). Regards, Hans -----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, 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:57:43 UTC