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


Ah, that's the other side of the question.  Sure, here's a value in the set
of instances of the derived type -- a manager:

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

Here's that same manager used where an Employee is expected:

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

Both these instances documents are valid.  Your question was:

> Can you provide at least
> one example of a value in D that is also in B?

The value (described by the tuple: <id>2</id>
<numberOfReports>15</numberOfReports>) is in D (Manager) and is also in B
(Employee).

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


Maybe we have different definitions of "subset". Can you provide at least
one example of a value in D that is also in B?

> -----Original Message-----
> From: Burcham, Bill [mailto:Bill_Burcham@stercomm.com]
> Sent: Thursday, May 02, 2002 4:16 PM
> To: 'Matthew Gertner'
> Cc: 'ubl-cmsc@lists.oasis-open.org'
> 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