Ed2 short to Ed1 long conversion

[Ed Barkmeyer]

"Wilson, Peter R" wrote:
>     The White Paper algorithm that I am using for mapping Ed2 ENUMERATIONS
> to Ed1 is that any BASED_ON is extended to include all its "parents" items,
> and that any EXTENSIBLE is extended to include all the items in BASED-ONs of
> the EXTENSIBLE that are visible to it.

Yes.  That is the equivalent that corresponds to the specifications for 
the extensible and extended enumerations in the DAM.

> ******** A couple of schemas and Ed2 to Ed1 mappings
> 
> SCHEMA s1; -- Ed2
>   TYPE colour = EXTENSIBLE ENUMERATION OF (p); END_TYPE;
>   TYPE traffic_light = ENUMERATION BASED_ON colour WITH (r, y, g); END_TYPE;
> END_SCHEMA;
> 
> SCHEMA s1; Ed1 mapped from the Ed2 s1  [A - see below]
>   TYPE colour = ENUMERATION OF (p, r, y, g); END_TYPE;
>   TYPE traffic_light = ENUMERATION OF (p, r, y, g); END_TYPE;
> END_SCHEMA;

Correct.

> SCHEMA s2; -- Ed2
>   USE FROM s1 (colour);
>   TYPE rainbow = ENUMERATION BASED ON colour WITH (v, i, b, g, y, o, r);
>   END_TYPE:
> END_SCHEMA;
> 
> SCHEMA s2; -- Ed1 mapped from Ed2 s2 and Ed1 s1
> **** ERROR colour is not extensible
> END_SCHEMA s2;

Agreed.  In general, this cannot be done, because the Ed2 schema s2 
is using features of the type colour that did not exist in Ed1.

It must be a requirement that an Ed2 short-form schema uses the Ed2
versions of any schema it interfaces.  (If only an Ed1 version exists,
then it is the Ed2 version.)

> SCHEMA s2; -- Ed1 mapped from Ed2 s1 and Ed2 s2
>   USE FROM s1 (colour);
>   TYPE rainbow = ENUMERATION OF (v, i, b, g, y, o, r); END_TYPE;
> END_SCHEMA;

This may be what the cited paper implies, but I'm pretty sure this is
the wrong mapping.  The problem is that colour is extensible in s1,
and its value set is therefore implicitly extended in s2 when it is
extended in type rainbow.  So this mapping does not maintain the
semantics of the s2 schema.

It must be a requirement that an Ed1 short-form schema made from an
Ed2 short-form schema replaces the interface declarations for 
EXTENSIBLE types with type declarations for them.  In effect, this 
means that the Ed2 short-form must be converted to an Ed1 long-form,
if the interfaced schema uses Ed2 features.

> **** Short to long versions of SCHEMA s2
> 
> SCHEMA s2long; -- Ed2 long version of Ed2 s2 and s1
>   TYPE colour = EXTENSIBLE ENUMERATION OF (p);
>   TYPE rainbow = ENUMERATION BASED ON colour WITH (v, i, b, g, y, o, r);
> END_TYPE;
> END_SCHEMA;

Correct.

> SCHEMA s2long; -- Ed1 version converted from s2long Ed2 version [B - below]
>   TYPE colour = ENUMERATION OF (p, v, i, b, g, y, o, r); END_TYPE;
>   TYPE rainbow = ENUMERATION OF (p, v, i, b, g, y, o, r); END_TYPE;
> END_SCHEMA;

Correct.

> SCHEMA s2long; -- Ed1 long version of Ed1 s2 and s1
>   TYPE colour = ENUMERATION OF (p, r, y, g); END_TYPE;
>   TYPE rainbow = ENUMERATION OF (p, v, i, b, g, y, o, r); END_TYPE;
> END_SCHEMA;

This is the result of the above noted error in mapping the s2 
short-form to an Ed1 short-form.

>     Interesting, isn't it?

Yes.  What I remember from the discussion in ? (Spiby, Sanderson, Price,
Maier, Tor ?, Barkmeyer) was that the mapping would be defined *only*
for the exchange schema, and it would always result in a "long-form"
Ed1 schema!  That is, it is not permitted of *any* schema to interface
an Ed1 schema that is mapped from an Ed2 schema.

So:
a) The Ed2->Ed1 mapping for s1 [A] is correct if s1 is the exchange 
schema, and meaningless otherwise.

b) The first mapping of s2 (Ed2, interfacing from Ed2) to s2long (Ed1) 
[B] is correct if s2 is the exchange schema, and meaningless otherwise.

c) No other mapping of s2 to Ed1 is ever correct.

This may seem a bit draconian, but it follows from Pascal's observation that you
will use one Express toolkit to compile all the schemas for an exchange.  If the
toolkit supports Ed2 schemas, then it will work correctly.  If the toolkit does
not support Ed2 schemas, then you must convert the *syntax* (= the exchange
schema and all the schemas it interfaces) from Ed2 to an Ed1 "long-form" so that
the toolkit can process it.  Mapping schemas-to-be-interfaced from Ed2
to Ed1 piecewise does not maintain all the Ed2 semantics needed for the exchange
schemas.

Unfortunately for the Modules folk, this means that it makes no sense to convert
Ed2 modules
to Ed1, full stop.  Only the (AP) exchange schema made from a set of modules can
be correctly
mapped to Ed1!

-Ed

P.S. Thanks, Peter.  We need someone to stick pins in our balloons from
time to time!

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