Comments on WG11 N197 (EXPRESS Ed2 Annex G)

Wilson, Peter R peter.r.wilson at boeing.com
Tue Oct 1 20:19:18 EDT 2002


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



More information about the wg11 mailing list