Part 28 support for Express v2

[David Price]

All,

I thought the reason for writing the normative short-to-long in E2 was so
that P28, etc. didn't have to change at all. For example, what's the use of
extensible enums/selects in an XML representation of a long form schema?

Cheers,
David

-----Original Message-----
From: owner-wg11 at steptools.com [mailto:owner-wg11 at steptools.com] On Behalf
Of Ed Barkmeyer
Sent: 15 September 2003 22:58
To: STEP Part 28; SC4 WG11
Subject: Part 28 support for Express v2


All,

Since Heidi and Josh have both asked about Part 28 v2 support for EXPRESS
v2, I 
thought I would contribute my (limited) analysis.

I believe that Part 28 v2 can be easily modified to support EXPRESS v2,
because 
very little text needs to be changed.

It is important to say (as Part 28 does, I think) that one can only map the 
"context schema for the exchange data set" (aka "the long form") into XML 
Schema.  You can map a module schema to XML schema if that module completely

describes some data sets you want to exchange.  But you can't map a "module 
schema" to XML and then "import" that XML Schema where the EXPRESS exchange 
schema USEs the module schema.  That doesn't work even for EXPRESS v1,
unless 
you make certain rules about EXPRESS features you can't use (e.g. you have
to be 
able to use XML schema inheritance - one supertype, ONEOF subtypes).

Express Ed 2 has only a few features of interest:

  - extensible ENUMERATIONs
are only "extensible" in reference schemas and module schemas.  In the
exchange 
schema that is the context schema for an exchange, they are whatever they
have 
been extended to be and no more.  So we should choose our wording carefully
with 
respect to the set of enumeration items that become facets of the XML data
type, 
but otherwise we don't need to change anything.

  - extensible SELECTs
Similarly.  An exchange schema can extend extensible SELECTs and it can
prune 
choices from any interfaced SELECT type.  But the result is a closed 
select-list.  All we have to do is choose the wording carefully.

  - renaming of attributes
We need to look at this one, but only for the case of inheritance with 
redeclared attributes (6.6.3).  In any case, we only have to mention that
the 
redeclaration can include a new name.  In XML schema, it will look like a
new 
content element/attribute and the deletion of the inherited one -- the
EXPRESS 
relationship between them will be lost.  But that happens if you rename an 
attribute by configuration directive as well.

  - SUBTYPE CONSTRAINTs
These are global rules and are not, in general, mapped to XML schema.  It is

possible to declare an entity ABSTRACT in a SUBTYPE_CONSTRAINT, but we only
say 
"if the entity is declared ABSTRACT", we don't say where.  We should do that
in 
a Note, and mention both ABSTRACT SUPERTYPE and ABSTRACT (ENTITY).

  - TOTAL_OVER and the reworking of the supertype constraint text This only
affects (global) rules and does not affect the mapping to XML schema.

  - ABSTRACT entities
What we say about mapping entities that are declared ABSTRACT is still
correct. 
  But EXPRESSv2 ABSTRACT entities can have attributes whose data types are 
"generalized" (like GENERIC_OBJECT or AGGREGATE OF T).  Since such
attributes 
*must be redeclared* in the instantiable subtypes, it is not actually
necessary 
to map them to XML schema at all.  In all valid EXPRESS schemas, the subtype

mapping will "add" the refined attribute to the XML schema data type,
thinking 
it is "redeclaring" it.  That is my preferred solution.

This approach does require us to distinguish things that are syntactically 
'generalized_aggregation_types' but also satisfy 'aggregation_type' from
those 
that don't satisfy 'aggregation_type'.  E.g.
  ENTITY gizmo ABSTRACT;
    coordinates: ARRAY[1:4] OF REAL;
    associates:  ARRAY[1:4] OF GENERIC_OBJECT;
  END_ENTITY;
'coordinates' and 'associates' both have 'generalized_aggregation_types';
but 
only 'coordinates' also satisfies 'aggregation_type'.  If XML inheritance is
not 
used for gizmo, gizmo is not mapped at all.  If XML inheritance is used, 
attribute 'coordinates' need not be redeclared and must be directly mapped
to 
XML schema; attribute 'associates' must be redeclared and need not be mapped

directly to XML schema.  (It occurs to me that EXPRESS v2 itself is not
clear on 
this point, but will almost certainly say that when clarified.)

I don't know of any other EXPRESS v2 feature we need to address.

-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-4694

"The opinions expressed above do not reflect consensus of NIST, and have not
been reviewed by any Government authority."