Part11e2: Interfacing (USE/REF) meets SUBTYPE_CONSTRAINT

[Phil Spiby]

Ed,

Please look at Step (g) in annex B again.
ONEOF(A,A) produces a disallowed combination [A&A], which, by the first
reduction, gives [A] is disallowed.

I agree that A AND <> -> ONEOF(A,A) is not obvious and should have been
better though out.

I like you idea (slightly modified) that
A AND <> -> A AND ?
This would result in the D(kA) term identifying all the complex entities
containing an A, which would then be removed from the resultant set. The
D(k?) term should not match anything since ? is not a valid name.

I disagree, with your proposed text for 11.4.3.
This, to me, states that you are wrong if you interface something which
cannot be instantiated. The intent of annex C was to explain what
instantiations could be made given a collection of declarations and
interface specifications.

I think the Ed2 -> Ed1 mapping should result in a single schema, as you have
argued (and was proposed in the initial draft). But I disagree with you that
subtype expressions should be mapped to Rules. I believe they are correctly
mapped to expressions combined with ANDOR, if you have the right
understanding of how AND and ONEOF are applied. TOTAL_OVER has to be mapped
to rules, there is now way around that, and I personally prefer the rule you
wrote since it is a whole lot simpler, the rule I used was in the style of
STEP, where SIZEOF(QUERY())=0 is the norm for predicates.

Phil

> -----Original Message-----
> From: owner-wg11 at steptools.com [mailto:owner-wg11 at steptools.com]On
> Behalf Of Ed Barkmeyer
> Sent: Wednesday, May 15, 2002 8:58 PM
> To: SC4 WG11
> Subject: Part11e2: Interfacing (USE/REF) meets SUBTYPE_CONSTRAINT
>
>
> 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."
>