Comments on WG11 N197 (EXPRESS Ed2 Annex G)

Mon Nov 4 21:53:18 EST 2002

Hi,
as mentioned in my mail yesterday, it would be nice (and is probably realistic 
in a joint effort) if we could get a document out for a 4-weeks WG11 review by 
end December.

Else, it seems that you two are in agreement now (except for liking things 
more or less and thinking of the old days)?!?

Did you have a look at the Japanese comments?
One concerns name clashes - that seems now resolved using the _dot_ approach.
Another one concerns tracebility of the schemas that were used to create the 
longform. I think it would be a good idea to add all schema names and their 
version ids into a remark block of the longform.

Best wishes, Jochen.

>===== Original Message From "Wilson, Peter R" <peter.r.wilson at boeing.com> 
=====
>> ----------
>> From: 	Wilson, Peter R[SMTP:PETER.R.WILSON at BOEING.COM]
>> Sent: 	Monday, November 04, 2002 6:51:09 PM
>> To: 	'Phil.Spiby at Eurostep.com'; Wilson, Peter R; sc4sec at tc184-sc4.org; 
'wg11'
>> Cc: 	Wilson, Peter R
>> Subject: 	RE: Comments on WG11 N197 (EXPRESS Ed2 Annex G)
>> Auto forwarded by a Rule
>>
>All,
>
>    This is in response to Phil's remarks. I have deleted the majority of
>old stuff from this thread.
>
>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: Phil Spiby [mailto:Phil.Spiby at Eurostep.com]
>> Sent: Saturday, November 02, 2002 1:47 AM
>> To: 'Wilson, Peter R'; sc4sec at tc184-sc4.org; 'wg11'
>> Subject: RE: Comments on WG11 N197 (EXPRESS Ed2 Annex G)
>>
>>
>> Hi Peter,
>>
>> My responses are embedded in the text.
>>
>> Phil
>>
>> > -----Original Message-----
>> > From: Wilson, Peter R [mailto:peter.r.wilson at boeing.com]
>> > Sent: 2002 November 01 21:07
>> > To: 'Phil.Spiby at Eurostep.com'; Wilson, Peter R;
>> sc4sec at tc184-sc4.org;
>> > 'wg11'
>> > Cc: Wilson, Peter R
>> > Subject: RE: Comments on WG11 N197 (EXPRESS Ed2 Annex G)
>> >
>> > Phil,
>> >
>> >     Thanks for the comments on my comments on Annex G issues. I have
>> > further
>> > commented below.
>> >
>> >     How is Edition 2 as a whole coming along?
>>
>> I don't know! I tried to contact Jochen a couple of times but
>> apparently
>> he was on holiday then going straight to the ISO meeting. The
>> last time
>> I had information he said that he was confident of having a
>> rough draft
>> available at the meeting.
>
>    And when will the final draft be available for the four week review by
>WG11 to ensure that everything is OK?
>
>> Your original argument was that going from short form to long form
>> discards semantics, including the semantics of instantiability. This
>> position now seams to have changed to forcing the discarding of this
>> information!
>> I am confused!
>
>    My position hasn't changed. EXPRESS provides for instantiabilty
>constraints via REFERENCE in a multi-schema model. A decision, for whatever
>reason, to convert a multi-schema model (short form) to a single schema
>model (long form) has the consequence that REFERENCE dissappears and hence
>REFERENCE semantics are discarded. The EXPRESS committee has no job in
>attempting to rescue others from the consequences of their decisions.
>
>>
>> My understanding of the rationale for the E2Short->E1Long was
>> that there
>> are NO implementation methods for E2Short. The implementation
>> methods at
>> present only deal with E1Long, due to historical issues not
>> worth going
>> into here! E2Short->E1Long is the only means by which implementations
>> can be created at present capturing as much of the original
>> semantics as
>> possible. So, to my view we should preserve as much of the E2short
>> semantics as possible.
>>
>> In a separate e-mail Alan Williams pointed out that the rule
>> I proposed
>> doesn't work since it would allow circular relationships between
>> implicitly interfaced entities. We need a better rule which
>> ensures that
>> all dependent entities have no independent existence, such as:
>>
>> RULE dependent_x FOR (x);
>> WHERE
>>    SIZEOF(QUERY(i <* x | SIZEOF(ROLESOF(i)) = 0)) = 0;
>> END_RULE;
>>
>
>    When I implemented an E2 short to E1 long processor I used approximately
>the following process:
>1) Create a schema S1 that contains items defined in the original short
>schema plus items that are USEd by the original short schema.
>2) Create a schema S2 that contains the items REFERENCEd
>by the original short schema, and in S1 create a single REFERENCE FROM S2
>specifying all the original REFERENCEd items.
>3) Recursively go through the items in S2 adding the items necessary to
>resolve all references (i.e., appropriate explicitly or implicitly imported
>items).
>
>    At this point, S1 contains the first class items (independently
>instantiable) and S2 contains all the second class items (those that are not
>independently instantiable).
>
>4) Delete the REFERENCE FROM S2 from S1, add all the items in S2 to S1, and
>delete S2. If RULEs about instantiablity are insisted on, then this is the
>appropriate point to add them to S1 (and offhand I guess that there would be
>a RULE for each ENTITY that was in S2).
>
>    I consider global RULEs to be constructs of last resort, and every
>effort should be made to avoid their use.
>
>> >
>> > > Another thing which we have not considered until now is the name
>> space
>> > > issues associated with producing a long-form. I know that we
>> > > should not
>> > > have a problem within STEP, since WG4 stated that all names should
>> be
>> > > unique across the whole of STEP, but in the general case we cannot
>> > > assume this. Therefore I would propose that we have a simple name
>> > > mangling process (much easier than the short name
>> generator!) which
>> > > causes every implicitly interfaced item to have a new
>> name, I would
>> > > suggest that we use a trailing underscore character to
>> indicate that
>> > > this is an implicitly interfaced name. This would apply to
>> > > all entities,
>> > > types, constants, functions, procedures and rules that were
>> implicitly
>> > > interfaced.
>> >
>> >     I would argue that the EXPRESS namespaces are well defined and,
>> among
>> > other things, EXPRESS provides for multi-schema models so that there
>> can
>> > be
>> > multiple namespaces over and above those within ENTITY,
>> FUNCTION, etc.
>> >
>> >     I see no reason to cater for those who choose to munge schemas
>> > together;
>>
>> THIS IS EXACTLY what WG11 has been told to do by providing this annex!
>>
>
>    Old timers on the EXPRESS committee have painful memories of their best
>judgements being overruled, resulting in problems that could so easily have
>been avoided.
>
>> > they should be aware of the consequences of doing so and
>> the problems
>> that
>> > that may cause *them*. Why should the EXPRESS Committee
>> assist them in
>> bad
>> > modeling?
>> >
>> >     That said, EXPRESS provides a means of referring to the name of
>> > something in another schema via the schema.name constructs
>> (i.e., the
>> dot
>> > notation).
>>
>> This was in the 1992 CD version of EXPRESS, but was removed at the
>> syntactical level before the IS was published. The only
>> remnant of this
>> is in the values returned by the typeof function.
>>
>> > *If* it is decided that the EXPRESS committee is going to aid
>> > and
>> > abet those who have not thought through the implications of
>> converting
>> a
>> > multi-schema model to a single schema model, then the new name for
>> ENTITY
>> > ent originally in SCHEMA sch should be sch_dot_ent. However, the
>> renaming
>> > must be limited to resolving actual name clashes --- forget about
>> trying
>> > to
>> > assign any (implicit interface) meaning to any renaming, it
>> should be
>> > invoked *only* to resolve name clashes (you can get name
>> clashes with
>> > explicit imports just as well as with implicit implicit imports).
>> >
>>
>> I agree that we probably should only deal with the clashes and not do
>> this to all implicit objects. Your suggestion of Schema_dot_name is
>> appropriate since it records where the clashing names came from which
>> will probably be of use.
>>
>>
>> Let's hope the people in Seoul read this discussion and act
>> accordingly.
>>
>> Phil
>>
>>