ubl-cmsc message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: RE: [ubl-cmsc] restriction and extension are both subclassing
- From: "Burcham, Bill" <Bill_Burcham@stercomm.com>
- To: 'Eduardo Gutentag' <eduardo.gutentag@sun.com>
- Date: Wed, 01 May 2002 18:48:38 -0500
Maybe these two references will help:
(From the category theory perspective) Start at
section 2.3 of this paper.
There are two examples in that section of specialization by adding attributes
(properties) to the subtypes -- and the explanation is from the set-theoretic
perspective.
(From Entity-Relationship Modeling perspective) Start at slide
56 in this presentation.
To your point about the value of this "pure theory analysis"
-- Matt G. presented an alternative Specialization Architecture in the CMSC
today -- the one described in his recent paper (Schema Adjunct Framework +
Schematron). As a motivator for the value of that architecture, Matt said
essentially "restriction and extension are two very different things and the way
XSD tries to treat them both as derivation is just wrong -- so we shouldn't use
XSD". Sorry I didn't include that context with my post, but as a rebuttal
argument I'd say it isn't just "pure theory analysis" -- I'd say instead that it
is rebuttal.
-----Original
Message-----
From: Eduardo Gutentag [mailto:eduardo.gutentag@sun.com]
Sent:
Wednesday, May 01, 2002 5:47 PM
To: Burcham, Bill
Cc:
'ubl-cmsc@lists.oasis-open.org'
Subject: Re: [ubl-cmsc] restriction and
extension are both subclassing
> "Burcham, Bill"
wrote:
>
> Since I couldn't get this thought out in the conference
call today, I thought I'd get in into the record this way:
>
> From
the set-theoretic standpoint, XSD restriction of a simple type and extension of
a complex type are the same -- they both define a subset of a base set. To use
type terminology, they are both kinds of specialization in the
generalization-specialization paradigm.
>
> A simple type is
single-valued -- think scalar. When we restrict a scalar type we take away
values from its domain. This means that the restricted type has fewer possible
values than the original (or base) type. We never add values to the domain. An
example of this kind of specialization is: base type Integer, specialized type
Whole Number. These are scalars and the set of Whole Numbers is a proper subset
of the set of Integers.
>
> A complex type is not single-valued.
Instead it is comprised of one or more (simple type or complex type). A complex
type can be specialized in two ways: 1) a constituent simple type can be
restricted or 2) a property of simple or complex type can be added. In both
cases, the new type has fewer possible (compound) values than the original type.
Note: that transitivity in the definition of complex type means that there is
kind of a third way to specialize a complex type: (3) a constituent complex type
can
> be specialized.
>
>
I totally fail to see how a
complex type that has been "specialized" by having
a property of either type
added has fewer possible values. I just don't see
it. No. Nope. What am I
missing?
(and I have to confess that, even if the assertion were true, I
fail to see
what is the value added of this kind of pure theory analysis -
undoubtedly
the result of a mind that wears glazed eyes at all times and
carries an extra
pair just in case...)
--
Eduardo
Gutentag
| e-mail:
eduardo.gutentag@Sun.COM
XML Technology
Center
| Phone: (510)
986-3651
Sun Microsystems
Inc.
|
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC