Part11e2: Interfacing (USE/REF) meets SUBTYPE_CONSTRAINT

[Ed Barkmeyer]

All,

We really, really need to look carefully at the rules for interfacing
SUBTYPE_CONSTRAINTs.  
The Ed1 rules are given in Annex C and referenced in 11.4.3.  The DAM
proposes changes to 11.4.3 and Annex C, and adds 11.4.7. 

Issue 1: Clarify 11.4.3 vs 11.4.7

The proposed text of the DAM says the following should be added to
11.4.3:
  "- all subtype constraints for the interfaced entity data type;"

At the end of the list of implicit interfaces, 11.4.3 goes on:
"Subtype/supertype graphs may be pruned as a result of only following
the SUBTYPE OF links when collecting the implicit interfaces of an
interfaced entity data type. The algorithm used to calculate the allowed
instantiations of the resulting pruned subtype/supertype graph is given
in annex C."

This paragraph should be aligned with the proposed 11.4.7.  I suggest
replacing it with: 
"SUPERTYPE clauses for interfaced entity data types are considered
special cases of subtype constraints and are interfaced as specified in
11.4.7."

Issue 2:  Move the AND rule from Annex C to 11.4.3.

Annex C gives the following interpretation of the SUPERTYPE clause for
interfaced entity types:

"This annex gives the rules required to resolve the subtype/supertype
graphs where one or more entity data types, originally in the graph,
have not been interfaced. These missing entity data types leave holes in
the supertype expressions. Such holes are denoted by <> in this clause.
The following reductions are used to remove these holes from a supertype
expression:

- ONEOF(A, <>, ...) => ONEOF(A, ...)
- ONEOF(<>) => <>
- ONEOF(A) => A
- A AND <> => ONEOF(A, A)
- A ANDOR <> => A
"

To explain the curious construct ONEOF(A,A), the standard continues: 
  "The treatment of AND is to ensure that entity data types which are
constrained in the original schema to be combined, are not allowed to
exist in this schema (ensured by ONEOF(A,A)) if the entity data types
they were to be combined with are not interfaced."

This appears to be nonsense.  According to B.2.2, ONEOF(A,A) produces
A&A, and according to B.1, A&A == A.  And these reductions will be
applied by Step (c) of Annex B, which Step (d) of Annex C directs us to
perform.  So how ONEOF(A,A) "ensures" the stated intent is beyond me.

What is really being stated here is a rule that should appear in 11.4.3
just after the paragraph that refers to Annex C, to wit:
"An entity data type which is constrained in the original schema to be
combined (by an AND in a supertype expression), shall not be explicitly
interfaced if no entity data type that would satisfy the AND constraint
is interfaced."

In Annex C, we should change the rules to accomplish the intent.  The
situation A AND <> *can* occur in a valid schema if the entity type is
*implicitly interfaced*.  And the intent stated in Annex C is probably
correct in that case -- such an A cannot be instantiated.  But I don't
think ONEOF(A,A) accomplishes that intent.  What is required is:

a. Replace
- A AND <> => ONEOF(A, A)
with
- A AND <> => A AND ?X, where ?X is a pseudo-entity-name that does not
appear in the schema,

b. add a step after step (d),
(e) Delete from the evaluated set every member that contains ?X.


Issue 3:  Correct the interface rule for TOTAL_OVER.

The DAM proposes to add the following rules to Annex C
  "- TOTAL_OVER(A , <>, ... ) => TOTAL_OVER(A, ... )
   - TOTAL_OVER(<>) => <>"

The first of these rules is wrong, and the fix obviates the second rule.

Suppose the interfaced schema contains the constraint:
  SUBTYPE CONSTRAINT either_b_or_c FOR A;
    TOTAL_OVER(B, C);
  END_SUBTYPE_CONSTRAINT;

Proposed rules:
- If all of A, B, C are interfaced, the TOTAL_OVER constraint is
interfaced.
- If only A is interfaced, then the TOTAL_OVER constraint is not
interfaced.  (This is the second rule above.)
- If only A and B are interfaced, i.e. not all subtypes in the
TOTAL_OVER constraint are interfaced, the constraint is *not*
interfaced.  

In the last case, the rule in the DAM would result in TOTAL_OVER(B). 
But there is no justification for that result.  The original schema said
that some A's are not B's.  They are C's, but the interfacing schema
doesn't know or care about the properties of C's (which might implicitly
interface another dozen types); as far as the interfacing schema is
concerned, C = A - B, and has no interesting properties.  That is, in
the interfacing schema, A can be instantiated outside of B.  And that is
consistent with the interfaced schema.  But TOTAL_OVER(B) would disallow
that.

So I suggest replacing the proposed change to Annex C with:
"- TOTAL_OVER(...) -- see below"

"TOTAL_OVER:  If all of the subtypes in the list are interfaced, the
TOTAL_OVER constraint is interfaced without change.  If not all subtypes
in the TOTAL_OVER constraint are interfaced, the constraint is not
interfaced."  

Issue 4:  How should SUBTYPE_CONSTRAINTs (and supertype expressions) be
combined?

Clause 9.7 should say, just before the syntax box:
"For a population to be valid, all constraints on the supertype/subtype
graph must hold, including those stated in subtype_constraints and those
stated in supertype_expressions in the entity declaration(s)." 

In the DAM, 9.7.2 says this, but only for multiple TOTAL_OVER
constraints.  In essence, the paragraph from 9.7.2 should just be
generalized and moved to 9.7.

Except for the mapping to Ed1, it is not necessary to talk about
"combining constraints".  So we shouldn't do that!


Issue 5:  Mapping SUBTYPE_CONSTRAINTS to Ed1.

For the mapping to Ed1, we may need to "combine" supertype-expressions
appearing in multiple SUBTYPE_CONSTRAINTs for the same entity and
SUPERTYPE OF clauses in the entity declaration.
I have demonstrated (to at least my satisfaction) that, in general,
these constraints can *not* be combined in a single
supertype-expression.  (When there is only one such constraint, it can
become a SUPERTYPE clause, and when there is more than one, they can
sometimes be combined by ANDOR, but not always.)

All supertype_expressions can be stated as RULEs (previous email).  And
TOTAL_OVER can be stated as a RULE (existing Ed2->Ed1 guideline). 
Therefore all subtype constraints can be stated as RULEs.  And if we
state them all as RULEs, then the requirement that all RULEs must hold
for a valid population will effectively "combine" them (by logical AND).

But there are problems with doing this, and those problems relate to
interfacing and Annex C.
Consider: ONEOF(A,B,C) becomes 
  RULE FOR (A, B, C); WHERE
   A*B = [] AND A*C = [] AND B*C = [];
  END_RULE;

According to clause 11.4.3, what is interfaced is
"— all rules referring to the interfaced entity data type and zero or
more other entity data types, all of which are either explicitly or
implicitly interfaced in the current schema;"

So if an interfacing schema contains: USE FROM s1(A,B); and does not
interface C, the above RULE is not interfaced at all.  But Annex C says
that what is interfaced is ONEOF(A,B), or rule A*B = [].  And that is
correct.

Similarly
  SUBTYPE_CONSTRAINT xxx FOR A; X AND (Y ANDOR Z); END...
becomes:
  RULE FOR (A, X, Y, Z) WHERE X = Y + Z; END_RULE;
which is not interfaced unless *all* of A, X, Y, Z are interfaced.  But
if only X and Y are interfaced, Annex C says what is interfaced is X AND
Y, or rule X = Y.  And that is a valid interpretation.  (Not interfacing
the rule at all might also be valid.)

And, interestingly,
  SUBTYPE_CONSTRAINT xxx FOR A; TOTAL_OVER (Y, Z); END...
becomes:
  RULE FOR (A, Y, Z) WHERE A = Y + Z; END_RULE;
which is not interfaced unless *all* of A, Y, Z are interfaced.  I argue
above that this is correct.  But notice that this RULE strongly
resembles the RULE for the AND constraint above!  (And in fact, if only
A and Y are interfaced, the existing draft would require A
TOTAL_OVER(Y), or rule A = Y, which is analogous to the AND case
above.)  I argue that the semantics of the AND and the TOTAL_OVER are
subtly different, which is why the interface rules are different, but
the RULE versions of the two cases are not distinguishable!  (It would
not much trouble me, however, if we made the decision not to interface
the AND rule either.)

So once again, we can only get the long-form exchange schema right.  We
can't convert subtype constraints to RULEs and get the interface rules
to work as specified in Annex C.  We can only convert the effective set
of separate constraints, each interfaced as specified in Annex C to a
set of RULEs that have to be simultaneously satisfied.  When only one
constraint applies to a supertype, and it is not a TOTAL_OVER, the
mapping can state that constraint in an Ed1 SUPERTYPE clause; in any
other case, the constraint must be stated as a RULE.

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