Part11e2: Interfacing (USE/REF) meets SUBTYPE_CONSTRAINT

Tue May 21 02:22:02 EDT 2002

Hi guys,

did you in your discussions on interfacing subtype_constraints agree whether
they can be USEd, REFERENCEd, or both?
I will need to update clauses 11.1 and 11.2 correspondingly. So far I have
not discovered any change request to these chapters.

Thanks, Jochen.
____________________________________________________________
Jochen Haenisch			E-mail: Jochen.Haenisch at epmtech.jotne.com
EPM Technology AS		Home of the EXPRESS Data Manager
P.O Box 6629 Etterstad		Tel: Int + 47 23 17 17 26; mobile: Int + 47
922 60 274
N-0607 Oslo				Fax: Int + 47 23 17 17 01  
Norway					Web:  http://www.epmtech.jotne.com

> -----Original Message-----
> From:	Ed Barkmeyer [SMTP:edbark at nist.gov]
> Sent:	20. mai 2002 17:31
> To:	Phil.Spiby at eurostep.com
> Cc:	SC4 WG11
> Subject:	Re: Part11e2: Interfacing (USE/REF) meets SUBTYPE_CONSTRAINT
> 
> 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.