- From: David Beech <David.Beech@oracle.com>
- Date: Tue, 02 Jan 2001 10:58:56 -0800
- To: Yoshiaki SHIBATA <yshibata@sslab.sony.co.jp>
- CC: Jane Hunter <jane@dstc.edu.au>, www-xml-schema-comments@w3.org, mpeg7-ddl@darmstadt.gmd.de
Yoshiaki SHIBATA wrote: > > Dear Jane, all: > > Thank you very much for providing a list of queries on XML Schema > where most of our queries are taken into account. > Could you also please add the following question if you don't mind? > > ----------- > - When we just want to "rename" the existing type, which construct > <extension>, <restriction> is to be used? > > Example: > > <complexType name="Mpeg7Type"> > <complexContent> > <restriction base="anyType"/> > </complexContent> > </complexType> > > <complexType name="DType"> > <complexContent> > <restriction base="mpeg7:Mpeg7Type"/> <!-- <== can we use > "restriction" > just because its semantics i.e., DType is a special case of > Mpeg7Type? --> > </complexContent> > </complexType> > ------------- > > Actually an advice was given for this question in the reflector. But I also > would > like to hear from the original designer in W3C. First, a disclaimer - there's no single designer of the refinement features of XML Schema, and I'm just offering a personal suggestion. A criterion might be to be guided by the MPEG7 semantics of the derived type, and by possible mappings to other type systems, e.g. to classes in Java or C++ with their associated methods providing much of the semantics. If the derived type inherits the semantics of its base type, it is probably clearest to make this a degenerate case of extension, since refinement by extension fits naturally with semantic inheritance and substitutability in those other type systems. On the other hand, if the derived type is inheriting the state for convenience, and allowing substitutability in the XML instance, but is not intended to inherit all the associated method semantics of the base type, it might be advisable to use a degenerate case of restriction. Restriction, in general, does not correspond well to subclassing in languages like Java and C++, except when all the methods are read-only. As soon as there are methods that change the state of the object, they are liable to break the constraints imposed by the restriction. So choosing restriction is a warning signal that there may also be other restrictions on the inherited semantics. David
Received on Tuesday, 2 January 2001 14:02:38 UTC