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: [ubl-cmsc] restriction and extension are both subclassing


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.

 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC