Part11: Annex C and the AND constraint

[Ed Barkmeyer]

All,

Summary: What Annex C does cannot be deduced from 9.2.4.4 and is not
equivalent to any RULE.  We need to fix one of 9.2.4.4 or Annex C.

Because of what Annex C requires, I would have to modify the simple rule
I associated with SUPERTYPE OF (A AND B).

I said that A AND B is equivalent to:
 RULE FOR (A, B); WHERE A = B; END_RULE;

Since A and B can be expressions, <A> AND <B> is properly equivalent to:
 RULE FOR (a1, a2, ..., aN, b1, ..., bM); WHERE
  (a1 + ... + aN) = (b1 + ... + bM);
 END_RULE;
where aK are the types appearing in <A> and bJ are the types appearing
in <B>.

And Annex C interfaces this rule by deleting all occurrences of types not
interfaced and converting () to [], if necessary.  By comparison, 11.4.3
says that RULE will not be interfaced at all, unless all aK and bJ are
interfaced.

We note that the above RULE does not appear to be "separable".
But, if you adopt the appropriate mindset, it is.  
Consider the set of RULEs:
 RULE aK_rule FOR (aK, b1, ..., bM); WHERE: 
  SIZEOF(QUERY( a <* aK : NOT a IN (b1 + ... + bM) )) = 0;
 END_RULE;
one for each aK, and the corresponding set of RULEs:
 RULE bJ_rule FOR (bJ, a1, ..., aN); WHERE: 
  SIZEOF(QUERY( b <* bJ : NOT b IN (a1 + ... + aN) )) = 0;
 END_RULE;
one for each bJ.  This set of RULEs is equivalent to the above RULE.

And now if *all* the bJ are interfaced, interfacing any aK will cause
the appropriate aK-rule to be interfaced.  And similarly, if *all* the
aK are interfaced, then interfacing any bJ will cause the appropriate
bJ-rule to be interfaced.  And this is correct!  And Annex C does this.

So if we describe subtype-expressions as being "equivalent to certain
RULEs", which I think would be helpful for the reader, we must say 
that the simple equivalents would not necessarily produce the same 
results on interfacing.  (Both AND and ONEOF can embody multiple 
semi-separable constraints.)

Now if less than all of the bJ are interfaced, *no* aK_rule would be 
interfaced as a RULE, but Annex C would interface the RULEs:
 RULE aK_interfaced FOR (aK, bX, ..., bY); WHERE: 
  SIZEOF(QUERY( a <* aK : NOT a IN (bX + ... + bY) )) = 0;
 END_RULE;
where bX, ..., bY are whichever bJ happen to be interfaced.  And in 
the case where *no* bJ is interfaced, Annex C produces:
 RULE aK_interfaced FOR (aK); WHERE: 
  SIZEOF(QUERY( a <* aK : NOT a IN [] )) = 0;
 END_RULE;
that is, SIZEOF(aK) = 0, which is what the ONEOF(A,A) produces.

And this truly violates Bernd's "Law of Least Astonishment", because these
aK_interfaced RULEs *cannot be deduced* from the model defined by the
interfaced schema, at least not as described in 9.2.4.4!  Annex C enforces
an interpretation that the original model does not clearly imply!  Annex C
interprets the subtype-expression to create an *interfacing requirement* in
addition to stating facts about the subtype relationships.  In effect, it is
declaring that members of an AND relationship are only meaningful in the
presence of both sides.

So the favorite example:
  ENTITY Person SUPERTYPE OF (
   ONEOF(Male, Female) AND ONEOF(Citizen, Alien) );
says that no interfacing schema can be interested in Males and Females
unless it is also interested in Citizens and Aliens!  Male/Female cannot be
usefully interfaced without interfacing at least one of Citizen and Alien! 
This is what violates the Law of Least Astonishment.

But put another way, it says that the Citizen/Alien concept and the
Male/Female concept are both critical to each other, and it is not
meaningful to interface either of them without the other.  In this case,
that is an unlikely interpretation, but there certainly are cases in which
that kind of interpretation is appropriate.  (But it does make this a
dubious example of AND.)

The analogous model is:

  TYPE Male_or_Female = SELECT(Male, Female); END_TYPE;
  TYPE Citizen_or_Alien = SELECT(Citizen, Alien); END_TYPE;
  ENTITY characterized_Person SUBTYPE OF (Person);
   gender: Male_or_Female;
   origin: Citizen_or_Alien;
  END_ENTITY;

which makes these properties mandatory attributes of characterized_Person,
and requires you to interface Male, Female, Citizen, and Alien in order to
provide values for them.  If neither Citizen nor Alien is interfaced, then
the value of origin is always ?, and no instance of characterized_Person is
valid.  And when Annex C prunes the would-be RULEs above, it is analogous to
pruning the SELECT types.

So what Annex C does may be surprising, but it is not unsupportable.  The
effect of Annex C is surprising because the text talks about "different
categorizations", when Annex C makes them "related categorizations".  

We need further normative text in either 9.2.4.4 or in 11.4.7 (and a note in
other one to point to it) that states this interpretation of AND.  It is not
just that the populations are identical, but that both supertype-factors are
critical in characterizing the single population.  (The problem with this is
that there is then no subtype-constraint that just says the populations are
identical.  TOTAL_OVER only works in some cases.  In general, you have to
write a RULE.)  And it might be appropriate to state the (surprising)
interpretation of the Citizen/Alien example, or choose a different example.

Of course, if we don't really mean this, then we should fix Annex C!

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