Merging subtype constraints (again)

[Wilson, Peter R]

Ed and others,

    I think that between us we have clearly demonstrated the murkiness of
the subtype constraints, both Ed1 and Ed2.

    There were many attempts to write a "correct" Annex B algorithm for
determining the evaluated set. I now think that we should never have
attempted this. With respect to supertypes/subtypes the basic thing that an
"EXPRESS instance checker" has to determine is whether or not a particular
instance combination is valid. If the Annex B algorithm is used then the
test can be implemented by determing the evaluated set and testing if the
particular combination is a member of the set and, as has been pointed out
in the past, the complexity (or order) of the evaluated set computation is
proportional to at least the total number of subtypes. I haven't worked it
out but the complexity could well be proportional to some power (> 1) of the
number of subtypes.

    I now have an instinctive feeling that Annex B would be much improved if
it was rewritten as how to test a particular combination of instances for
validity. Eg., any subtype must be in combination with all its supertypes;
any combination that includes more than one type specified in a ONEOF(...)
is invalid; etc.

    It appears that TOTAL_OVER cannot be mapped to any Ed1 constraint
expression, which forces an Ed2 to Ed1 mapping to be in the form of a RULE.
This implies to me that we had better take a really good look at the whole
subtype constraint area.

    I am still very concerned about the Ed2 short to Ed1 long mapping as I
think that it is order sensitive (although the past week has shown that I am
liable to misinterpret things); that is, doing Ed2 short to Ed2 long to Ed1
long is not the same as doing Ed2 short to Ed1 short to Ed1 long. I would
very much like to see the proposed final versions of the Ed2 to Ed1
conversion algorithm and the Short to Long algorithm. 

    As an editor of an AP (which will hopefully use modules) and also of new
IRs to support the AP I have a vested interest in ensuring that they will
cooperate smoothly with the least amount of work on my part.     

Peter W.

Dr Peter R. Wilson
Boeing Commercial Airplanes
PO Box 3707, MS 6H-AF, Seattle, WA 98124-2207
(Package Delivery: MS 6H-AF, 1601 E. Valley Frontage Road, Renton, WA 98055)
Tel: (425) 237-3506, Fax: (425) 237-3428
Email: peter.r.wilson at boeing.com
--------------------------------
Any opinions expressed above are personal;
they shall not be construed as representative of any organisation.
--------------------------------
 

> -----Original Message-----
> From: Ed Barkmeyer [mailto:edbark at nist.gov]
> Sent: Monday, May 13, 2002 8:25 AM
> To: Phil.Spiby at eurostep.com
> Cc: 'wg11'
> Subject: Re: Merging subtype constraints (again)
> 
> 
> All,
> 
> Phil is correct.  It just goes to show that you should always 
> read all the
> fine print carefully.  If I had correctly read Annex B in 
> 1993, I would have
> voted No on the DIS.  Annex B.3 rule (b) very clearly agrees 
> with Phil, and
> makes Peter's and my interpretation of ABSTRACT SUPERTYPE OF (...)
> completely incorrect.  As a consequence, I fully agree that 
> TOTAL_OVER does
> something that could not formerly have been done in Express.
> 
> Unfortunately, Peter and I thought that what TOTAL_OVER does 
> was possible
> with ABSTRACT SUPERTYPE OF.  The problem is that 9.2.4.1 
> makes ABSTRACT
> SUPERTYPE OF exactly equal to the ABSTRACT SUPERTYPE 
> constraint combined
> with some impossible to decipher SUPERTYPE OF (...) clause.
> The subtypes that appear in the SUPERTYPE OF list have *no 
> meaning* with
> respect to the ABSTRACTness.  That is the subtlety that Peter 
> and I missed.
> 
> So ignore everything I have said about SUBTYPE_CONSTRAINTS, 
> TOTAL_OVER,
> ABSTRACT, SUPERTYPE, etc.  It was mis-informed and entirely wrong.
> I have no idea how SUBTYPE_CONSTRAINT interacts with SUPERTYPE OF,
> and I don't care.
> 
> My operating rule still stands: Use RULEs!  
> Never use SUPERTYPE clauses, and don't bother with 
> SUBTYPE_CONSTRAINTS!  
> They give you a way to write another 40% of what can be more easily, 
> correctly and clearly written with RULEs!  And as Peter has 
> demonstrated, 
> they add yet another degree of confusion to the infamous 
> SUPERTYPE clause.
> 
> Annex B will have to be modified to accommodate TOTAL_OVER; otherwise
> there will be no consistent interpretation of any of this stuff.
> My recommendation would be to replace Annex B with an interpretation
> of all of the constructs in terms of RULEs, which are in turn based on
> set theory, as exemplified in my previous emails and Peter's paper.
> 
> -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."
>