SEDS on EXPRESS: USE FROM on

trthurma at rockwellcollins.com trthurma at rockwellcollins.com
Tue Mar 2 11:56:21 EST 2004





>From the perspective of an "AP Developer"

A policy change is appropriate to allow a combination of USE FROM and
REFERENCE FROM since the combination of USE FROM and REFERENCE FROM is
unambiguous, and is current practice.

Policy needs to support actual practice as it evolves.  The practice of
REFERENCE FROM for APs has been in use beginning with the need to add the
CONSTANT dummy_gri.

Best Regards,
Tom

Thomas R. "Tom" Thurman
MS 106-183
Rockwell Collins Inc.
400 Collins Road N.E.
Cedar Rapids Ia, 52498, USA
phone:(319)295-2280
FAX:(319)295-0654
This email and any attachments are confidential to the intended recipient
and may also be privileged. If you are not the intended  recipient please
delete it from your system and notify the sender. You should not copy it or
use it for any purpose nor disclose or distribute its contents to any other
person.


                                                                                                                  
                      Ed Barkmeyer                                                                                
                      <edbark at nist.gov>        To:       Lothar Klein <lothar.klein at lksoft.com>                   
                                               cc:       seds at tc184-sc4.org, Rob Bodington                        
                      03/02/2004 10:26          <rob.bodington at eurostep.com>, "'SC4 WG11'" <wg11 at steptools.com>,  
                      AM                        "pfAeroFW, ISOWG12" <ISOWG12 at IMC7.EMS.LMCO.COM>                   
                      Please respond to        Subject:  Re: SEDS on EXPRESS: USE FROM on                         
                      edbark                                                                                      
                                                                                                                  
                                                                                                                  




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







More information about the wg11 mailing list