Part 21 support for GENERIC data type

[Ed Barkmeyer]

There was a minor error in what I wrote: 
> SELECT(aggregates of GENERIC)

According to my reading of the Express DAm (with or without the assorted editorial corrections requested by U.S. comments), the
underlying type in a type-declaration cannot be a generic data type.  Therefore, no named data type can be a generic data type,
and therefore, a SELECT type cannot have a member which is a generic data type.  (It does not change the argument -- the
redeclared attribute can still have a complex type involving SELECTs over aggregates.)

BTW, the interesting feature of a solution is a *name* that will unambiguously imply a specific datatype (and use) for the
redeclared generic attribute.  As noted, my suggestion that we should use a subtype name has some potential ambiguities, but it
is as close as I can come.  I believe that the alternative to using some kind of "name as qualifier" might be "revolutionary",
as Martin suggested. (Of course, the handling of externally mapped instances inside a given tool might be forcibly
"revolutionized" by the Express feature, regardless of what the Part 21 solution is.  It is that kind of internal architecture
problem that has motivated many XML toolsmiths to recommend restricting use of XML schema to "appropriate subsets".)

Dave Loffredo wrote:

> As far as the specifics go, I'm sure we can devise some new encoding
> for P21 and the other 2x series.  But the real questions to ask are:
> 
>    1) Who will do the work to produce yet another edition?
>    2) Why will the vendors and users want to undergo another
>       iteration to a basic part of STEP?

I think I can answer (2):

The same set of folks who thought it was necessary to add these features to EXPRESS presumably want to create schemas that have
these features.  And presumably, those folk want to use those schemas to define data exchanges.  At the point at which they want
to do the exchange, they will discover the need for changes to Part 21 and/or Part 28.

Now as long as the envisaged change is upward compatible with Part 21:2001, no vendor or user will be affected until these
putative DAm-feature exchange schemas complete development and actually come into use for exchange.  And at that point, if not
before, some organizations will discover that they should have put resources into the modifications to Part 21.

It is possible that the folks who want to do these exchanges will only be interested in exchange via OSEB, and since that
not-yet-standard technology will probably support Express Ed2 (with whatever alterations may be required between now and
adoption of Part 28, if any), they may have no need for changes to Part 21.  But I don't think that is the case.

So as to (1):

It follows that the National Bodies, and their member firms, who thought it was important to have these Express DAm features
will put forward the resources to modify Part 21.  Won't they?  At least, let those customers stand up and be counted, and the
tool vendors will respond.  (I certainly have no problem with the idea that if they don't, Part 21 will not change, and the
generic attribute feature will be implicitly deprecated.  But NIST may not share this opinion.)

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