Identification of Express Version

[Ed Barkmeyer]

All,

Thanks to David and Pascal for clarifying the issue, which seems to be: IS it
useful to label a file with the version of Express it contains?  And if so, WHY?

In my view, all that the version label does is to allow the parser to know
whether it can process the schema file, and to say up-front what the problem is
-- a version mismatch.  The alternative is that it might work or it might not,
and the presence of strange error messages may mean you have a version mismatch,
or it may mean you have a corrupted file, or that your Express is really
non-conforming.  So the sole value of the version label is that it allows a
parser to produce a good diagnostic for a situation that we expect the Revision
of Part 11 to create.

If I understand Pascal correctly, he doesn't think this is of any value:
> Q1: Is it needed to indicate the version of the Express language in an 
> Express schema?
>  
> If I am the customer of an application, the answer to Q1 is no. 
> (If I am expert enough to know that there are several versions and TCs of
> Express) I want to know which version and TC of Express, the application 
> implements and the marking of Express schemas does not
> provide me any information about that.
>  
> If I am developer of an Express application, the answer is also no.
> Either my application implements the latest version of the language or it 
> does not. If it does not, then it will return an error when it encounters 
> an Express language construct (e.g. extensible select) that did not exist in 
> the version of the language that was considered at design of my application.

>From my point-of-view, this feature is low cost for low return.
It has a minor value, and it doesn't cost anybody much.

But Dave Loffredo seems to think it has a high cost:
> What if this ID was in place when TC 1 & 2 came out? ...
> in 2002, we would have schemas with version(1), version(2), and
> version(3).  

This is not quite right.  The version label goes on the <syntax> object, not the
schema!  If every Part of ISO 10303 that contains Express schemas were expected
to parse as an Express <syntax> object, then we would have *Parts* with version
(1) and probably Parts with version (2) or (3), depending on when they were
adopted and what features they used.  Each Part would contain a
language-version-id somewhere before the first schema-declaration.  And the
producers of the Part or the revision of the Part would ensure that the
<language-version-id> correctly indicates the Express features that are being
used in the current version of that Part.  That seems like a pretty low cost to
me.

> Seems like this makes life more confusing for the schema
> developers, without changing the status quo on parser compliance.

I don't see why this should be confusing for schema-developers -- they know what
features they are using, and they label their files accordingly.  They cannot
interface (USE) a schema that requires a *later* version than the one they
indicate, but if they are *developing* a new schema, it is difficult to
understand how that would happen.  

As Pascal says, as long as versions of Express are upward compatible with Part
11:1994, no schema is version(n)-specific.  A Part that is labeled version(n)
may have features of version(n) and should be compatible with any later version
of Express as well.  The Part will be correctly interpreted by every Express
parser that supports that version or a later one.  So a developer should be able
to use any previously adopted schema, because its version number can only be the
same or lower.

The problem arises only when we revise IRM schemas and other re-usable
resources.  If we modify an existing IR Part and add a schema that uses a new
Express feature, the Part will acquire a new <language-version-id>, even though
only the new schema requires the additional features. The problem is that an old
Express parser may no longer be able to process the Part file *at all* -- it
will have "errors" from the new features -- even though none of the older
schemas in it have changed!  And if we modify an existing schema in a way that
uses a new feature, it will affect existing interfaces FROM the modified
schema.  An old parser that ignored the Part file label will have trouble
parsing that schema and all the schemas that interface it.

So I think Dave has a point.  If you use a new Express feature in revising a
re-usable Part, you may well render it impossible for old parsers to parse old
schemas that re-use elements of the Part that were not themselves revised.  The
re-usable Part file, and everything in it, now requires the parser to support
the new version of Express.  (Long-forms rule! ;-)  

But that problem arises from *using the new feature*, not from labeling the file
to say you did.  I don't see how labeling the Part file makes the problem worse
for schema developers.  If we don't maintain upward compatibility, then of
course, schema developers will have a problem reusing *any* previous work.  But
versioning files does not imply a loss of upward compatibility.  So where is the
cost to schema developers?  What will they be confused about?

-Ed

P.S. One thing we IT folk could afford to learn from the manufacturing engineers
-- you don't modify reusable partsy you create new parts with new part-numbers. 
If you believe in versioning reusable components, you have to do a where-used
analysis every time, to ensure that the change doesn't break any usages, or that
you start the work item to rev the affected usage.

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