Re: MPEG-7 Problem Issues and Queries

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


Received on Tuesday, 2 January 2001 14:02:38 UTC