(Haenisch) SEDS reports for ISO 10303-11

[Ed Barkmeyer]

Jochen,

1.  I agree with Phil: we should discuss these SEDS in Myrtle Beach.

2.  Solutions to the TYPEOF problem.  It has always (since 1989) been my position that TYPEOF, ROLESOF and USEDIN are terrible
constructs, because they turn meta-data into string data.  I think that the solution proposed in Edition 3 is in the right
direction -- to have a data type whose values are "types" (not "type names"), and any type-reference that is valid in the schema
*denotes* the corresponding value of the "types" data type.  And a similar approach can be used for "Roles" (attribute names). 
(Note also that a Role is very much like a type, so much so that STEP commonly uses SELECT data types to model "roles".)

3.  IS, ISKINDOF.  Part of this is solved by the TypeOf solution in Edition 3.  The other part is the "leaf type" issue.

3a.  Frankly, I don't think the Annex B (and Part 21) concept "leaf type" is of much interest in a model.  It is only a
consideration for representations (which is why it is a concern in C++ and Java and Part 21 and Part 28).  The concept that is
interesting in a model is "is an instance of", and that function is true for all types of which a given instance is a member. 
It is important in some application models to *model* the narrowest classification of an object, but that assumes some
particular set of classification rules.  And if you impose additional classification rules on your Express model, then (and only
then) does this concept mean something.  If, for example, you impose a tree-structure rule on your models, then it is possible
to require TYPEOF to return a deterministic sequence of values, from the leaf to the root, with the rule "X precedes Y if and
only if X is a subtype of Y", but this special case is only meaningful with that additional classification rule.

3b.  Implementation concerns.  This issue of "classification rules" is common to implementation languages.  Like the UML v2
folk, we (WG11) should talk about explicit "implementation annotations" for Express models, since these would also be useful for
Part 23/27/29, Part 28, Express-X and other standard and non-standard "implementation methods" yet to come.  I have said before,
and I continue to aver, that the existing STEP models are SQL models written in Express, and they are therefore not easily
mapped into object-oriented or hierarchical data structures.  We need to have formal markup in the APs that will support such
mappings.

4.  USE and REFERENCE.  (Phil correctly identified the problem as 1989-1994 politics.)  There are two different problems here: 
"long forms" and "reference only".  Regrettably, USE and REFERENCE combine the "interfacing" ("import") concept with the
*orthogonal* "reference only" concept, which causes these problems to get mixed up.

4a. Reference-only.  REFERENCE should be a qualifier on an entity data type that says it can only be instantiated as an instance
of some Role related to an instance of a "primary" type.  This is also the INTERNAL notion that was deleted from Part 21 long
ago, the WEAK notion in IDEF1-X, and the "Dependency" notion in SDM and USM, and the "black/white diamond" notion in UML.  But
(as it is modeled in UML) it is correctly a property of the relationship, not of the participating class itself.  That is, it
should be possible to state that certain entity instances of type B are only meaningful when they have a given relationship to
some instance(s) of type A.  And that qualification defines a subtype of B.  The same model could have another subtype of B that
has a different "dependency", and still another subtype of B that is "independent".  Reference-only is a kind of RULE that is
misplaced in the interface declaration in Express v1.  REFERENCE-only should be like SUBTYPE CONSTRAINTS -- a kind of rule for a
set of *usages* of a type that can be attached to the type or to a subtype in an AP/Module.

4b. Long-form.  "Long form" is the result of expanding all interface declarations and resolving their interactions to produce
the schema that actually governs an exchange.  The more capability we add to Express in the line of separable constraints,
renaming, extensible types, and reducible select types, the more complex those interactions become and the less clear it becomes
just what declarations the "governing schema" actually contains.  So I strongly believe in the existence of an *informative*
long form, and a *normative* short-form.  (There is more politics here.  The long form was made normative in 1994, because the
implementors correctly judged that the IRMs and the AP derivation process were immature and bug-ridden and they wanted a
well-defined normative schema for the exchange.  That situation has changed. The short-forms in Modules are well-defined, while
the long form ARMs are unions of those definitions and the long form AIMs/MIMs are meaningless -- the same IRM types are reused
with different meanings.)

So I would prefer to see Express-n have an "interface" capability spelled "USE", a "reference-only subtype constraint", and a
deprecated vestigial declaration "REFERENCE FROM" that combines them.  The reference-only constraint will then have syntax that
appears in the "long form".  And that syntax would have to be "generated" when mapping a REFERENCE FROM into the long form.

-Ed

-- 
Edward J. Barkmeyer                       Email: edbark at nist.gov
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Mail Stop 8260          Tel: +1 301-975-3528
Gaithersburg, MD 20899-8260               FAX: +1 301-975-4482

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