Comments on WG11 N197 (EXPRESS Ed2 Annex G)

[Phil Spiby]

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.

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

If this is the case, then I would like to see a clear statement in the
standard that the two sub-processes have no meaning if not combined into
third process. This should prohibit further problems by the
implementation methods just revising the standards to cover the new
constructs without addressing the real issue of implementing the short
form view actually defined in the modules structure.

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

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

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

> 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

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