Part11e2: Interfacing (USE/REF) meets SUBTYPE_CONSTRAINT

[Ed Barkmeyer]

Phil Spiby wrote:

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

Yes.  I missed that.  What actually happens in Step (g1) is that A is
in the disallowed list.  And all instances containing A are removed from
the valid list by (g3).

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

At this point, it hardly makes a difference.  The current text, however
obscurely, accomplishes the intent. And it is no more obscure than the rest
of Annex B and C.  If it works, don't fix it.

> 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 agree -- it should not be normative text in 11.4.3.  I would suggest a
Note, however.  This is an important consequence that should not require the
reader to go to Annex C and excerpt it from the curious text.  

(You will pardon my doubt that people ever explicitly interface things they
don't intend should ever be instantiated.  But then I don't see any reason
for USE/REFERENCE, either.  A model interfaces a concept.  Making rules for
the allowable instantiation of modeled types is a separate and unrelated
feature.  Put another way, if I can explicitly interface a type that cannot
be instantiated, why can I not *declare* an ENTITY that cannot be
instantiated?  After all, that is what I will get in the long form!  This
was the subject of another email, or a U.S. comment, I don't remember
which.)

> I think the Ed2 -> Ed1 mapping should result in a single schema, as you have
> argued (and was proposed in the initial draft). 

I think we have simply re-discovered what we did then.  Any other choice
produces the kind of non-deterministic results Peter identified.

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

Frankly, I think the "subtype expression" is one of the worst modeling ideas
in Express.  But I now believe they can be properly combined by ANDOR.  So I
see no reason not to do that.  

My remaining concern, however, is that one cannot read clause 9.2.4 and
figure out even remotely what they mean.  One must read the algorithm in
Annex B and C to determine what they mean, and it takes an expert in reading
other people's code to form an intuitive interpretation of those Annexes. 
So I stand by my recommendation to rewrite the normative text of 9.2.4.2, .3
and .4 to state an interpretation that is comprehensible to humans.  (I
attach the relevant part of that email below.  I don't necessarily insist
that the words I proposed are exactly what is wanted, but the difference in
content between what I wrote and what the text currently says is enormous!)

In addition, I would suggest that the equivalent RULEs be added as NOTES. 
It will make it easier for some folks to understand "combining" supertype
expressions and TOTAL_OVER.

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

Thank you.  It is the *simpler* that is the issue here.
The thing that subtype expressions and TYPEOF/SIZEOF/QUERY do wrong is to
complicate simple rules.  This makes the models unreadable by the people we
most need to reach: the users and the engineering tool vendors.  [Most
constraints on populations and aggregates can be written using FORALL,
THERE_EXISTS and INSTANCE_OF.  EXPRESS doesn't have the first two at all,
and has the last (as IN) only in RULEs and not in local rules.  Instead, it
has the misbegotten TYPEOF function and the less-often-useful QUERY
construct.  But it is much too late to fix this.]

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

Ed Barkmeyer wrote:

> It also follows that 9.2.4.2, 9.2.4.3 and 9.2.4.4 must be rewritten so
> as to make the intent of SUBTYPE_CONSTRAINTs clear.
> 
> 9.2.4.2 Replace the normative text with: "The ONEOF constraint states
> that the populations of the operands in the ONEOF list are mutually
> exclusive.  No instance of any of the populations of the operands in the
> ONEOF list shall be an instance of the population of any other operand
> in the ONEOF list.  When a ONEOF constraint occurs as an operand in
> another constraint it represents the union of the populations of the
> operands in the ONEOF list."
> 
> 9.2.4.3 Replace the normative text with: "ANDOR does not state a
> constraint.  Within a complex constraint, the ANDOR represents the union
> of the populations of the operand expressions.  An instance of the
> population designated by the ANDOR expression may be an instance of
> either operand population or an instance of both operand populations
> simultaneously."
> 
> 9.2.4.4 Replace the normative text with: "AND states the constraint that
> the populations specified by the two operands shall be identical.  That
> is, any instance of the left operand population shall also be an
> instance of the right operand population, and any instance of the right
> operand population shall also be an instance of the left operand
> population.  When the AND expression occurs as an operand in a complex
> constraint, it represents either/both of its operand populations."
> 
> In 9.2.4, after the second paragraph of text insert:
> "The meaning of a subtype-constraint is the set of constraints stated in
> the supertype-expression.  Although the result of the
> supertype-expression is nominally a population, that population has no
> significance.  That is, the nominal population resulting from the
> supertype-expression may include instances that are not actually
> contained in the constrained population, and that population does not
> necessarily include all instances of the supertype.
> 
> NOTE -- A subtype-constraint can contain any number of AND constraints
> and ONEOF constraints.  Each is interpreted as a separate constraint, in
> addition to its interpretation as a population in the statement of some
> more complex constraint.  Independent constraints can be connected by
> ANDOR."
> 
> and at the end of the next paragraph, add:
> "That is, Annex B characterizes the populations which satisfy the whole
> subtype-constraint."
> 
> And all of this will still be correct for SUBTYPE_CONSTRAINT.