Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: Default and Fixed Values of attributes

From: "Hans Teijgeler" <hans.teijgeler@--------.-->
To: <noah_mendelsohn@--.---.--->, "'Michael Kay'" <mike@--------.--->
Date: 2/14/2005 6:57:00 PM
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@w... [mailto:xmlschema-dev-request@w...]
On Behalf Of noah_mendelsohn@u...
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
--------------------------------------





From Neeraj.Bajaj@S... Tue Feb 15 11:20:10 2005
Received: from wiggum.w3.org ([128.30.52.23])
	by frink.w3.org with esmtp (Exim 4


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent