Merging subtype constraints (again)

[Ed Barkmeyer]

"Wilson, Peter R" wrote:
>     Ed, in a message to the exploder on 2002/05/08, made a convincing
> argument that subtype constraint expressions from different
> SUBTYPE_CONSTRAINTS for a common entity could be merged by ANDing the
> expressions.

NO!!!  Peter, you misunderstood.  (Probably I was not too clear.)
I said the constraints can be combined by "LOGICAL AND", like RULEs,
*NOT* "SUPERTYPE AND".  "SUPERTYPE AND" is *not* LOGICAL (Boolean) AND; 
it is much more like "SET EQUAL".

>     The White Paper on generating long forms stated that in an Ed2 to Ed1
> conversion the constraint expressions should be ANDORed together.
>
>     Following Ed's argument, the White Paper should be revised to specify
> AND instead of ANDOR.

The White Paper may need revision (I haven't read it since some early
draft), but it was my impression that it was to be superseded by the
forthcoming Annex to Part 11 Ed2, anyway.

But AND is wrong in many cases.  I think ANDOR works correctly for
joining AND and ONEOF (and ANDOR) subtype constraints into a
supertype-expression in a SUPERTYPE OF clause.  I'm not sure that
"joining subtype constraints" by ANDOR (or any other connector)
is always correct in an ABSTRACT SUPERTYPE OF clause.  The ABSTRACT
SUPERTYPE OF is declaring a TOTAL_OVER constraint, and if you add
an ANDOR, you are adding things to the list of subtypes whose 
population union covers the population of the supertype.  In the
best of cases, the addition doesn't change the TOTAL_OVER constraint,
but it makes it less clear.  In the worst of cases, it *relaxes the
constraint*.

For example:
 ENTITY vehicle ABSTRACT SUPERTYPE OF 
  (one_wheel ANDOR two_wheel ANDOR three_wheel ANDOR four_wheel); ...
 END_ENTITY;

If I add:
 SUBTYPE_CONSTRAINT wheeledness FOR vehicle;
  ONEOF (one_wheel, two_wheel, three_wheel, four_wheel);
 END_SUBTYPE_CONSTRAINT;

These can be merged by ANDOR:
 ENTITY vehicle ABSTRACT SUPERTYPE OF 
  (one_wheel ANDOR two_wheel ANDOR three_wheel ANDOR four_wheel ANDOR
   ONEOF (one_wheel, two_wheel, three_wheel, four_wheel)); ...
 END_ENTITY;

But if instead I add:
 ENTITY motorized_vehicle SUBTYPE OF vehicle; ...
 SUBTYPE_CONSTRAINT no_motorized_unicycles FOR vehicle;
  ONEOF (one_wheel, motorized_vehicle);
 END_SUBTYPE_CONSTRAINT;

it would be merged with the above to produce:
 ENTITY vehicle ABSTRACT SUPERTYPE OF 
  (one_wheel ANDOR two_wheel ANDOR three_wheel ANDOR four_wheel ANDOR
   ONEOF (one_wheel, motorized_vehicle)); ...
 END_ENTITY;

And this weakens the original constraint.  The original did not accept
 vehicle&motorized_vehicle 
as an evaluated set member.  And neither did the subtype constraint.
Both would require an evaluated set member that contains vehicle to 
contain one of:
 vehicle&one_wheel, vehicle&two_wheel, vehicle&three_wheel, or 
 vehicle&four_wheel
But the proposed merge *does* accept
 vehicle&motorized_vehicle 
as an evaluated set member!

(But ANDing the additional constraint is totally wrong.
 ENTITY vehicle ABSTRACT SUPERTYPE OF 
  (one_wheel ANDOR two_wheel ANDOR three_wheel ANDOR four_wheel 
   AND ONEOF (one_wheel, motorized_vehicle)); ...
 END_ENTITY; 
disallows bicycles.  I.e.
 vehicle&two_wheel
is not a valid evaluated set member.  One of
 vehicle&two_wheel&one_wheel, vehicle&two_wheel&motorized_vehicle
is required.)

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