OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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


Sure.  (forgive me) base: Employee, specialization: Manager.  Employee has
an employee identifier (id).  A Manager is also an Employee, but in addition
to an identifier, a manager has a number of direct reports
(numberOfReports).

Here is the schema (with elements declared of each type as well):

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
elementFormDefault="qualified" attributeFormDefault="unqualified">
	<xs:complexType name="Employee">
		<xs:all>
			<xs:element name="id" type="xs:decimal"/>
		</xs:all>
	</xs:complexType>
	<xs:complexType name="Manager">
		<xs:complexContent>
			<xs:extension base="Employee">
				<xs:all>
					<xs:element name="numberOfReports"
type="xs:decimal"/>
				</xs:all>
			</xs:extension>
		</xs:complexContent>
	</xs:complexType>
	<xs:element name="Employee" type="Employee"/>
	<xs:element name="Manager" type="Manager"/>
</xs:schema>

Matt's question was:

>  Can you can provide an example of values valid in the base type but not
in the >  extended type?

Here's a value valid in the base type (Employee element is of type
Employee):

<?xml version="1.0" encoding="UTF-8"?>
<Employee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:noNamespaceSchemaLocation="emp.xsd">
	<id>1</id>
</Employee>

Here's that same value (same content), but given as the content for an
element who's type is Manager (Manager element is of type Manager).  This
instance fails validation:

<?xml version="1.0" encoding="UTF-8"?>
<Manager xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:noNamespaceSchemaLocation="emp.xsd">
	<id>1</id>
</Manager>

Take any example of derivation of complex types in XSD and they'll work the
same.  If you take the "set of all possible content for the base type" as B
and the "set of all possible content for any derived type" as D then D will
always be a subset of B.

-----Original Message-----
From: Matthew Gertner [mailto:matthew.gertner@schemantix.com]
Sent: Thursday, May 02, 2002 4:01 AM
To: 'Burcham, Bill'; 'Eduardo Gutentag'
Cc: 'ubl-cmsc@lists.oasis-open.org'
Subject: RE: [ubl-cmsc] restriction and extension are both subclassing


I agree that extension of a base type can be described as specialization. I
heartily disagree that the resulting type has a value set that is a subset
of that of the base type. Can you can provide an example of values valid in
the base type but not in the extended type?

Matt
-----Original Message-----
From: Burcham, Bill [mailto:Bill_Burcham@stercomm.com]
Sent: Thursday, May 02, 2002 1:49 AM
To: 'Eduardo Gutentag'
Cc: 'ubl-cmsc@lists.oasis-open.org'
Subject: RE: [ubl-cmsc] restriction and extension are both subclassing


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