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

[Ed Barkmeyer]

All,

Following Phil's email, I made a number of changes to the EXPRESS 
metamodel.  I attach a drawing of a new addition to the diagram set.
I hope this is what Phil meant and what Part 11 was trying to say.
Although it isn't what I thought, it makes sense to me (now).

A SingleEntityValue represents a collection of values for the explicit 
attributes contained in a single EXPRESS entity declaration, and the 
SingleEntityType represents the "data type" of that collection, i.e. the 
data type of the output of the "implicit" partial entity constructor and 
the group (\) operator for that entity data type.

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.

"Without loss of generality", a PartialEntityValue (-Type) consisting of 
exactly one SingleEntityValue (-Type) is "equivalent to" that 
SingleEntityValue (-Type).  That is why the diagram shows 
SingleEntityValue (-Type) as a subtype of PartialEntityValue (-Type).

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.  Those 
are called EntityValues in the diagram.  They correspond to a true 
EntityType, and not just to the SingleEntityType derived from it.

An EntityValue also represents the state of a "conceptual" 
EntityInstance at some point in time (e.g. the time of the exchange). 
It may be the state of more than one distinct EntityInstance, which is 
why Part 11 says EntityInstances are "named" EntityValues.  (Hmm. The 
diagram should have an id:InstanceName attribute on EntityInstance.  I 
had a battle with the Poseidon tool about this, and I guess I lost.)

An EntityInstance/EntityValue can be "characterized" by a single leaf 
node in the subtype/supertype graph, if all the attributes of that 
instance are either declared for or inherited by the named entity data 
type at that node.  Those are the instances that can use "internal 
mapping" in Part 21, and that is what is meant by a SingleLeafInstance. 
   An instance that is an ANDOR of two or more leaf entity types, so 
that no one entity data type declares/inherits all of its attributes is 
a MultileafInstance.  Those are the instances that require "external 
mapping" in Part 21.  (The term Multi-leaf Instance appears in Part 11, 
clause 3.3 and is never used; the term Single-leaf Instance doesn't.)

If everyone agrees that this was the intended model, we can make the 
necessary fixes to the Part 11 definitions (and one or two other places) 
to make this clear.

Phil says that he personally believes the values of an entity data type 
are EntityValues, not EntityInstances.  The text of Part 11 is a bit 
confused on this point.  I find it more useful to insist that the 
instances of an EntityType are EntityInstances, each of which has a name 
and a corresponding "state", which is an EntityValue.  One can always 
extract the Value from the Instance when needed.  The other way around 
doesn't work:  An EntityValue can correspond to (be the state of) zero 
or more EntityInstances, and in general you have no way to know which 
one is intended.

Some applications don't want certain EntityValues to be distinguished by 
"names", e.g. for my tool, all values of Cartesian_point at the same 
coordinates are the same point.  But you can always write rules and 
programs that compare entities by value if you started with "instances", 
and you can thereby ignore the "names".  But you cannot do anything 
meaningful about distinguishing "Instances" if Part 11 insists that 
EXPRESS only describes the Values.

The point of the SEDS and the attached diagram is that one can make the 
text of Part 11 clear on these points, using a somewhat complicated but 
clearly structured (meta)model.  The result can clearly define all the 
existing operators and functions, and it should break no existing 
schemas that were clear as to their intent.  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.

-Ed

P.S.  The discussion thus far has shown that two of the would-be SEDS 
should be somewhat (ranging to significantly) modified before they 
become official.  I will do that in the near future.

P.P.S.  I would have drawn the attached diagrams in EXPRESS-G, but I 
don't have an EXPRESS-G tool that still works, and one annoying modeling 
tool per week is about all I can take. ;-)

-- 
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: EntityValues.jpg
Type: image/jpeg
Size: 43286 bytes
Desc: not available
Url : http://lists.steptools.com/pipermail/wg11/attachments/20050527/3ec4a4c1/EntityValues.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EntityValues.wmf
Type: video/x-ms-wm
Size: 43720 bytes
Desc: not available
Url : http://lists.steptools.com/pipermail/wg11/attachments/20050527/3ec4a4c1/EntityValues.bin