EXPRESS language version identifier

[Ed Barkmeyer]

All,

With respect to Kikuchi-san's contribution:

> I reported some
> comments from Japanese delegation in previous Myrtle Beach meeting as
> following.
> 
> - DAM based EXPRESS model should have a version identifier. If version
> identifier is omitted, the version should be interpreted as version 3
> (TC2 level).

It is my recollection that this was the agreement in Myrtle Beach, in
the presence of all the NB delegates, and in response to the ballot
comments.

> - The version identifier should have 1 to 4.

I don't remember this.  The DAM itself only identifies version(4), and
there is no text, and no proposed text of which I am aware, that 
explicitly identifies version(3) or any other.  The proposed comment
resolution was that a <syntax> that has *no* language-version-id is to be 
taken as version(3), i.e. Part 11:1994 with TC1 and TC2.  That is, a
<syntax> that *conforms* to version(3) also conforms to Part 11:2002.

A <syntax> that has a language-version-id with version(3) does *not* 
conform to version(3) of Part 11 -- language-version-id is not a valid
version(3) construct.  So there is no reason to support this case.
I was not aware that the comments from Japan (or any other NB) asked
for this capability, and I do not recall discussing this case in
Myrtle Beach.

> - Conformance class should be used for version 4 based but with no new
> feature model.

This also is what I understood to be the agreement.  That is, that the
DAM would explicitly identify a conformance class for version(3) schemas
(and version(3) interpretations of schemas), so that Part 11:2002 
(version 4) could completely supersede Part 11:1994 (version 3).  
It is my impression that the absence of a language-version-id indicates
that the <syntax> conforms to the version(3) conformance class, and
there was a US ballot comment that proposed just such text.

> In my memory, above three comments are agreed. I hope version id will
> be remained and these agreements will carry out.

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.

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

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!

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