[wg11] One more SEDS for ISO 10303-11:2004

[Ed Barkmeyer]

This is the last recommended change.  It is about bringing the entity 
data type concepts together and defining the domain of an entity data 
type, which Part 11 currently does not do in clause 8 or 9.

Note:  With the exception of seds11-12-9r1, all of the recently 
submitted SEDS are editorial -- their purpose is clarification and 
consistency.  They should involve no change whatsoever to 
implementations.  We may argue whether my clarifications are Phil's 
preferred clarifications.

SEDS 11-12-9r1 (previous message) is a technical specification for the 
interpretation of aggregate initializers in places other then the right 
operand of an assignment.  Heretofore there was no technical 
specification for this, and the interpretation of any schema containing 
such a usage was never defined by Part 11.  I believe that the proposed 
text more or less matches the common interpretation, as I understood 
from the discussion in Valencia, but this is certainly debatable.

-Ed

-- 
Edward J. Barkmeyer                        Email: edbark at nist.gov
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8264                Tel: +1 301-975-3528
Gaithersburg, MD 20899-8264                FAX: +1 301-975-4694

-------------- next part --------------
Section 1.  GENERAL INFORMATION (completed by SC4 Secretariat/WG Convener):

SEDS Report Number: (seds11-8-3-1)
Date Submitted:
Status:
Assigned WG:
SEDS Team Leader: 
SEDS Team Members: 


Section 2.  ENHANCEMENT AND DISCREPANCY INFORMATION (completed by Author of SEDS Report):

Author: Ed Barkmeyer, NIST
Email Address: edbark at nist.gov
Part and Clause where Issue Originates: Part 11, Clause 8.3.1 and 3.3
Other Parts Affected by the Issue: none
Related Issues:
Summary/Abstract/Keywords:
 domain of entity data type is not specified

Problem Description:

Except for clause 8.3, all of the other subclauses of clause 8 define the domains of the data types defined in those subclauses.  Clause 8.3.2 (Defined data types) refers to clause 9.1 for the declaration, and clause 9.1 also defines the domain, which depends completely on the declaration.  But 8.3.1 (Entity data types) refers to clause 9.2, and clause 9.2 does not define the domain of entity data types.

Moreover, the domain of an entity data type involves several related but distinguished ideas.  Those ideas are currently found only by judicious examination of the definitions in clause 3.3: 3.3.1, .2, .3, .6, .7, .8, .9, .11, .12, .13.  They should be brought together in subclause 8.3.1.

Some of these definitions need to be corrected in order to bring them together.  In particular,

3.3.1 (complex entity data type) The definition violates ISO vocabulary directives.  The main definition is identical to the definition of entity data type, but only some complex entity data types are entity data types.  

3.3.2 (complex entity data type instance) The term "complex entity instance" is what is used.  The definition violates the vocabulary directives by not identifying its supercategory.  It should begin "an entity instance that ..."

3.3.6 (entity) The abstraction is not a "unit of information"; the abstraction is a "thing of interest" (as Annex B says).  It is the entity data type that describes "units of information".

3.3.11 (multi-leaf) The definition is based on the subtype/supertype graph concept, which is problematic for an instance.  And the concept isn't necessary:  A "single-leaf" complex entity data type has a corresponding entity data type that is a subtype of all the others in the combination; a "multi-leaf" complex entity data type doesn't.

Conditions Under Which the Issue Was Discovered:
  Discussion of the "single entity value" (a related SEDS) in WG11.

Proposed Solution (Optional):

a.  In 3.3.1 (complex entity data type) replace the definition with:
"a combination of entity data types within a particular subtype/supertype graph that satisfies all constraints imposed by the schema"

b.  In 3.3.2 (complex entity instance) strike "(data type)" and replace the definition with:
"an entity instance that is a valid member of more than one entity (class)"

c.  In definition 3.3.6 (entity), replace "class of information" with "classifier for things of interest"

d.  In definition 3.3.9, delete "(single)" and replace "a unit of information" with "the properties of a thing of interest" 

e.  In definition 3.3.11, remove the parentheses, and replace the definition with:
"a complex entity data type that has no equivalent declared entity data type:  In the combination, there is no one entity data type that is a subtype of all the others."

f.  In definition 3.3.12, strike "(data type)" and "data type"

g.  In definition 3.3.13, strike "(data type)" and replace the definition with:
"a complex entity value that is a member of the domain established by a multi-leaf complex entity data type"

h.  Before the only normative paragraph of 8.3.1 insert:

"An entity is a conceptual classifier for things of interest that is defined by a set of common properties.  An entity instance is a thing of interest, seen as a member of an entity (class).  An entity instance is described by a collection of information units, called attributes, that represent the values of those properties in that instance.  An entity value is a representation of that collection of information units.  In addition to having a representation as an entity value, an entity instance is considered to have an "instance name" -- a unique identification that distinguishes that instance among the things of interest.  It is possible that two or more entity instances are represented by the same entity value, but they can be distinguished by instance name.

NOTE 1 The instance name is not actually modeled in EXPRESS, but it is presumed to exist in any implementation.  If some set of modeled attributes of an entity instance uniquely identifies it, that can be declared in a uniqueness rule in the entity declaration (see 9.2).  

An entity data type is a specification of the common attributes and constraints that describe an entity.  The domain of an entity data type is a collection of entity values, each of which represents an entity instance that is a member of that entity (class)."

i.  After the normative text of 8.3.1, add:

"An entity instance can be a member of more than one entity (class), by having all the properties of two or more entity classes.  An entity instance that is a member of more than one entity (class) is said to be a "complex entity instance", and its representation is said to be a "complex entity value".  A complex entity value contains representations of the values of all the attributes of all the entities of which the complex entity instance is a member.  A complex entity data type represents a specific combination of entities that can have common (complex) entity instances.  The domain of a complex entity data type is the collection of all the corresponding complex entity values.

Some complex entity instances have a single "leaf" entity data type -- one entity data type that is a subtype (see 9.2.3) of all the other entity data types of which it is a member, and therefore inherits all of their attributes and constraints.  The complex entity data type for those complex entity instances is equivalent to that leaf entity data type.  

Some complex entity instances do not have this property -- there is no one entity data type that is a subtype of all the other entity data types of which it is a member.  The corresponding complex entity data type has no equivalent "leaf" entity data type.  Such complex entity instances are said to be "multi-leaf complex entity instances, and the corresponding complex entity data types are said to be "multi-leaf complex entity data types.  Multi-leaf complex entity data types are implicitly declared by combinations of entity declarations and constraints (see 9.2.3 and 9.2.5).  They do not have EXPRESS identifiers and cannot be explicitly referenced.

EXAMPLES - see 9.2.3."


Section 3.  RESPONSE INFORMATION (completed by SEDS Resolution Team Leader):


If Accepted, Resolution:


Section 4.  FOLLOW-UP INFORMATION (completed by WG Convener):

Class:
Priority:
Impact of Change: 
Further Action Required:
Action Required by SEDS Coordinator/WG Conveners/QC/SC4: