SEDS on EXPRESS: USE FROM on

[Ed Barkmeyer]

Lothar Klein wrote:

> Problem Description:
> With a USE FROM *all* only all the data types get interfaced, but not
> functions, procedures and constants. To get them in as well an
> additional REFERENCE FROM *all* would be needed. Since USE FROM on a
> data type takes precedence over a REFERENCE FROM this is not what
> schema developer like to do.

I don't understand this last sentence.
It is SC4 policy to require USE statements in APs and to disallow 
REFERENCE statements.  This SEDS identifies a problem, but the 
second sentence suggests that the solution is already provided 
for in Part 11.  So the solution to the stated problem appears to 
be to amend the policy rather than the standard.

But perhaps the last sentence is intended to convey another part 
of the problem that I don't understand.

> Conditions Under Which the Issue Was Discovered:
> Module development
> 
> Proposed Solution (Optional):
> After this sentence
> "If there are no named_types specified, all of the named data types
>  declared within or USEd by the foreign schema are treated as if
>  declared locally."
> add
> 
> "In addition all of the following EXPRESS items declared within or
> referenced by the foreign schema are made visible in the current
> schema:
>  - Constant;
>  - Function;
>  - Procedure."

It is very much the intent of clause 11 that REFERENCE is the 
primary link between schemas, and therefore that
   REFERENCE FROM S;
imports the entire definition space of S into the definition 
space of the current schema, making all the supporting elements 
in S -- TYPEs, FUNCTIONs, RULEs, CONSTANTs, etc. -- usable in the 
current schema.

   USE FROM S (ent);
on the other hand, adds a very specific notion -- that the entity 
"ent", defined in S, is a *primary* and *independent* object 
class in the current schema.  That property cannot *ever* apply 
to constants, functions, procedures, rules, or TYPEs.  They are, 
by their nature, *dependent* notions, in that they are only 
meaningful (and can only be used) in describing properties of 
entity data types.

It was very clearly the expectation of the 1994 EXPRESS standard 
that the structure of an exchange schema would be:

SCHEMA exchange-1;
   REFERENCE FROM <support-schema-1> (* all *);
   REFERENCE FROM <support-schema-2> (<support elements>);
   ...
   REFERENCE FROM <major-concept-schema>(<dependent elements>);
   USE FROM <major-concept-schema>(<primary entities>);
   USE FROM <major-concept-schema-2>(...);
   ...
END_SCHEMA;

I understand Lothar's complaint to say that that model of an 
exchange schema "is not what schema developer[s] like to [use]". 
  Why not?  It is the model that the EXPRESS language was 
designed to support.

Now the formerly unwritten SC4 "quality" directives did in fact 
*forbid* that model to be used, whether "schema developers" liked 
it or not.  That policy required APs to contain *only* USE 
statements, which makes no sense.  But that mistake is easier to 
reverse than changing the standard.

However, if we are going to change the standard to "what schema 
developers are used to using" (as in C++, Java, UML and XML 
schema), we should delete both USE and REFERENCE and substitute 
IMPORT, which has only the syntactic behavior of copying 
declarations verbatim from one schema to another.  It has *no* 
"interfacing" semantics (dependent, independent, explicit or 
implicit).  (We would want to keep the SELECT-type pruning 
rules.)  And selective IMPORT can, unlike EXPRESS "interfacing", 
result in importing declarations with undefined symbols.  But 
that is "what schema developers are used to", because that's what 
you get in Java and C++, and even less in UML and XML schema 
(which have no selective import).

-Ed

"Be careful what you wish for.  You may get it."
   -- traditional
   (is William W. Jacobs' "The Monkey's Paw" the original?)

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