SEDS on EXPRESS: USE FROM on

[Wilson, Peter R]

    I agree with Ed Barkmeyer on this one. I just want to add one piece of information to Ed's excellent discusion.

    The stated reason (not necessarily documented) for why USE was restricted to APs and REFERENCE to IRs was so that you could tell by looking solely at the EXPRESS code whether it was an AP model (no REFERENCE) or an IR model (no USE). It didn't seem to matter that the EXPRESS models would be defined within either an IR or AP document. (Or was it all the other way round?)

Peter W.

Dr Peter R. Wilson
Boeing Commercial Airplanes
PO Box 3707, MS 2R-97, Seattle, WA 98124-2207
Tel: (206) 544-0589, Fax: (206) 544-5889
Email: peter.r.wilson at boeing.com
--------------------------------
Any opinions expressed above are personal;
they shall not be construed as representative of any organisation.
--------------------------------
 

> -----Original Message-----
> From: Ed Barkmeyer [mailto:edbark at nist.gov] 
> Sent: Tuesday, March 02, 2004 8:26 AM
> To: Lothar Klein
> Cc: seds at tc184-sc4.org; Rob Bodington; 'SC4 WG11'; pfAeroFW, ISOWG12
> Subject: Re: SEDS on EXPRESS: USE FROM on
> 
> 
> 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."
> 
>