SEDS on EXPRESS: USE FROM on

[Lothar Klein]

(moved this to wg11 exploder only)

Hi again,

Thanks for the feedback.
The topic got discussed again during yesterdays WG12 plenary meeting
and the WG12 minutes will say that examples are to be prepared to
explain the problems in more depth (Phil Spiby).

No one did really argue against USE FROM and REFERENCE FROM. There is no
wish to go for a new IMPORT statement.

Ray Goult mentioned that a few STEP parts already today use selective
USE FROM and REFERENCE FROM statements from the same schema to comply
with EXPRESS.

The SEDS I wrote does also not fully cover the problem.
Another part of the problem is that REFERENCE FROM cannot be chained.
This leads to problems that "compatible" changes in low level schemas
are not only reflected in medium but also in top level schemas.

Let us please wait for the examples and then continue the discussion.

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

Tuesday, March 2, 2004, 5:26:12 PM, you wrote:
> 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?)