OCL 2.4 RTF Avatar
  1. OMG Issue

OCL24 — Clarify invalid propgation/conformance priority

  • Key: OCL24-8
  • Legacy Issue Number: 18437
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    There is a contradiction between invalid conform to anything and invalid always propagates for e.g.

    Sequence{}->first().oclIsKindOf(Class)

    oclIsKindOf uses the invalid input to return true.

    Invalid propagation should dominate giving invalid.

    This requires OclInvalid::oclIsKindOf, oclIsTypeOf, oclType, oclAsType overloads to explicitly return invalid.

  • Reported: OCL 2.3.1 — Mon, 11 Feb 2013 05:00 GMT
  • Disposition: Resolved — OCL 2.4
  • Disposition Summary:

    (A) It is clearly correct that OclVoid/OclInvalid conform to anything so that null/invalid can be used anywhere.
    (B) It is also clearly correct for navigation on null and invalid to be invalid so that bad results propagate.
    The above are not contradictory. The contradiction arises through the introduction of the oclIsInvalid() and oclIsUndefined() operations that may be used on null or invalid, despite (B).
    It would appear that oclIsInvalid() and oclIsUndefined() must be privileged to violate the strictness of (B). If so, are oclIsKindOf, oclIsTypeOf, oclType, oclAsType etc. also privileged?
    The specification can be clarified by making all oclXXX() operations privileged so that they can be used on null and invalid and defining their OclVoid and OclInvalid overloads explicitly.
    The affected text can be clarified to eliminate the accidental omission of operation calls for null and invalid.
    The affected text covers the DataType equality issue so the resolution of Issue 14918 is included

  • Updated: Fri, 6 Mar 2015 20:57 GMT