Comments on WG11 N197 (EXPRESS Ed2 Annex G)

[Wilson, Peter R]

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?

Regards
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: Phil Spiby [mailto:Phil.Spiby at Eurostep.com]
> Sent: Tuesday, October 29, 2002 2:16 AM
> To: 'Wilson, Peter R'; sc4sec at tc184-sc4.org; 'wg11'
> Subject: RE: Comments on WG11 N197 (EXPRESS Ed2 Annex G)
> 
> 
> 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.
>

    I'm in agreement with this and to expand a little...
o Process A is Ed2 short to Ed2 long
o Process B is Ed2 long to Ed1 long.
These are distinct processes.

o The Ed2 short to Ed1 long conversion process is process A followed by
process B.
This is a third distinct process which has two ordered subprocesses.
 
> 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;
> 

    I will argue that instantiability is captured in the individual schemas
(that is the purpose of REFERENCE and implicit interfacing). Going from a
multi-schema model to a single schema model deliberately discards that
distinction. There is no need for any global RULEs about instantiablity, and
in fact the creation of any such RULE should be prohibited.
 

> 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;
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). *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).

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