Identification of Express Version

[Ed Barkmeyer]

Dave,

You wrote:
> If I can summarize your two points as follows:
> 
>    #1 -- the ASN.1 identifier will stay the same from draft
>       status to IS
> 
> Perhaps, but that is not the key issue.  

I understood that to be Pascal's issue.

> A TC will change the ASN.1
> identifier, even if there are no technical changes to the spec.  So
> the issue may not hit now, but it eventually will.

1.  A TC can only change the ASN.1 identifier if the TC contains a change 
to that part of the text of Part 11:2002.

2.  Changing the ASN.1 identifier that is required to appear in conforming
schemas *is* a technical change.

3.  Unless the TC contains nothing more than grammatical and typographical
repairs, the concept "technical change" is in the eye of the beholder.
The old IGES labelling scheme of Clarification, Correction and Change,
used in many STEP TCs, indicates that even a "Clarification" may be a
"change" for someone who misinterpreted the intent of the previous text.
So I think the idea of having a new version-id for the TC is probably
never a mistake.

>    #2 -- the ASN.1 identifier is needed to separate E1 from E2
>       schemas.
> 
> I completely agree that something is needed to separate the two, but
> is the ASN.1 identifer too fragile for this purpose?  THIS is the real
> question.  As shown above, the ASN.1 identifier may change because of
> editorial fixes that have nothing to do with new language features.

At the moment, the production rule for language-version-id specifies
"version(4)" verbatim.  And the proposed text of the standard is to say:

"When a schema contains any declaration not in the limited EXPRESS 
language designated conformance class xxx (see 5.n), the language version 
identifier shall be specified.

Note -- This provision allows <syntax> objects that conform to earlier 
versions of ISO 10303-11, and do not have language-version-ids, to conform 
to this international standard, and to be recognizable as conforming to 
the earlier versions, which are supported by conformance class xxx."

It's not what the version number is; it is whether the ASN.1 identifier
appears at all.  A <syntax> object that begins with an ASN.1 identifier 
that specifies a version other than 4 does not conform to the standard, 
although it will probably be accepted by many parsers.  

If and when we define version(5), the TC/Amendment that defines it will 
have to include some words about handling of versions earlier than 5.
Otherwise a version(4) file will be non-conforming.  But if version(5)
is upward compatible with version(4), it should be easy to write that
text.  And if it is not, then v(4) may become a new conformance class.

I don't think we have a problem now, and we have created the mechanism
by which we will in future know what we are looking at.  I don't see
that we need an additional mechanism -- it would just create a different
shape of identifier supported by text of the standard that would have to
change in each version.  That is, it would create exactly the same 
problem (if there is one).  If version(5) creates a compatibility problem, 
then it will also have the opportunity to fix it.  And I think we can
safely wait to cross that bridge until we come to it.

-Ed

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