EXPRESS Ed.2 SEDS

[Ed Barkmeyer]

Peter Wilson wrote:

 >  I think that there is a problem in that the "wordy meaning" of ONEOF
 > depends on the context. What about:
 >             ONEOF(a,b) AND ONEOF(c,d)
 > In this case your proposed wording change won't convey the right
 > impression (there must be one from (a,b) and one from (c,d),
 > whereas the rewording implies that there need not be any of a,b,c,d).

Are you saying that the meaning of ONEOF changes when you add another
(AND) constraint?  It doesn't.

The meaning of ONEOF(a,b) in

   SUBTYPE_CONSTRAINT FOR (xyz);
     ONEOF(a,b) AND ONEOF(c,d);
   END_SUBTYPE_CONSTRAINT;

is still:
  An instance of XYZ can consist of at most one of A and B.

The further meaning of the combined constraint is:
  If an instance of XYZ contains an A or a B, it must also contain
either a C or a D (and vice versa).

But it emphatically does *not* say:
  An instance of XYZ shall consist of exactly one of A and B.
It does not say that an instance shall contain *any* of A,B,C and D.
That's what TOTAL_OVER is for.

 >  Let's leave it as it is.

And have the AP238 people be confused as to how to write the constraint that 
they mean, since the Note says that the ONEOF means more than the normative 
text says it does.  They mean "at most one of A and B", and they don't want to 
require that it "shall contain" either.  Should they believe the Note?  Should 
they say, "well, the normative text doesn't say this, we hope that validation 
tool implementors didn't believe the Note" ?  Or should they say:  Since we 
don't know what the hell ONEOF does, we can't use it; let's write what we mean 
as a RULE:
   RULE FOR (A, B);
   WHERE
    A*B = [];
   END_RULE;
But now we can't validate the exchange file, because our EXPRESS tool doesn't 
actually interpret RULEs -- it can't do rules that involve populations, only 
rules for validating instances.  And in any case, the diagnostic would be 
worthless: Somewhere in the data set is an A that is also a B.

Instead of confusing modelers, why can't we just fix our mistake?
When we issue the (inevitable) TCorr to EXPRESS v2, let's fix the erroneous Note.

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