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

[Lothar Klein]

Ed,

It took me more time to answer - have to be in the right mute and
concentration to figure these things out. I re-arranged pieces of your
e-mail so that I could structure my answer better. Hope it got somehow
right - all this is already more than an e-mail - more a kind of
detailed paper.

Lets come to a decision whether we need a conceptual or an
implementation model (more on this below). Based on such a decision I
can then draw an improved data model.
----------

I think we have to add the Express-schema(s) to the whole discussion
to get a proper solution.

The question whether a combination of single entity data types/values
is complete or not can only be answered in the scope of an express
schema. The same combination may be complete in one schema, but for
another schema it is not. So I agree that it does not make sense to
have specific subtypes for complete or partial since this can only be
answered in relation to a particular schema.

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

Ok - this is a question of definition. So you say that a partial
entity value may consist of 0 single entity values. I don't have a
problem with this - in our implementation this may actually be the
case for an instance of the Java class ComplexEntityValue.
If it is useful on a conceptual level I don't know.

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

In our JSDAI implementation this is somehow similar. On the level of
the sdai_dictionary_schema we only keep a string for the expression of
a derived attribute or the complete contents of a rule, function or
procedure. The string is stored so that we are able to re-genere Java,
e.g. for an HTML documentation or Express XML as used in stepmod.
  But during compilation of Express schema(s) we also
generate Java code so that we can later execute all this.
During execution we use specific Java classes:
- Value for attribute values and aggregate members
- EntityValue for a single entity value (no sub/supertypes)
- ComplexEntityValue out of which we can make an instance (if complete)

Objects of these classes point into a population of the
sdai_dictionary_schema so that they always know about their actual
data type. 

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

Looking from schema perspective I would not argue that way, see above

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

... within a particular schema. Yes

> This is why in the revised diagram attached, I model 
> "complete complex entity value" as complete with respect to a 
> "reference_type" entity_type.

No - I don't think it is ok to introduce another object "entity_type"
when already having "single_entity_type" and "(partial) complex entity
type".
  Because you are using the term "reference_type" I guess that you
want to say that we have to separate between the definition of a
variable, parameter or entity-attribute and its type.

> ...
> But the point is that "complete" is only meaningful *in reference to* a
> target entity_type.

I can't follow you here.
"complete" can only be answered for a schema and this decides whether
we can make an instance out of it.
  The next question is whether this instance can be assigned to a
variable, parameter or entity-attribute. This is a different question
and clearly covered by Express already I think.

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

Yes, as I mentioned above the fact whether a complex entity type is
partial or complete must be turned into a relation to a schema.

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

Yes - get rid of those

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

It is ok that a single_entity_type corresponds to exactly one
complex_entity_type with the additional rule that the
complex_entity_type has only one component and this single component
is THIS single_entity_type.

The attribute equivalent_type on the value level does not make sense I
think - and this lead me to something else:

--- start: conceptual versus implementation level ---
In our Java implementation it is clear that we can have 2 instances of
Java class EntityValue or 2 instance of Java class ComplexEntityValue
with the same value. This is necessary to effectively work with this.
  But in a conceptual data model (not one for implementation) we may
say that an EntityValues and ComplexEntityValues must be unique in
respect to their contents. This is because there is not way to
distinguish between two Complex/Single entity values with the same
contents - they don't have an identity like the entity instance has.
  At the end we have to answer if we want to create a conceptual data
model which will exactly represent the nature of Express or one which
is suitable for implementation.
  Only when we speak on such a conceptual level a single_entity_value
has exactly one corresponding complex_entity_value. In a real
implementation we may have 0, 1 or more.
--- end ---

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

Ups - no!
The definition says that a data type is a "domain of values". Since we
have single_entity_values for a single_entity_type this is a data
type.

> The type of a SingleEntityValue is
> a "partial complex entity data type", as Part 11 says.

Let us find those places and change it

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

We have to change the text to say that the constructor and
group_operator (in the case that an entity type is used) results in a
single entity value. This single entity value is then implicitly
transformed into a complex entity value and further on into an entity
instance as needed by the other stuff around.

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

Yes and no - depends on whether we talk conceptually or on an
implementation basis. See above.

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

Again: conceptually I agree. Implementations are likely to work
differently.

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

We should try to minimise the number of changes.

Lothar

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