EXPRESS language version identifier

[Wilson, Peter R]

Ed and WG11,

    See my comments below

Peter W.

Dr Peter R. Wilson
Boeing Commercial Airplanes
PO Box 3707, MS 6H-AF, Seattle, WA 98124-2207
(Package Delivery: MS 6H-AF, 1601 E. Valley Frontage Road, Renton, WA 98055)
Tel: (425) 237-3506, Fax: (425) 237-3428
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: Ed Barkmeyer [mailto:edbark at nist.gov]
> Sent: Thursday, June 13, 2002 9:33 AM
> To: Yoshihito KIKUCHI
> Cc: wg11 at steptools.com
> Subject: Re: EXPRESS language version identifier
> 
> 
> All,
> 
> With respect to Kikuchi-san's contribution:
> 
> <snip>
>
> The problem that has arisen *since* the Myrtle Beach meeting is:
> What exactly is a <syntax>?  That is, to *what* does a 
> language-version-id apply?
> 
> Peter Wilson and I interpreted <syntax> as "any collection of schemas 
> that are parsed together" -- a file.  Phil Spiby interpreted it as 
> "that collection of schemas that completes the exchange schema for a 
> population by satisfying all the USE/REFERENCE references."
> 
> It is now clear that the DAM must specify which of these is 
> the intended
> meaning of the <syntax> object.  
> 
> If it is the latter (Spiby) interpretation, then the concept 
> "combination of schemas conforming to different versions of Express" 
> is purely academic -- any given exchange schema (the "context schema
> for the exchange" in the words of Part 28), including *all* 
> the schemas 
> the short-form exchange schema interfaces, is ONEOF(V3,V4).
> 
> If it is the former (Wilson) interpretation, then in effect the 
> language-version-id is propagated to exactly the collection of schemas
> in the <syntax>, so that each schema has its own language-version-id.
> And in that case, a mix of versions in an effective exchange schema,
> as Peter Wilson and Kikuchi-san indicate, is a real possibility.
> 
> If the Spiby interpretation of <syntax> is chosen, then, as 
> Pascal Huau 
> observed, the usefulness of the language-version-id is 
> extremely limited, 
> and it is not necessary to have it in the standard, and Phil 
> and I agreed 
> with this.
> 
    The view from my part of the world is that even if the usefulness of the
language-version-id is extremely limited, it is essential for long term STEP
data retention. 

    The Wilson/Spiby interpretation is a seperate issue.

> If the Wilson interpretation of <syntax> is chosen, however, the 
> language-version-id may be critical to the interpretation of 
> the exchange
> schema for a population, and I agree with Dr. Wilson and Kikuchi-san.
> But I think we must then also have an Annex that explains how 
> to do that
> interpretation, particularly for EXTENSIBLE types.  (Because 
> version(4)
> retains SUPERTYPE OF, the interactions of SUPERTYPE and 
> SUBTYPE_CONSTRAINT
> must be specified in all cases.)
> 
> I would also observe that, "before modules", *all* IRM 
> elements interfaced
> into an AIM exchange schema are always interpreted in the 
> context of the 
> AP/AIM, i.e. the context of the ARM mapping.  So the Spiby 
> interpretation 
> is consistent with the 1994 STEP architecture.  But "with 
> modules", it is
> to be expected that module schemas will always be interpreted in the 
> context of that module, no matter what exchange schema they 
> are interfaced
> into.  So the Wilson interpretation is consistent with the 2002 STEP
> architecture.  There will of course be no "version(3)" 
> modules, but it 
> may be very important to know which ones are "version(4)" modules when
> we have Express version(5)!
> 
> I think I am now coming to agree with Kikuchi-san that we 
> should retain
> the language-version-id construct.  The other requirements 
> above, however,
> that result from the "Wilson interpretation" would then apply:
> - we need to define the interpretation of <syntax> in the 
> standard, or 
> revise Part 1 to define it in relationship to modules; and
> - we need to explain the interpretation of "cross-version 
> interfacing".

    Having performed some Edition 2 to Edition 1 mappings I have come to the
conclusion that such a mapping only gives usable results in the case of
mapping an Edition 2 long form to an Edition 1 long form. In general,
mapping of seperate Edition 2 schemas to edition 1 schemas 
and then creating an Edition 1 long form from the resulting mapped schemas
does not produce the same model as creating an Edition 2 long form and then
mapping that to Edition 1.

    A multi-schema Edition 2 model can not be mapped to an equivalent
multi-schema Edition 1 model.

    I don't think that I am any longer particularly concerned as to whether
the Wilson or the Spiby interpretation is picked (i.e., one id for the lot
or one id per schema). However, no matter which, the DAM must explain
clearly the consequences of whichever is finally selected.
 
> 
> It will be obvious from the foregoing (and from my previous 
> vacillation
> on this issue) that I believe that both positions are valid.  
> It is the 
> still-ill-defined morass of "modules" that leads me to support 
> Kikuchi-san's position.  
> 
> -Ed
> 
> P.S. I believe that the vocal US delegation is now 2-1 in 
> favor of the 
> Japanese position, whereas we were 2-1 in favor of the French 
> position 
> a month ago. ;-)  To follow ANSI rules, however, I would have to say
> this issue has never been formally resolved in the U.S.TAG 
> and the U.S.
> has *no* position!
> 

    The PS still stands for me.

> -- 
> Edward J. Barkmeyer                       Email: edbark at nist.gov
> National Institute of Standards & Technology
> Manufacturing Systems Integration Division
> 100 Bureau Drive, Mail Stop 8260          Tel: +1 301-975-3528
> Gaithersburg, MD 20899-8260               FAX: +1 301-975-4482
> 
> "The opinions expressed above do not reflect consensus of NIST,
> and have not been reviewed by any Government authority."
>