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

[Lothar Klein]

Phil,

>From what you write I see that we have basically a common
understanding of these things. 

A few remarks:

- SDAI (p22) does not (yet) know about any kind of entity value. This
  is an extension of our JSDAI implementation only.
  But maybe a future version of SDAI should have these concepts, based
  on hopefully precise definitions in Express.

- The current definition of "3.3.15 partial complex entity value"
  says:
   "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."

  Note that it says "... must be combined with other partial ..."
  So by this definition it is distinct from a *complete* complex
  entity value.

- There is this special case "A(2)" which complicates things since we
  can have an instance out of this single one. We could get rid of
  this complication if we say that the single entity value "A(2)" is
  transformed into a complex entity value "(A(2))" and the instance is
  made out of this.

For the whole logic is may be useful to change the defined terms
slightly to have "complex entity value" as the general term and
"complete complex entity value" and "partial complex entity value"
as specialisations. Then we could say that the "||" operator produces
a "complex entity value" which may be either *complete* or *partial*.
An instance can be made only out of a "complete complex entity value"
but not out of a "partial complex entity value".
Whether a complex entity value is complete or partial is deduced out of
the subtype/supertype graph according to the algorithm in the annex.

Lothar

PS:
According to some ISO guidelines all definitions in clause 3 should be
given by a single sentence. No dot is allowed. stepmod enforces this.


-- 
// Lothar Klein, LKSoftWare GmbH
// Steinweg 1, 36093 Kuenzell, Germany
// +49 661 933933-0, Fax: -2
// mailto:lothar.klein at lksoft.com   http://www.lksoft.com

Wednesday, May 18, 2005, 11:22:04 AM, you wrote:
> Lothar & Ed,

> Interesting discussion!

> A part of the problem here comes from EXPRESS and SDAI using the same (or
> similar) terms to mean different things!
> 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
> 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)
> 3. A complex entity value is a valid partial complex entity value.

> 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

>   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

> 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)

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

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

> 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.

> 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.

> How are these issues addressed in the MOF for UML? I guess there are similar
> issues since UML has similar capabilities in this area (often overlooked by
> people assuming disjoint constraints between sub-classes). Perhaps we can
> use a similar terminology and concepts, this would help with the
> harmonization between EXPRESS and UML.

> Phil