Issue 1775: MOF Constraints are pure predicates (mof-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Minor Summary: Summary: Modify the description of MOF Constraint in section 3 to make it clear that MOF Constraints should be interpreted as pure predicates that specify a "validity" condition on a collection of meta-objects They do not in any way require or allow modification of the default behavioral semantics of a server. Evaluation of constraints must be side-effect free. Resolution: resolved and closed Revised Text: Actions taken: August 5, 1998: received issue May 8, 2000: closed issue Discussion: Proposed resolution: 1. Add text to state that Constraints should not be used to over-ride inate behavior of the M1 level semantic model. 2. Add text to state that evaluation of Constraints as part of immediate or deferred val-idation should have not any side-effects on any state (visible or hidden). In other words, the order and timing of Constraint evaluation has no effect apart from de-termining which constraint error exceptions get raised. Implementation: Covered 1) in a rewrite of Section 3.4.21, “Constraint,” on page 3-64. Covered 2) in Section 4.11.4, “Constraint evaluation should not have side-effects,” on page 4-23. Done. [SC] End of Annotations:===== Return-Path: To: mof-rtf@omg.org, issues@omg.org Subject: MOF Constraints are pure predicates Date: Wed, 05 Aug 1998 11:22:08 +1000 From: Stephen Crawley Source: DSTC (Dr. Stephen Crawley, crawley@dstc.edu.au) Nature: Editorial Severity: Minor Modify the description of MOF Constraint in section 3 to make it clear that MOF Constraints should be interpreted as pure predicates that specify a "validity" condition on a collection of meta-objects They do not in any way require or allow modification of the default behavioral semantics of a server. Evaluation of constraints must be side-effect free. Additional text: In discussion of 1711, GK Khalsa seems to suggest that MOF Constraints can be used to specify the behavior of an implementation. For example, he suggested that a MOF Constraint stating that "x.attr1 == x.attr2" could or should be interpreted as telling the server implementor that a value assigned to "x.attr_1" should be propagated to "x.attr_2" so that the constraint is satisfied. While I can't see any text that supports GK's suggestion, I also can't see any text that explicitly forbids an implementation from "messing around" with the state of a collection of meta-objects. Allowing this to happens would mean that different implementations of a server could behave in radically different ways. This makes interoperability problematical. ========= If we DO want to allow a modeler to use OCL expressions (or whatever) to specify behavior (specifically of Operations, derived Attributes or derived Associations), we need to define a variant of Constraint in which the 'evaluationPolicy' attribute is removed. It should be linked to the object whose behavior it is defining using a new association. This would be a MOF extension, not an RTF issue.