Re: [Joey Coyle <joey@xcoyle.com>] restriction

> This is not logical.  There are many circumstances when you want an 
elemental
> data slot filled in a parent type instance, and then don't even want the
> element in a derived child.

Perhaps, but in our type system that would be an extension not a 
restriction.  Reason?  The derived type admits instances that the base 
type would not.  In that sense, it is an extension to the value space of 
the original type.  It so happens that we currently provide no means of 
declaring such an extension.  If everyone feels that it is worth the added 
complexity, then I don't think very much in our type system would break as 
a result.  On the other hand, it would add to the complexity for 
applications as well, as they would have to deal with a broader range of 
extensions in cases where extensions were allowed.  Indeed, one can 
imagine further complexity in trying to provide specific identification 
for the two sorts of extension.  Given the pressure that we are under to 
eliminate rather than add to our complexity, I'm not sure that such 
changes are the best 80/20 choice right now, but they are otherwise 
consistent with our design I think.

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------







ht@cogsci.ed.ac.uk (Henry S. Thompson)
Sent by: www-xml-schema-comments-request@w3.org
05/26/00 05:14 AM

 
        To:     www-xml-schema-comments@w3.org
        cc:     (bcc: Noah Mendelsohn/CAM/Lotus)
        Subject:        Re: [Joey Coyle <joey@xcoyle.com>] restriction

ht@cogsci.ed.ac.uk (Henry S. Thompson) writes:

> From: Joey Coyle <joey@xcoyle.com>
> Subject: restriction
> To: ht@cogsci.ed.ac.uk
> Cc: dbeech@us.oracle.com
> Date: Thu, 25 May 2000 15:31:09 -0400
> 
> There are many in the ASN.1 world that want to move to XML Schema, and 
if I am
> reading correctly, it seems you have said no to many.
> 
> 
> When modeling by restriction, which is quite common, you have jumbled 
the
> meaning of minOccurs.  It means both that instances must contain data 
for that
> element, and secondly that derived types by restriction must include 
that
> element.
> 
> 
> This is not logical.  There are many circumstances when you want an 
elemental
> data slot filled in a parent type instance, and then don't even want the
> element in a derived child.

I'm not aware of any OO or related type system in which derived types
(== subclasses) may eliminate methods/properties of base
types/superclasses.  The XML Schema type definition derivation design
is based on the requirement that processes which consume members
of the base type will work with members of the derived types, which
means required properties cannot be lost.

> 
> ##################################################
> 
> The next issue I would like to address is about the level of
> restriction.  Can you explain this:
> 
> 
> A complex type with an empty specification for {final} can be used as a 
{base
> type definition} for other types derived by either of extension or
> restriction; the explicit values extension, and restriction prevent 
further
> derivations by extension and restriction respectively. If all values are
> specified, then the complex type is said to be [Definition:]  final: no
> further derivations are possible.
> 
> 
> Does it mean that a type which is derived by restriction and is 
instantiable,
> can not be used as a base type for further restriction?

I'm sorry I don't see the connection between the above two
paragraphs.  By 'instantiable' do you mean not "abstract='true'"?
A type definition validly derived by restriction can be used as the
base for further derivation by restriction unless it is
"final='restriction ...'".

ht

-- 
  Henry S. Thompson, HCRC Language Technology Group, University of 
Edinburgh
          W3C Fellow 1999--2001, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
                     Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
                                      URL: http://www.ltg.ed.ac.uk/~ht/

Received on Friday, 26 May 2000 12:17:21 UTC