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

[Ed Barkmeyer]

Lothar Klein wrote:

> I do not agree with several details of your proposal.
> See attached an alternative Express-G diagram.
> I can ensure you that this concept is working.

In general, I can agree with your diagram.  See the attached revision.
I do not deny that your model can work, but some of the assumptions that 
make it work are hidden.  In my revision, I expose those assumptions, 
and I delete 3 concepts that are not necessary, I think, for the model 
to work.

The main problem I have with it is that a "complete complex entity 
value" is "complete" with respect to 1:? entity data types, but it may 
also be "partial" with respect to 0:? entity data types as well.  So it 
is clear that the relationship between "complete complex entity value" 
and "partial complex entity value" is ANDOR, and the same for the 
corresponding data types, apparently.  Also, a "partial complex entity 
value" in your diagram has no modeled properties (and indeed it has none 
that are distinct from "complex entity value").  So why do you model it?

Also, a "complete complex entity value" is only interesting when I want 
to assign it to an object whose type is an entity data type, and what is 
then important is that it must be complete with respect to that entity 
data type.  This is why in the revised diagram attached, I model 
"complete complex entity value" as complete with respect to a 
"reference_type" entity_type.

Actually, a "complete complex entity value" that is being assigned may 
be complete with respect to other entity data types as well, and what is 
really required is that it is complete with respect to some valid 
(possibly unnamed multileaf) subtype of that entity data type.  So my 
diagram is a bit misleading as well.

But the point is that "complete" is only meaningful *in reference to* a 
target entity_type.  A "complete complex entity type" does not have any 
meaning when separated from a target entity_type.  And a complete value 
represents a valid instance of all of the entity data types whose 
single-entity-values are contained in the complete complex entity value. 
  So it is not clear what purpose the "complete complex entity type" 
serves.

For these reasons, I don't see the need to have complete_ and partial_ 
complex_entity_types, or partial_complex_entity_values.

Your complete_complex_entity_value is my EntityValue, your 
complex_entity_type is my PartialEntityType, and your 
complex_entity_value is my PartialEntityValue.  Apart from the names, 
our models of these concepts are the same.

The other addition I made is to the relationship between 
single_entity_type and complex_entity_type (and the same for _value). 
This relates to the SingleEntityType SUBTYPE OF (PartialEntityType) 
issue you raise, and I discuss that below.

>>A PartialEntityValue, per Part 11 (after TC2), represents one or more
>>SingleEntityValues packaged together.  This represents the output of the
>>"entity instance constructor" (||) operator, as well as the operators
>>above.  This may not correspond to any actual entity data type, because
>>it is missing the values of some required supertype.  (Part 11 says 
>>this.)  A PartialEntityType is the data type of one of those collections.
> 
> You introduce the new term "PartialEntityValue" and before we had only
> "partial complex entity value". You would be semantically more precise
> to speak of "complex entity values" which may be either "complete" or
> "partial".

Sorry about that.  There are some minor differences in the spelling of 
the terminology of the meta-model.  PartialEntityType is "partial 
complex entity data type" in Part 11.  We omitted words that are not 
required for the distinction in terms, *solely in order to keep the 
width of the boxes down to 3-5cm*.  In writing the text of Part 11, 
these terms would expand to their Part 11 patterns (mutatis mutandis).

The point of EntityValue SUBTYPE OF (PartialEntityValue) is that 
EntityValue ("complete complex entity value") is in fact a subtype of 
"partial complex entity value".  The word "partial" in that Part 11 term 
means that the set of single entity values may or may not be complete, 
not that the set is necessarily "incomplete".

>>"Without loss of generality", a PartialEntityValue (-Type) consisting of
>>exactly one SingleEntityValue (-Type) is "equivalent to" that 
>>SingleEntityValue (-Type).
> 
> This is the bend in your data model and you better avoid it.
> If you say a partial or complete complex entity value is a SET of one
> or more single entity values you can avoid this glitch.

Ah.  We agree on this, I think.  One can achieve this by deleting the 
SUBTYPE indication.  It is not necessary to make SingleEntityType 
(-Value) a SUBTYPE of PartialEntityType (-Value).

Unfortunately, it also makes it unnecessary and inconvenient for 
SingleEntityType to be a data type!  The type of a SingleEntityValue is 
a "partial complex entity data type", as Part 11 says.  There are two 
operations that conceptually produce SingleEntityValues, but no 
operations are defined on SingleEntityValues.   Those operations are 
said to produce a partial complex entity value consisting of one 
SingleEntityValue.  The group operator, the attribute reference, the 
complex entity constructor are all defined to take operands that are 
PartialEntityValues (partial complex entity values), and the "implicit" 
EntityValue to EntityInstance conversion operator takes a partial 
complex entity value.  So if we construct a "single entity data type" 
that is not a subtype of "partial complex entity data type", it isn't 
the data type of anything!  And if we make SingleEntityValue an instance 
of "single entity data type", it isn't a valid operand of any operator!

I said "without loss of generality", because that is the common 
mathematician's expression for doing something logically consistent that 
requires massive circumlocution to do precisely.  The fact is that a 
SingleEntityValue, as a value of a SingleEntityType, is "equivalent" to 
the SET consisting of exactly that value, and that SET is properly the 
value of the partial complex entity type.  Originally I modelled that 
relationship in lieu of the SUBTYPE wire, that is,
SingleEntityValue is-equivalent-to exactly-one PartialEntityValue, and
PartialEntityValue is-equivalent-to at-most-one SingleEntityValue.
And the changes I made to your diagram add this relationship and match 
my original model.  (And of course, there is a WHERE rule that says that 
for the equivalent PartialEntityValue, there is only one component and 
it is the SingleEntityValue.)

The same model can be made for SingleEntityDataType.  But now we must 
explicitly say in Part 11, that the output of the partial entity 
constructor, or the group operator, is the partial entity value 
consisting of exactly the SingleEntityValue that corresponds to the 
named entity data type.  But then there are no Instances of a 
SingleEntityDataType -- they are only pieces of a partial complex entity 
value.

I think the model I drew is ugly, just as you say.  But I also think the 
revised model I attach requires us to make more text changes to Part 11, 
and violates the Law of Least Astonishment (one of Bernd Wenzel's 
favorite criteria).  So we get to decide which is the "lesser of two evils".

>>...
>>Now some PartialEntityValues contain all the attributes needed to 
>>represent an EntityInstance of a given EntityType, i.e. they have 
>>SingleEntityValues for an EntityType and all of its supertypes.
> 
> You better reserve the word "partial" for those which are really
> incomplete.

Part 11 doesn't.  And the whole issue of operators is why it doesn't -- 
only assignment makes the distinction.  When you assign the value to an 
object (constant, derived attribute, formal parameter, variable), the 
partial entity value must be a "complete" value of the entity data type 
that is the declared data type of that object.  In any other use, it is 
just a collection of single entity values.

To change the term, we have to replace 20+ occurrences in the normative 
text.  To clarify the definition and add a Note requires one change in 3.3.

In your diagram you use the term "complex entity value" with this 
meaning, and I don't really have a problem with that.  But ... Part 11 
uses the term "complex entity instance" and one would think then that a 
"complex entity value" should be the value that corresponds to a complex 
entity instance, but you call that a "complete complex entity value".

>>...
>>I would also be surprised
>>if this model breaks any existing EXPRESS or SDAI tools, although it may
>>bring to light some dubious practices on both the modeling side and the
>>tooling side.
> 
> The sdai_dictionary_schema has a simplified view of what is an
> "entity_definition" and partial complex entity types are not covered
> at all.
> There is the sdai_parameter_data_scheme which talks on values, but
> unfortunately it also does not talk on entity_values, only
> entity_instances.

I don't think this is a problem.  SDAI "constructors" do not have the 
form of EXPRESS group operators and complex entity constructors, and 
SDAI uses the "implicit partial entity constructor" only to construct 
simple entity instances and "root" instances in complex entity graphs. 
So SDAI doesn't need partial complex entity types and instances.

Partial complex entity instances are an artifact of the EXPRESS data 
manipulation language -- we need them only to talk about the outputs of 
certain operators.  Part 11 correctly says that in general they don't 
have meaning -- they are nothing more than collections of attribute 
values.

(David Price's model didn't have partial entity data types/instances at 
all, and he didn't need them, because he modeled Expression as an 
Express-language-string.  For rules applications, I need Expression, and 
so I need partial complex entity values.)

So except for distinguishing complete_ and partial_ complex_entity_value 
subtypes of complex_entity_value (and similarly for _type), I think you 
and I agree on the model.  We just use different terms.

-- 
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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Klein-rev1.png
Type: image/png
Size: 21435 bytes
Desc: not available
Url : http://lists.steptools.com/pipermail/wg11/attachments/20050531/55f47164/Klein-rev1.png