[wg11] SEDS for EXPRESS (10303-11:2004)

[Ed Barkmeyer]

Phil Spiby wrote:

> I will try to only use the EXPRESS terms here.
> 
> 1. A single entity value is a member of the domain defined by an entity data
> type

This is the definition in 3.3.9.  For the record:

The term "single entity value" does not appear anywhere in the text of 
Part 11:2004.  The sole occurrence is in the definition in 3.3.9.

The phrase "entity value" appears many times but only in the terms 
"partial complex entity value" and "entity value comparison".  It never 
appears as a term in its own right.

The term "single entity data type" sans "value", which I took to mean 
"exactly one entity data type", because it has no definition in 3.3, 
appears in the definition of a "simple entity instance" (3.3.19) and in 
Annex B.

> 2. A partial complex entity value is a collection of 1 or more single entity
> values from distinct entity data types (i.e. the same entity data type
> cannot occur more than once)

This statement does not appear anywhere in Part 11!

3.3.15 defines "partial complex entity value" as follows:
"a value of a partial complex entity data type. This has no meaning on 
its own and must be combined with other partial complex entity values 
and a name to form a complex entity instance."

3.3.14 defines partial complex entity data type as:
"a potential representation of an entity. A partial complex entity data 
type is a grouping of entity data types within a subtype/supertype graph 
which may form part or all of a complex entity data type."

Neither definition says anything about "single entity data types" or 
"single entity values".  It is not clear from the normative text what a 
value of a "grouping of entity data types" might be, although we are 
able to puzzle it out from the examples -- it is a group of collections 
of attributes that taken together may or may not be/represent a member 
of the domain of some entity data type.  But I would point out that in 
SC4 in the large, an "application object" is a "grouping of entity data 
types" that expresses a single application concept, and that is not at 
all what is meant here.

One point of the SEDS is that Phil's definition (2.) *does not appear in 
Part 11*, and it should.

The other point of the SEDS is that the definition of "single entity 
value", quoted in Phil's point (1.), is wrong!

3.3.9 defines "single entity value" as:
"a unit of data which represents a unit of information within the class 
defined by an entity data type. It is a member of the domain established 
by this entity data type."

Nowhere in Part 11 is it stated that a member of the domain established 
by an entity data type consists precisely of the attribute values 
explicitly declared in a single entity_declaration, as distinct from 
those of supertypes identified in that entity_declaration.

In fact, Part 11, clause 9.2.3, explicitly says that a member of the 
domain defined by an entity data type *includes* all the inherited 
attribute values:
"An entity declaration which completely defines all the significant 
properties of that entity declares a simple entity data type. An entity 
declaration which establishes inheritance relationships with supertypes 
declares a complex entity data type. A complex entity data type within 
an inheritance graph shares characteristics of its supertype(s)."

And 9.2.3.1 says:
"An instance of an entity data type that is a subtype is an instance of 
each of its supertypes."

Since the characteristics of its supertype(s) include all the inherited 
attributes, I conclude from 9.2.3 that the representation of an instance 
of a complex entity data type must include representations of all its 
inherited attributes.  It follows that a member of the domain defined by 
a complex entity data type, which is a representation of an instance of 
the entity class, must include values for the inherited attributes as 
well as the attributes proper to the declaration of the subtype.

Now 9.2.3, as quoted above, defines two kinds of entity declarations -- 
those that declare simple entity data types, and those that declare 
complex entity data types.  If follows that the domain defined by an 
entity data type must be one or the other.

It was apparently the intent of 3.3.9 to define the term "single entity 
data type" to mean that something that is neither of the above -- namely 
the collection of explicit attributes that appears in a single entity 
declaration.  And then a "single entity value" is a member of the domain 
of a "single entity data type" with that definition.  But the definition 
actually in 3.3.9 is largely wrong:
"a unit of data which represents a unit of information within the class 
defined by an entity data type. It is a member of the domain established 
by this entity data type."

I understand this to mean that an "entity value" is the set of 
(attribute) values that represents an individual in the entity (class) 
represented by the entity data type, which, from 9.2.3, must be either a 
simple entity data type or a complex entity data type.

When the entity data type is a simple entity data type, the "single 
entity data type" is (more or less) equivalent.  But when the entity 
data type is a complex entity data type, or the root supertype of one, 
the ideas are importantly different in kind, and we have to separate them.

The whole point of the SEDS is that NO TERM IS DEFINED IN PART 11 to 
refer to the collection of explicit attributes in one entity 
declaration, and the definition of "partial complex entity value" is 
ambiguous.

If the term "single entity value" was intended to have that meaning, it 
should be so defined.  And then it should be USED in the definition of 
"partial complex entity value".

And we have to stop pretending that a partial complex entity value 
consists of members of the domains of entity data types. It doesn't! It 
does consist of members of (other) domains "established by" entity data 
type declarations, namely the "single entity data types" that correspond 
to the entity data types.  In the case of a "simple entity data type", 
the representations are the same, but the concepts are different, and we 
have to make that distinction as well, which was the point of the 
proposed 12.13.

I don't deny that what Phil says is more or less what was intended, but 
it is not what the text of Part 11:2004 says!

What the SEDS is asking for is a change to the wording of Part 11, 
particularly in 3.3.9 and 3.3.15, to make the intent clear.

> So from your example just changing the definition of B to:
>   ENTITY B ABSTRACT SUPERTYPE SUBTYPE OF (A); b1: STRING; END_ENTITY;
> 
>   A(2)
>   B("Hello")
>   C(.FALSE.)
> Are the single entity values

Agree, but only with the proposed revised definition.  B("Hello") is a 
member of the domain of the (currently undefined term) "single entity 
data type" B; it is *not* a member of the domain of the "entity data 
type" B, as defined in 9.2.3.

>   A(2)
>   B("Hello")
>   C(.FALSE.)
>   (A(2)B("Hello"))
>   (C(.FALSE")A(2))
>   (B("Hello")C(.FALSE.))
>   (A(2)B("Hello")C(.FALSE"))
> Are the partial complex entity values

Agree.

> And
>   A(2)
>   (A(2)B("Hello")C(.FALSE"))
> Are the complex entity values (The SDAI view is that A(2) is not a complex
> entity value)

The term "complex entity value" does not appear in Part 11.  Per 9.2.3, 
A(2) is a representation of a "simple entity instance"; and
(A(2)B("Hello")C(.FALSE")) is a representation of a "complex entity 
instance".

Assuming that "complex entity value" is the (unnamed) value that 
corresponds to a complex entity instance, it seems to me that "the SDAI 
view" is supported by Part 11.

> I do not understand why Lothar claims partial complex entity value and
> complex entity value are exclusive, in fact the definition of partial complex
> entity data type states that it may form part or all of a complex entity
> data type. 

Agree.

> I do agree with Lothar on his assertions about single entity values

I don't disagree that (some of) this was the intent.  I think there is 
still confusion among "entity instance", "entity value" and "single 
entity value" as to which is the "domain" of an entity data type.

> Given this I believe we do need to have another go at tidying up the
> definitions and the meta-model is a very useful (probably necessary) way of
> clarifying our understanding before we actually start re-writing the
> definitions.

I certainly agree with the first half of this.  As you will see from 
Allison's forthcoming document, almost every element of the meta-model 
thus far is grounded in a Part 11 concept with a reference to the 
subclause that defines it.  So with respect to the second half of Phil's 
recommendation, we have a chicken-and-egg problem.  Mixing the 
meta-model project with the TCorr project makes it quasi-official and 
that may be good for participation, but it might also be bad for the 
TCorr and the Express-G toolsmiths.

> To add more confusion to this issue, I think we need to separate out entity
> values and entity instances. To my mind, and I guess this may be
> controversial, I think Entity data types only define the domains of entity
> values, not of entity instances! Subtype/supertype graphs define the domains
> of instances, where a graph can be just a single entity data type.

As I said above, I'm convinced that this is the real underlying problem, 
i.e. that there are three different ideas here, and only one of them can 
be the domain of the entity data type.  I always thought the domain of 
the entity data type was entity instances, but Part 11:2004 (actually 
TC2 did it, I think) makes it pretty clear that the "entity instances" 
are the "individuals in the entity *class* corresponding to the entity 
data type", and the domain of the entity data type is the value 
representations of those individuals.  So I can accept Phil's point.

> How are these issues addressed in the MOF for UML? 

In a word, badly.

> I guess there are similar
> issues since UML has similar capabilities in this area (often overlooked by
> people assuming disjoint constraints between sub-classes). 

In object land, there was for many years an apostolic mission to 
convince software engineers that there was no difference between 
conceptual object classes and implementation classes -- there was a 
"natural seamless mapping".  And UML v1 supported that nonsense.

UML v2 distinguishes between a "conceptual classifier" and an 
"implementation class" and talks about "individuals" (entity instances?) 
being represented by "objects" (entity values, more or less).

There is no UML concept that corresponds to "single entity value" or 
"partial entity value". The nearest related notion is hierarchical 
object constructors, which are functions that invoke other functions.

> Perhaps we can
> use a similar terminology and concepts, this would help with the
> harmonization between EXPRESS and UML.

Being very careful, we can maybe use some of the UML metamodel terms in 
3.3.  But we don't want to change the Part 11 terminology any more than 
we have to.  Just trying to correct/clarify statements about partial 
entity data types modifies 7 or 8 separate subclauses.  Any significant 
change to the terminology will result in massive editorial changes.

Thanks, Phil.  I think we more or less agree on what needs to be done.
(I'm not pushing any particular ideology here, I just want the concepts 
and terms to be clarified, so we can model them.)

-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

"The opinions expressed above do not reflect consensus of NIST,
  and have not been reviewed by any Government authority."