Comments on WG11 N197 (EXPRESS Ed2 Annex G)

[Phil Spiby]

Peter,

To give the people attending the EXPRESS 2 issue resolution session in
Seoul something to talk about I would like to address some of you
issues.

Short to long conversion:
Although I agreed that there are two separate processes and these could
be documented separately. I think this then leads to the issue you have
identified, that if you have two processes, then based on which order
you perform the processes, you get different results. Therefore I would
argue that we should define a single process of how to get from E2Short
to E1Long, this may be documented as two steps, but with a clear
statement that both steps must be performed and in the order specified
to achieve the required results, any deviation from this process would
fall outside the scope of the standard.

Instantiability in long forms:
I would argue that each entity which is interfaced either implicitly or
via a REFERENCE statement should result in a global rule which ensured
that it was used in some role possibly:
RULE independent_x FOR (x);
WHERE
  x = QUERY(i <* x | SIZEOF(ROLESOF(i)) > 0);
END_RULE;

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.

Phil

> -----Original Message-----
> From: Wilson, Peter R [mailto:peter.r.wilson at boeing.com] 
> Sent: 02 October 2002 01:19
> To: 'Phil.Spiby at Eurostep.com'; sc4sec at tc184-sc4.org; 'wg11'
> Cc: Wilson, Peter R
> Subject: RE: Comments on WG11 N197 (EXPRESS Ed2 Annex G)
> 
> 
> Phil,
> 
>     I am very pleased that someone has responded to my Annex 
> G review. I am also very surprised that I was the only one to 
> submit anything.
> 
>     I have interspersed my responses in your text.
> 
> Regards
> Peter W.
> 
> > -----Original Message-----
> > From: Phil Spiby [mailto:Phil.Spiby at Eurostep.com]
> > Sent: Tuesday, October 01, 2002 3:08 PM
> > To: Wilson, Peter R; sc4sec at tc184-sc4.org; 'wg11'
> > Subject: RE: Comments on WG11 N197 (EXPRESS Ed2 Annex G)
> > 
> > 
> > Peter,
> > 
> > I would like to respond to your paper on Annex G.
> > 
> > I think you position that this annex is "Fundamentally 
> flawed" is an 
> > overstatement of the current situation.
> 
>     I beg to differ on this one, but "Fundamentally flawed" 
> does not necessarily imply "redo it all".
> 
> > 
> > Taking your points individually:
> > 
> > The definitions for "long form", "short form" etc are 
> expected to be 
> > covered in a revised version of Part 1, this was recommended at the 
> > Stockholm meeting (Not sure if this message was passed on 
> since I was 
> > only there for one and a half days)
> 
>     Annex G is not standalone, and not everything was 
> supplied to enable a complete review. I have my own ideas on 
> what "short" and "long" mean but there was nothing that I 
> could check my assumptions against (it would have been useful 
> if the definitions had been given in a (temporary) note). You 
> will find that this is a running theme with me.
>  
> > 
> > I like your idea of a two stage process, this would enable 
> support for 
> > E2 longform implementations (if the rest of WG11 doesn't 
> sort itself 
> > out and deal with shortform correctly [it was argued that by 
> > specifically NOT supporting E2 longform we could impact the 
> > implementation methods and force them to adopt the short form!])
> >
> 
>      The two stage process is not just a good idea --- it is 
> essential. It's the mixing of the two processes that is the 
> fundamental flaw.  Annex G deals with two distinct ideas 
> Short to Long, and Ed 2 to Ed1. They cannot be intermingled 
> or mixed together.
> 
>  
> > E2 to E1 (longform) does not, I believe, impact the 
> semantics, it does 
> > however cause the creation of a number of global rules etc. 
> which some 
> > will find objectionable.
> 
>     I hope you mean E2 (long) to E1 (long). In that case I 
> think that I agree that the semantics can be maintained, but 
> if and only if the long forms are the end of the road. 
> 
>     As I said, both in emails in May and in my review 
> comments I ran some experiments on short Ed2 to long Ed1. For 
> the sake of argument just consider two Ed2 schemas, say Sa2 
> and Sb2. The two ends of the process spectrum are
> basically: 1) form Slong2 (Ed2 long form) from Sa2 and Sb2, 
> and then convert Slong2 to Slong1 (Ed1 long form); and 2) 
> convert Sa2 to Sa1 (Ed1) and convert Sb2 to Sb1 (Ed1) and 
> then form Slong1 from Sa1 and Sb1. The experiments showed 
> that Slong1 from process (1) was _not_ the same as Slong1 
> from process (2).
> 
> > 
> > Short to Long does impact the semantics, and has therefore 
> always been 
> > argued against by the EXPRESS committee, however, since the current 
> > implementation forms only deal with single schema models we have to 
> > accept that this is the case. A formal mapping may be created which 
> > ensures that the semantics are not perverted, however this would 
> > probably cause an explosion of global rules required to deal with 
> > independent insatiability etc.
> > 
> 
>     I think that the main semantic loss in short to long is 
> losing the USE and REFERENCE, and hence which are the first 
> class entities and which are second class. However  that 
> could be fairly easily dealt with by SC4 by making all the 
> second class enities the arguments to a global RULE (with no 
> body), perhaps called second_class, with the convention that 
> those are not to be independently instantiated (does any 
> implementor actually care about
> this issue?).   
> 
> > The multi-rooted schema versus single rooted schema was not 
> identified 
> > as being required! All the SC4 based (and as far as I know 
> non-SC4!) 
> > base their implementations of defining either a single 
> (long form) or 
> > single (short form) schema as the target for implementation. I have 
> > seen no implementations based on implementing an arbitrary 
> collection 
> > of connected schemas. Is this really a need that we have 
> overlooked? 
> > It certainly isn't needed within SC4.
> > 
> 
>     It may not necessarily be a need for SC4, but neither are 
> multi-schema implementations. The EXPRESS user base is much 
> broader than SC4, and I am convinced that the language must 
> not be hobbled by SC4's view of the world.
> 
>     Short-to-long is essentially concatenating several 
> schemas into a single one. I assume that following the 
> EXPRESS usual practice, the means by which the starting 
> schema(s) for this process is identified is out of scope. And 
> if it isn't (the Ed2 scope statement hasn't been sent out for 
> review yet) then it must be declared to be out of scope. It 
> shouldn't be too difficult to come up with wording to cover a 
> multi-schema starting point. Something like "The contents of 
> the identified starting schemas form the initial contents of 
> the long form schema." together with "Methods for identifying 
> the starting schemas are out of scope."
>     
> > The "empty box" mentioned in the annex is the [] symbol as
> > used in annex
> > C.
> 
>     I assumed that but it needs clarifying (Is "empty box" 
> used in Annex C? It hasn't been distributed for review yet so 
> nobody, except perhaps the document editor, knows.).
> 
>     I think that it would not be too onerous in either time 
> or thought to fix Annex G, either as two main subclauses or 
> as I would prefer, two annexes. One describes the short to 
> long algorithm, which seems to be mainly an elaboration on 
> the pruning annex. The other describes the Ed2 to Ed1 
> conversion. As far as I can tell, the words and ideas are 
> there, its (just) a question of teasing them apart properly. 
> The short to long is pretty much a mechanical process, like 
> the linker portion of a compiler system. Language conversion 
> has more to do with semantics and requires more intellectual 
> effort to get right.
> 
>     Hope this helps.
> 
> > 
> > Phil
> > 
> > > -----Original Message-----
> > > From: owner-wg11 at steptools.com
> > > [mailto:owner-wg11 at steptools.com] On Behalf Of Wilson, Peter R
> > > Sent: 19 September 2002 23:44
> > > To: 'sc4sec at tc184-sc4.org'; 'wg11'
> > > Cc: Wilson, Peter R
> > > Subject: Comments on WG11 N197 (EXPRESS Ed2 Annex G)
> > > 
> > > 
> > > 
> > >     Attached are my comments on the EXPRESS Edition 2 Annex G
> > > describing a short to long form algorithm.
> > > 
> > >     My summary statement is that Annex G is fundamentally
> > > flawed and must be rewritten.
> > > 
> > > 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.
> > > --------------------------------
> > >  
> > > 
> > > 
> > 
>