Object Constraint Language Avatar
  1. OMG Specification

Object Constraint Language — Closed Issues

  • Acronym: OCL
  • Issues Count: 361
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
OCL231-38 Lack of features commonly used in OCL UML 1.1 OCL 2.3.1 Resolved closed
OCL231-37 Issue nnnn: Japan PAS Ballot Comment 13 (ocl2-rtf) - Section 8.3.1 OclExpression (l16, p44) OCL 2.3 OCL 2.3.1 Resolved closed
OCL23-40 toLowerCase referred to as toLower (similarly for toUpperCase) OCL 2.2 OCL 2.3 Resolved closed
OCL21-354 Section 8.3.9 of the final Adopted Version of the OCL 2.0 Spec OCL 2.0b1 OCL 2.1 Resolved closed
OCL2-16 OCL needs an abstract syntax, just like the UML metamode OCL 2.0b1 OCL 2.0b2 Resolved closed
OCL2-13 6.8.1.9 String on page 6-34 OCL 2.0b1 OCL 2.0b2 Resolved closed
OCL2-12 1. 6.2.1 "legend" on page 6-3, Internationalization issue OCL 2.0b1 OCL 2.0b2 Resolved closed
OCL2-15 inhibtedChar on page6-48, OCL 2.0b1 OCL 2.0b2 Resolved closed
OCL2-14 EBNF of the String on page6-48. OCL 2.0b1 OCL 2.0b2 Resolved closed
OCL2-11 Downcast OCL collection operators OCL 2.0b1 OCL 2.0b2 Resolved closed
OCL2-10 In 6.9 "Grammar for OCL" (Internationalization issues) OCL 2.0b1 OCL 2.0b2 Resolved closed
OCL2-9 OCL: Created and Destroyed instances OCL 2.0b1 OCL 2.0b2 Resolved closed
OCL2-8 context declaration for OCL invariants OCL 2.0b1 OCL 2.0b2 Resolved closed
OCL2-7 postcondition for the operation round on the predefined OCL type OCL 2.0b1 OCL 2.0b2 Resolved closed
OCL23-39 Role 'collectionTypes' should be 'collectionType' OCL 2.1 OCL 2.2 Resolved closed
OCL2_-92 The property 'unspecified' can be removed from the metamodel OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-94 Instanciation of collection types OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-93 The metaclass 'OclMessageArg' can be removed from the metamodel OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-91 The composition associations in figure 9 are missing OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-90 The superclass of UnspecifiedValueExp is not ModelElement OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-89 Reusing TypedElement for UnspecifiedValueExp OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-88 An UnlimitedNaturalExp should be added in the metamodel OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-87 The Ocl prefix should be avoided as much as possible in metaclass names OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-86 Should avoid using the OclHelper stereotype OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-85 Inconsistency in the way to represent Tuple literal part OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-84 The naming of the parts properties in literals is not consistent OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-83 The set of possible values of CollectionKind is missing OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-82 Use a uniform convention to name multivalued properties OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-79 make link explicit OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-78 The container for self and return variables is missing OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-81 Inherited or non navigable properties should not appear in class descriptio OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-80 Should compare the value of the slots and not the objects itself OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-77 VariableDeclaration should be renamed Variable OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-76 Specific inheritance links at M1 level should be removed OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-75 OclAny cannot be an instance of Classifier OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-74 Section: 11.9.2 reject OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-73 Section: 11.9.1 exists OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-72 Section: 11.7.2 OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-71 ’StringValue.iterators OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-70 context Classifier OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-69 context TTupleType::... OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-68 referredOperation OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-67 "Bag" OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-66 context TTupleType::make(atts : sequence(Attribute) ) : TTupleType OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-65 type of a TupleLiteralExp OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-62 type of a TupleLiteralExp OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-64 The type of the attribute is the type of the value expression. OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-63 tuple literal expression OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-61 message is a send action, OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-60 message is a call action, OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-59 ’parameter’ should be ’Parameter’ OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-58 the property ’refParams’ is not present in OperationCallExp OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-57 forall’ should be ’forAll’ OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-54 attributes of the signal. OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-53 parameters of the operation. OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-56 5] The target of an OCL message cannot be a collection. OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-55 ’sentMessage’ should be ’sentSignal’ OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-48 The type of the condition of an if expression must be Boolean. OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-50 result type OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-49 iterator OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-52 type of each iterator var. must be type of the elements of source collectio OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-51 1] The type of the source expression must be a collection. OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-47 collection literal expression OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-46 7. context AttrubuteCallExp OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-45 context TupleType::make(atts : sequence(Attribute) ) : TupleType OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-44 In section 3.3.9 OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-43 context Operation OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-42 If message is a send action, arguments must conform to attributes of signal OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-41 The type of body expression must conform to declared type of result variabl OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-40 Errors in the abstract syntax chapter 1. -- [1] Integer conforms to real. OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-39 The classifier name TupleType is also a reserved word OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-38 change rollnames OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-37 OclMessageArg metaclass that is currently defined, could be removed. OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-36 tostring operation for Integer, Real and Boolean OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-35 plus (infix) operator (’+’) OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-34 flatten operation OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-30 result of applying the collect operation to a Sequence OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-29 Remove the composition symbol at the end of PropertyCallExp OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-33 There should be an OclTypeLiteralExp metaclass OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-32 There should be an OclTypeLiteralExp metaclass OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-31 There should be an OclUndefinedLiteralExp metaclass OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-28 section 7.4.6 (Re-typing or casting) on p.13 OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-27 Use the "null" keyword instead of verbose "OclUndefined". OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-26 What's a collection? OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-25 Keywords "attr" and "oper"? OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-24 Formal Semantics of OCL 2.0 in Appendix A OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-23 OclUndefined = OclUndefine ? OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-22 Enumeration approach for reflection OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-21 Issue: OclModelElement OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-20 Issue: OclType OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-19 Issue: oclIUndefined() versus isEmpty() OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-18 Issue: Attributes and Association Ends versus Properties OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-17 Issue: Operator precedence OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-16 Issue: Keywords OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-15 Issue: Set of characters OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-14 Issue: General section to define OCL concepts OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-13 Reintroduce allAttributes operator OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-12 Missing equality and inequality operations on collection types OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-11 Clarify definition of collectNested for Set, Bag, and Sequence OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-10 Undefined values, isEmpty() and Collections OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-7 Flagging recursive definitions OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-9 Attributes and Association Ends versus Properties OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-8 Operator precedence OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-4 Consider OclType as a powertype OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-6 Flagging insecure cast from Set to Sequence OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-5 domain for library operations /, div OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-3 Omit predefined type OclModelElement. OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-2 oclIsNew for a collection OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-1 OCL 2.0/international character sets OCL 2.0b2 OCL 2.0 Resolved closed
OCL24-13 Problems with OCL definition of Package::makesVisible OCL 2.3.1 OCL 2.4 Resolved closed
OCL21-353 Section: A/2.3 Enumeration Types OCL 2.0 OCL 2.1 Resolved closed
OCL2-6 Section 6.6.2 UML 1.4 OCL 2.0b2 Resolved closed
OCL23-19 OCL 2.1 12 Typos OCL 2.1 OCL 2.3 Resolved closed
OCL23-18 OCL 2.1 12.2.3 Incomplete resolution of Issue 9796 for attrOrAssocContextCS OCL 2.1 OCL 2.3 Resolved closed
OCL23-26 OCL 2.1 11.2 Conflicting {OclVoid, OclInvalid}::{oclIsTypeOf, oclIsKindOf, oclAsType} semantics OCL 2.2 OCL 2.3 Resolved closed
OCL23-25 OCL 2.1 Implicit Conversion to Collection Literal OCL 2.2 OCL 2.3 Resolved closed
OCL23-29 String.equalsIgnoreCase(String) should result in Boolean OCL 2.2 OCL 2.3 Resolved closed
OCL23-28 OCL 2.1 11.2.3 Navigated Implicit Conversion to Collection Literal OCL 2.2 OCL 2.3 Resolved closed
OCL23-24 OCL 2.1 11.2.5 Numeric = and <> operations should compare values rather than objects OCL 2.2 OCL 2.3 Resolved closed
OCL23-27 OCL 2.1 8.3.8 OclInvalid::allInstances OCL 2.2 OCL 2.3 Resolved closed
OCL23-23 wrong variable name OCL 2.1 OCL 2.3 Resolved closed
OCL23-22 Undefined operation tail() on p 130 OCL 2.1 OCL 2.3 Resolved closed
OCL23-17 OCL 2.1 12.2.5 named-self classifierContextDeclCS OCL 2.1 OCL 2.3 Resolved closed
OCL23-21 Undefined operation tail() OCL 2.1 OCL 2.3 Resolved closed
OCL23-20 Undefined operation tail() OCL 2.1 OCL 2.3 Resolved closed
OCL231-36 The t should be subscripted next to the equal sign OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-35 Comparison operators don't exist for Boolean OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-14 Issue nnnn: Japan PAS Ballot Comment 9 (ocl2-rtf) Section 7.4.8 OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-13 Issue nnnn: Japan PAS Ballot Comment 8 (ocl2-rtf) Section 10.3.2 OperationCallExpEval P127 OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-22 Japan PAS Ballot Comment 24 (ocl2-rtf) 10.1 Introduction OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-21 Japan PAS Ballot Comment 23 (ocl2-rtf) 10 Semantics Described Using UML OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-19 Japan PAS Ballot Comment 18 (ocl2-rtf) OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-18 Japan PAS Ballot Comment 17 (ocl2-rtf) Section 9.3.4 simpleNameCS OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-12 Issue nnnn: Japan PAS Ballot Comment 7 (ocl2-rtf) Section 7.4.5 table 7.3 OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-11 Issue nnnn: Japan PAS Ballot Comment 6 (ocl2-rtf) OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-20 Issue from PAS Ballot comment for ISO/IEC DIS 19507 Section 9.3.29 OperationCallExpCS OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-15 Issue nnnn: Japan PAS Ballot Comment 10 (ocl2-rtf) Section 7.4.9 list of keywords OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-17 Japan PAS Ballot Comment 16 (ocl2-rtf) - Section 9.3.3 VariableExpCS OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-16 Issue nnnn: Japan PAS Ballot Comment 11 (ocl2-rtf) p 35 line 1 OCL 2.3 OCL 2.3.1 Resolved closed
OCL23-5 OCL 2.0, 2.1 Loop iterators are not ordered and other inconsistencies OCL 2.1 OCL 2.3 Resolved closed
OCL23-4 OCL 2.0, 2.1 inconsistent definition of null and invalid OCL 2.1 OCL 2.3 Resolved closed
OCL23-13 OCL 2.1 7.4.7 Inconsistent Operator Associativity and Precedence OCL 2.1 OCL 2.3 Resolved closed
OCL23-12 OCL 2.1 Resolution of missing Concrete Syntaxes and Reserved Words OCL 2.1 OCL 2.3 Resolved closed
OCL23-3 Missing specification of UnlimitedNatural OCL 2.1 OCL 2.3 Resolved closed
OCL23-2 Erroneous operation names 'isOclType' and 'asOclType' OCL 2.1 OCL 2.3 Resolved closed
OCL23-1 [OCL-2.1 RTF] Transitive closure operator OCL 2.1 OCL 2.3 Resolved closed
OCL23-14 OCL 2.1 7.4.9 true, self, Bag and String are not reserved words OCL 2.1 OCL 2.3 Resolved closed
OCL23-9 Inconsistent lookup for underscored symbols OCL 2.1 OCL 2.3 Resolved closed
OCL23-8 OCL 2.1 Inconsistent implementation of Issue 6532 and contradictory resolution of Issues 7341 and 10437 OCL 2.1 OCL 2.3 Resolved closed
OCL23-16 OCL 2.1 9.3 Missing TypeLiteralExpCS OCL 2.1 OCL 2.3 Resolved closed
OCL23-15 OCL 2.1 9.3 Inferred TupleLiteralExp part type OCL 2.1 OCL 2.3 Resolved closed
OCL23-11 OCL 2.0 and 2.1 Section 9.3 CollectionRangeCS incorrect operator spelling OCL 2.1 OCL 2.3 Resolved closed
OCL23-10 OCL 2.1 Incomplete resolution 9913 InvalidLiteralExpCS and NullLiteralExpCS OCL 2.1 OCL 2.3 Resolved closed
OCL23-7 OCL 2.0 Inadequate Headings and PDF index OCL 2.1 OCL 2.3 Resolved closed
OCL23-6 OCL 2.0, 2.1 Inaccurate well-formedness constraints for IteratorExp OCL 2.1 OCL 2.3 Resolved closed
OCL231-33 Prime symbol lacking in the explanation preceding the formula OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-32 Confusing usage of the "precedes" symbol for generalization hierarchy OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-29 Japan PAS Ballot Comment 34 (ocl2-rtf) 13.3 Diagrams figure 13.8 OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-28 Japan PAS Ballot Comment 33 (ocl2-rtf) 13.3.3 String page 144 OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-25 Japan PAS Ballot Comment 28 (ocl2-rtf) 10.2.3 Additional Operations for the Values Package OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-24 Japan PAS Ballot Comment 27 (ocl2-rtf) Section 10.2.1 Definitions of Concepts for the Values Package OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-30 Use of the word meta OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-26 Japan PAS Ballot Comment 30 (ocl2-rtf) 10.3 The Evaluations Package, 2nd paragraph OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-31 on page 153 oclIsInState is used instead of oclInState OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-23 Japan PAS Ballot Comment 25 (ocl2-rtf) 10.1 Introduction, 3rd and 4th paragraphs OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-27 Japan PAS Ballot Comment 31 (ocl2-rtf): 10.3.1 Definitions of Concepts for the Evaluations Package OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-34 Unbalanced parenthesis in the formula OCL 2.3 OCL 2.3.1 Resolved closed
OCL23-33 OCL 2.2 UML Alignment of association names OCL 2.2 OCL 2.3 Resolved closed
OCL23-32 OCL 2.2 11.5.3 What is a locale? OCL 2.2 OCL 2.3 Resolved closed
OCL23-31 OCL 2.2 11.7.1 Why must + be commutative for Collection::sum() OCL 2.2 OCL 2.3 Resolved closed
OCL23-30 OCL 2.2 11.7.1 Why must + be associative for Collection::sum() OCL 2.2 OCL 2.3 Resolved closed
OCL23-37 OCL 2.3 Ballotted: Retracting resolutions for Issue 10439/13076 OCL 2.2 OCL 2.3 Resolved closed
OCL23-36 toLowerCase() declared as returning Integer OCL 2.2 OCL 2.3 Resolved closed
OCL23-34 the use of the keyword 'attr' OCL 2.2 OCL 2.3 Resolved closed
OCL23-38 The opertion "collect" is confused with the operation "reject" OCL 2.2 OCL 2.3 Resolved closed
OCL23-35 Definition for symmetric difference is wrong OCL 2.2 OCL 2.3 Resolved closed
OCL231-7 US PAS Ballot Comment 3 (ocl2-rtf) paragraph 1 OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-6 US PAS Ballot Comment 2 (ocl2-rtf) References OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-2 Issue on Alignment of next OCL version and references UML 2.4/ MOF 2.4 OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-5 US PAS Ballot Comment 1 OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-4 oclIsInState() OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-1 OCL 2.3 Incomplete CollectionRange well-formedness rules OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-10 Issue nnnn: Japan PAS Ballot Comment 5 (ocl2-rtf) OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-9 Issue nnnn: Japan PAS Ballot Comment 2 (ocl2-rtf) OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-3 typo in ptc/2010-11-42 and pas/2010-08-02 OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-8 Japan PAS Ballot Comment 1 (ocl2-rtf) OCL 2.3 OCL 2.3.1 Resolved closed
OCL21-347 Exact type of Set{} and missing Set(MyType){} literal definitions OCL 2.0 OCL 2.1 Resolved closed
OCL21-346 Use of simple quotes and double quotes in strings OCL 2.0 OCL 2.1 Resolved closed
OCL21-339 Missing definition of of iterators for OrderedSets OCL 2.0 OCL 2.1 Resolved closed
OCL21-338 Type of a type expression OCL 2.0 OCL 2.1 Resolved closed
OCL21-345 Use of MOF reflection in EssentialOCL should be clarified OCL 2.0 OCL 2.1 Resolved closed
OCL21-344 No way to represent type parameters in the standard library OCL 2.0 OCL 2.1 Resolved closed
OCL21-336 OCL 2.0 8.2 Collection Type packaging OCL 2.0 OCL 2.1 Resolved closed
OCL21-335 Section: A.3.2.2 Syntax and Semantics of Postconditions OCL 2.0 OCL 2.1 Resolved closed
OCL21-342 Making OclAny denote any object OCL 2.0 OCL 2.1 Resolved closed
OCL21-337 OCL 2.0: CollectionType constraint for invalid elements is incorrect OCL 2.0 OCL 2.1 Resolved closed
OCL21-341 Clarify the common supertype of Bag and Sequence OCL 2.0 OCL 2.1 Resolved closed
OCL21-340 The operation asSet, asSequence, asBag and asOrderedSet missing for OrderedSets OCL 2.0 OCL 2.1 Resolved closed
OCL21-334 Section: A.3.1.2 Semantics of Expressions OCL 2.0 OCL 2.1 Resolved closed
OCL21-343 Incosistency between UnlimitedInteger and UnlimitedNatural OCL 2.0 OCL 2.1 Resolved closed
OCL21-292 Dynamic typing with allInstances() OCL 2.0 OCL 2.1 Resolved closed
OCL21-291 missing closing parethesis inthese two expressions OCL 2.0 OCL 2.1 Resolved closed
OCL21-289 Usage of initialization and derivation constraints on the same property OCL 2.0 OCL 2.1 Resolved closed
OCL21-288 Collection element type serialization OCL 2.0 OCL 2.1 Resolved closed
OCL21-294 Section 8.2 InvalidType OCL 2.0 OCL 2.1 Resolved closed
OCL21-293 Section: 7.4.7, 7.4.9, 9.3.2 OCL 2.0 OCL 2.1 Resolved closed
OCL21-287 TypeType OCL 2.0 OCL 2.1 Resolved closed
OCL21-286 ownership of association ends does not matter for traversal in OCL OCL 2.0 OCL 2.1 Resolved closed
OCL21-284 11.7.1 OCL 2.0 OCL 2.1 Resolved closed
OCL21-283 11.2.5 (02) OCL 2.0 OCL 2.1 Resolved closed
OCL21-290 8.2.2 Well-formedness Rules for the Types Package OCL 2.0 OCL 2.1 Resolved closed
OCL21-281 11.8.1 OCL 2.0 OCL 2.1 Resolved closed
OCL21-280 11.2.4 (OclInvalid) - similar criticism as 11.2.3 OCL 2.0 OCL 2.1 Resolved closed
OCL21-282 11.2.5 OCL 2.0 OCL 2.1 Resolved closed
OCL21-285 Naming of Constraints in OCL OCL 2.0 OCL 2.1 Resolved closed
OCL21-274 Section: 7.4.9 OCL 2.0 OCL 2.1 Resolved closed
OCL21-273 Using "def" OCL 2.0 OCL 2.1 Resolved closed
OCL21-275 Section: 7.8 OCL 2.0 OCL 2.1 Resolved closed
OCL21-278 Section "IteratorExpCS" OCL 2.0 OCL 2.1 Resolved closed
OCL21-277 Section 9.2.2 OCL 2.0 OCL 2.1 Resolved closed
OCL21-279 11.2.3 OCL 2.0 OCL 2.1 Resolved closed
OCL21-276 Section 7.6.3 OCL 2.0 OCL 2.1 Resolved closed
OCL21-349 The following collection operations would be useful for the HL7 GELLO project: OCL 2.0 OCL 2.1 Resolved closed
OCL21-348 The concrete syntax given is extremely difficult to implement OCL 2.0 OCL 2.1 Resolved closed
OCL21-352 have tuple fields and let variables to have the declaration of their types explicity? OCL 2.0 OCL 2.1 Resolved closed
OCL21-351 type of the iterator variable is expected or not? OCL 2.0 OCL 2.1 Resolved closed
OCL21-350 doubts about the iterator variables OCL 2.0 OCL 2.1 Resolved closed
OCL21-295 CollectionType and CollectionKind OCL 2.0 OCL 2.1 Resolved closed
OCL21-307 no explanations about how to manipulate optional and multivalued attributes OCL 2.0 OCL 2.1 Resolved closed
OCL21-306 section 7.4.6 (p. 12) OCL 2.0 OCL 2.1 Resolved closed
OCL21-297 Section: A/1.1.1 Types OCL 2.0 OCL 2.1 Resolved closed
OCL21-296 last line on page 28 OCL 2.0 OCL 2.1 Resolved closed
OCL21-304 Section: A/1.2.4 System State OCL 2.0 OCL 2.1 Resolved closed
OCL21-303 Section: A/1.2.1 Objects OCL 2.0 OCL 2.1 Resolved closed
OCL21-302 Section: A/1.1.6 Generalization - editorial issues OCL 2.0 OCL 2.1 Resolved closed
OCL21-300 Section: A/1.1.5 Associations OCL 2.0 OCL 2.1 Resolved closed
OCL21-299 Section: A/1.1.5 Associations -- missing word OCL 2.0 OCL 2.1 Resolved closed
OCL21-301 Section: A/1.1.6 Generalization OCL 2.0 OCL 2.1 Resolved closed
OCL21-298 Section: A/1.1.5 Associations OCL 2.0 OCL 2.1 Resolved closed
OCL21-305 Section: A/2.2 Common Operations on All Types OCL 2.0 OCL 2.1 Resolved closed
OCL21-333 Section: A.2.5.8 Sequence Operations OCL 2.0 OCL 2.1 Resolved closed
OCL21-332 Section: A.3.1.2 Semantics of Expressions, Definition A.30 part ii OCL 2.0 OCL 2.1 Resolved closed
OCL21-327 Section 8.2.1 Type Conformance on page 37 OCL 2.0 OCL 2.1 Resolved closed
OCL21-330 Section: A.3.1.1 Syntax of Expressions OCL 2.0 OCL 2.1 Resolved closed
OCL21-329 Section: A.2.7 Type Hierarchy OCL 2.0 OCL 2.1 Resolved closed
OCL21-326 Section: A.2.6.1 Definition A.26 (Special Types) OCL 2.0 OCL 2.1 Resolved closed
OCL21-325 Section: A.2.6 Special Types OCL 2.0 OCL 2.1 Resolved closed
OCL21-322 Section: A.3.1.1 Syntax of Expressions OCL 2.0 OCL 2.1 Resolved closed
OCL21-324 Syntax of Expressions (second sentence after Definition A..29) OCL 2.0 OCL 2.1 Resolved closed
OCL21-323 Section: A.3.1.1 Syntax of Expressions (Definition A.29) OCL 2.0 OCL 2.1 Resolved closed
OCL21-331 Section: A.3.1.2 Semantics of Expressions OCL 2.0 OCL 2.1 Resolved closed
OCL21-328 Section 8.2 page 35 InvalidType OCL 2.0 OCL 2.1 Resolved closed
OCL21-321 Section: A.3.1.1 Syntax of Expressions OCL 2.0 OCL 2.1 Resolved closed
OCL21-311 Section: A/2.3 Enumeration Types -- editorial OCL 2.0 OCL 2.1 Resolved closed
OCL21-310 The constraint [1] on the TupleLiteralPart metaclass is overconstrained OCL 2.0 OCL 2.1 Resolved closed
OCL21-313 Section: A.2.5.2 Definition A.24 (Type Expressions) OCL 2.0 OCL 2.1 Resolved closed
OCL21-312 Section: Definition A.23 (Semantics of Navigation Operations) OCL 2.0 OCL 2.1 Resolved closed
OCL21-317 There are two instances of missing and misplaced parentheses OCL 2.0 OCL 2.1 Resolved closed
OCL21-316 A.2.5.5 Collection Operations OCL 2.0 OCL 2.1 Resolved closed
OCL21-320 Section: A.2.5.8 Sequence Operations OCL 2.0 OCL 2.1 Resolved closed
OCL21-319 Section: A.2.5.6 Set Operations Table A.4 OCL 2.0 OCL 2.1 Resolved closed
OCL21-309 OrderedSet collection OCL 2.0 OCL 2.1 Resolved closed
OCL21-318 Section: A.2.5.6 Set Operations OCL 2.0 OCL 2.1 Resolved closed
OCL21-314 Section: A.2.5.5 Collection Operations OCL 2.0 OCL 2.1 Resolved closed
OCL21-315 Section: A/2.5.5 Collection Operations - just before table A.3 OCL 2.0 OCL 2.1 Resolved closed
OCL21-308 The Tuple constructor is problematic OCL 2.0 OCL 2.1 Resolved closed
OCL2-5 OCL/MOF/UML alignment OCL 2.0b1 OCL 2.0b2 Resolved closed
OCL2-4 OCL 2: String operations OCL 2.0b1 OCL 2.0b2 Resolved closed
OCL2-3 OCL 2: Can collections contain void/undefined objects OCL 2.0b1 OCL 2.0b2 Resolved closed
OCL2-2 OCL 2: flatten OCL 2.0b1 OCL 2.0b2 Resolved closed
OCL2-1 Section 6.6.7 UML 1.4 OCL 2.0b2 Resolved closed
OCL21-270 Section: 7.3.4 OCL 2.0 OCL 2.1 Resolved closed
OCL21-269 Wrong subtyping of PropertyCallExp and NavigationCallExp OCL 2.0 OCL 2.1 Resolved closed
OCL21-268 inability to uniquely reference association ends OCL 2.0 OCL 2.1 Resolved closed
OCL21-267 Introduction and oclType() OCL 2.0 OCL 2.1 Resolved closed
OCL21-266 Circular imports OCL 2.0 OCL 2.1 Resolved closed
OCL21-272 Section: 7.5.9 OCL 2.0 OCL 2.1 Resolved closed
OCL21-271 Section: 8.3.5 OCL 2.0 OCL 2.1 Resolved closed
OCL21-248 sub evaluations (02) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-247 sub evaluations OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-254 Section: 7.5.11 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-253 Section: 7.5.9 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-246 value of a collection range OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-245 value of a collection range OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-249 Section: 6.5.4.3 Combining Properties OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-243 result value of an attribute call expression OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-251 Section: 7.4.5 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-252 Section: 7.5.3 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-250 Section: 7.4 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-244 result value of a collection literal expression evaluation OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-204 Issue: Syntax of Operation Call, Iterator, and Iterate Expressions OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-203 Issue: Abstract syntax tree OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-208 The notation for selecting elements should be more intuitive OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-207 The notation for testing the type of a metaclass is too verbose OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-206 Example with TupleType OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-211 Improve the notation when defining local variables OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-210 There is no simple way to invoke an "if then else" on a collection OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-209 notation for selecting unique element within a list should be more concise OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-216 Provide specific notational support when testing stereotypes OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-215 Suppress the usage of an Ocl prefix in standard library operations OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-202 Issue: Unspecified syntax and semantics for Integer, Real, and String OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-213 Allow implicit type casting to boolean when a boolean is expected OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-212 Allow applying iteration operations on single objects OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-214 Automatic casting between strings and enumeration values OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-217 Add a generic text formatter operator '% OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-205 The index seems incomplete OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-234 arguments of the return message of an ocl message expression OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-233 inv: model.sentSignal->size() = 1 implies OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-236 ’element’ should be ’elements’ OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-235 Only one of the attributes isPost and isPre may be true at the same time. OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-242 elements in a tuple value OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-232 arguments OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-240 The history of an object is ordered.(02) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-241 The operation allPredecessors OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-239 history of an object is ordered. OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-238 ’Element’ should be ’NameValueBinding’ OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-237 ’element’ should be ’elements’ (02) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-198 Add select/reject/collectNested to Collection OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-197 Exception of strict evaluation (queries) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-201 Issue: Virtual machine OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-200 Clarify the UML semantics of IfExpEval OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-195 Exception of strict evaluation (implies) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-196 Exception of strict evaluation (forAll, exists) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-199 Clarify the semantics of forAll OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-265 Notation for accessing class operations is inconsistent OCL 2.0 OCL 2.1 Resolved closed
OCL21-264 Navigating across non navigable associations OCL 2.0 OCL 2.1 Resolved closed
OCL21-263 allInstances OCL 2.0 OCL 2.1 Resolved closed
OCL21-261 Section: 1 - 13 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-260 Section: 11.9.3 & 11.9.4 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-258 Section: 11.2.1 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-257 Section: 10.2.2 LocalSnapshot OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-255 Section: 7.5.13 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-262 The spec does not describes the syntax of integer, real or string literals OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-259 Section: 11.5.4 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-256 Section: 7.6.2 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-219 rewrite well-formedness OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-218 Make usage of tuples less complex and less verbose OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-225 sub evaluations (in the sequence bodyEvals) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-224 context IfExpEval inv: OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-228 isSent attribute OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-227 ocl message expression OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-231 an iterate expression evaluation OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-230 missing ’inv:’ twice OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-222 1] The type of the attribute is the type of the value expression. OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-221 An additional attribute refParams lists all parameters of the referred OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-226 sub evaluations (in sequence bodyEvals) have different environment. OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-229 add ’and’ between both expression parts OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-223 context LocalSnapshot OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-220 context State::getStateMachine() : StateMachine OCL 2.0b2 OCL 2.1 Resolved closed
OCL24-12 Introduce selectByKind and selectByType operations OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-11 Collection::min/max accumulator initialized as self.first() OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-10 Collection::any() violates precondition if the collection is empty OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-9 Inconsistent inclusion of source in closure results OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-8 Clarify invalid propgation/conformance priority OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-7 OclAny::oclAsType postcondition implies type change OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-6 any iteration unsuitable for null Collection content OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-5 non(not(X)) should be X OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-4 Navigation from Association Classes does not conform to UML 2.4.1 OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-3 ISO has changed the following normative references to its documents OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-2 OCL String::indexOf OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-1 OCL 2.3 OclInvalid::= is vague OCL 2.3.1 OCL 2.4 Resolved closed

Issues Descriptions

Lack of features commonly used in OCL

  • Key: OCL231-38
  • Legacy Issue Number: 1790
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The current specification for OCL lacks many of the features we commonly
    use when doing formal specification of class interfaces, e.g. the ability
    to specify the frame condition, the ability to specify postconditions
    case-wise, the ability to specify when exceptions are thrown, etc.

    To bring OCL closer to the state of the art, I would like to see these
    considered as future extensions.

  • Reported: UML 1.1 — Mon, 10 Aug 1998 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    This issue was forked off from UML 1.x 15 years ago. It doesn't seem to have anything to do with OCL at all. But rather than throw the issue back to UML, let's address it anyway.
    One could imagine a UML extension that introduced a Frame class and an Operation.ownedFrameCondition to host it. OCL expressions could then impose the semantics.
    However a Frame would be specific to a particular implementation approach, and so it would seem more appropriate to use stereotypes to model the implementation characteristics. Perhaps one of the standard UML profiles already provides this capability.
    Disposition: Closed, no change

  • Updated: Sun, 8 Mar 2015 18:23 GMT

Issue nnnn: Japan PAS Ballot Comment 13 (ocl2-rtf) - Section 8.3.1 OclExpression (l16, p44)

  • Key: OCL231-37
  • Legacy Issue Number: 16136
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Typo. contaxt, change to context

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Initial Comment: contaxt->context
    Comment: Close as Fixed by OCL 2.3
    Disposition: Closed

  • Updated: Sun, 8 Mar 2015 17:59 GMT

toLowerCase referred to as toLower (similarly for toUpperCase)

  • Key: OCL23-40
  • Legacy Issue Number: 15527
  • Status: closed  
  • Source: yahoo.com ( Scott Forbes)
  • Summary:

    In A.2.1.2 Operations on p193, toLowerCase is referred to as toLower "case translations are possible with toUpper and toLower" and again in Table A.1

    Also toUpperCase is referred to as toUpper in the same places

  • Reported: OCL 2.2 — Tue, 14 Sep 2010 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 17:59 GMT

Section 8.3.9 of the final Adopted Version of the OCL 2.0 Spec

  • Key: OCL21-354
  • Legacy Issue Number: 8922
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I refer to Section 8.3.9 of the final Adopted Version of the OCL 2.0 Spec,
    the two additional operations on the OclExpression.
    "withAtPre" and "withAsSet".
    I am wondering where the two referred operations "atPre" and "asSet"
    (not restricted to collections) are "predefined".

  • Reported: OCL 2.0b1 — Fri, 30 Jun 2000 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:51 GMT

OCL needs an abstract syntax, just like the UML metamode

  • Key: OCL2-16
  • Legacy Issue Number: 3392
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    OCL needs an abstract syntax, just like the UML metamodel. This
    will clarify many issues about the exact semantics of OCL.
    This request has been made by multiple sources.

  • Reported: OCL 2.0b1 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — OCL 2.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:43 GMT

6.8.1.9 String on page 6-34

  • Key: OCL2-13
  • Legacy Issue Number: 4692
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    In the String explanation,
    There is a descrition that
    "The OCL type String represents ASCII strings."
    I think this cannot apply to multi-byte code.

    Could you change this sentence to
    "The OCL type String represents strings consisting
    of ASCII characters and/or multi-byte characters.

  • Reported: OCL 2.0b1 — Fri, 9 Nov 2001 05:00 GMT
  • Disposition: Resolved — OCL 2.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:38 GMT

1. 6.2.1 "legend" on page 6-3, Internationalization issue

  • Key: OCL2-12
  • Legacy Issue Number: 4691
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    1. 6.2.1 "legend" on page 6-3,
    There is a following description.
    "OCL expression are written using ASCII characters only"
    This sentence can be interpreted in this context as
    a) OCL expressions are written using only
    ASCII characters as examples in this document,
    b) the OCL expression must be written by only
    ASCII characters in general usage?

    Could you change this to
    "OCL expressions in this document are
    written using ASCII character only."

  • Reported: OCL 2.0b1 — Fri, 9 Nov 2001 05:00 GMT
  • Disposition: Resolved — OCL 2.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:38 GMT

inhibtedChar on page6-48,

  • Key: OCL2-15
  • Legacy Issue Number: 4694
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    4.Regarding inhibtedChar on page6-48,
    its definition is following.

    inhibitedChar :=
    "|"\"|"#"|"\'"|"("|")"|"*"|"+"|","|
    "|"."|"/"|":"|";"|"<"|"="|">"|"@"|
    ["|"\\"|"]"|"

    {"|"|"|"}

    "

    But, this definition is slightly different from one which we
    have provided previously.
    (Top two characters of each line are dropped)

    inhibitedChar := " " | "\"" | "#" | "\'" | "(" | ")" |
    "*" | "+" | "," | "-" | "." | "/" |
    ":" | ";" | "<" | "=" | ">" | "@" |
    "[" | "\\" | "]" | "

    {" | "|" | "}

    "

  • Reported: OCL 2.0b1 — Fri, 9 Nov 2001 05:00 GMT
  • Disposition: Resolved — OCL 2.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:38 GMT

EBNF of the String on page6-48.

  • Key: OCL2-14
  • Legacy Issue Number: 4693
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    Relating this, in the EBNF of the String on page6-48.
    There is a "~" symbol after double brackets.
    Does this means negation?
    If it is negation, there is no modification of String
    definition on the EBNF even though the body of string
    explanation is changed.
    But, I cannot find a "~" definition in the EBNF.
    In the unaryOperater definition of the EBNF on page6-48
    There is a "-".
    I think this is a "~" symbol.

  • Reported: OCL 2.0b1 — Fri, 9 Nov 2001 05:00 GMT
  • Disposition: Resolved — OCL 2.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:38 GMT

Downcast OCL collection operators

  • Key: OCL2-11
  • Legacy Issue Number: 4451
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    It is sometimes useful to downcast an OCL collection, for example
    when a generic function returns an OCL Collection, but a particular
    usage requires a Sequence. Unfortunately, the OCL operators
    asSet(), asSequence() and asBag(), are defined only for the
    concrete types, and not for their abstract common supertype
    Collection.

  • Reported: OCL 2.0b1 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — OCL 2.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:38 GMT

In 6.9 "Grammar for OCL" (Internationalization issues)

  • Key: OCL2-10
  • Legacy Issue Number: 4121
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    > In 6.9 "Grammar for OCL",
    > According to the current BNF grammar, we cannot use
    > multi-byte characters in class nor attribute names, because
    > name and string are composed of alpha-numeric letters only.
    > I think the definition of OCL should be modified for us
    > to be able to use multi-byte characters.
    > I show a draft of modification which will be proposed by
    > ISO/Japan National Body.(This will be discussed in UML1.3 PAS
    > at the next OMG/ISO Orlando meeting)
    >
    > typeName :=charForNameTop charForName*
    > name :=charForNameTop charForName*
    > charForNameTop := /* Characters except inhibitedChar
    > and ["0"-"9"]; the available
    > characters shall be determined by
    > the tool implementers ultimately.*/
    > charForName := /* Characters except inhibitedChar; the
    > available characters shall be determined
    > by the tool implementers ultimately.*/
    > inhibitedChar := " "|"\"|"#"|"\'"|"("|")"|"*"|"+"|","|"-"|
    > "."|"/"|":"|";"|"<"|"="|">"|"@"|"["|"
    "|
    > "]"|"

    {"|"|"|"}

    "

  • Reported: OCL 2.0b1 — Sat, 9 Dec 2000 05:00 GMT
  • Disposition: Resolved — OCL 2.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:38 GMT

OCL: Created and Destroyed instances

  • Key: OCL2-9
  • Legacy Issue Number: 4112
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Usually, the behaviour of an operation is described by pre and
    postconditions, and then shown in a collaboration diagram. In turn, in a
    collaboration diagram one can model (via the standard stereotypes create and
    destroy) the creation and destroying of instances, but this is not in the
    case in OCL. It would be useful to be able to explicitly model in a
    postcondition that an instance ocurring in the expression was created during
    the execution of the operation being specified. Since introducing a command
    is not possible, this feature could be achieved by just 'declaring' in the
    postcondition that the instance 'was created'.

    For example:

    context X::operation()
    post: self.attr = self.attr@pre->including(created p)

    this declares that p was created during the execution of operation, and it
    was not taken from elsewhere.

  • Reported: OCL 2.0b1 — Fri, 8 Dec 2000 05:00 GMT
  • Disposition: Resolved — OCL 2.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:38 GMT

context declaration for OCL invariants

  • Key: OCL2-8
  • Legacy Issue Number: 3855
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The second form of the context declaration for OCL invariants should be extended from

    context c : Class inv:

    to

    context c1,..,cn : Class inv:

    In similar situations, like the forAll and Exists operators, multiple iterators are allowed. So the above suggestion would increase uniformity. It also leads in some cases to simplified OCL expressions, e.g.

    context C inv C.allInstances->forAll(c1,c2 | c1.id = c2.id implies c1=c2)

    could be written as

    context c1,c2 : C inv c1.id = c2.id implies c1=c2

    Crossreference to issue #3139.

  • Reported: OCL 2.0b1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — OCL 2.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:38 GMT

postcondition for the operation round on the predefined OCL type

  • Key: OCL2-7
  • Legacy Issue Number: 3800
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The postcondition for the operation round on the predefined OCL type real reads

    ((r - result) < r).abs < 0.5) or ((r - result).abs = 0.5 and (result > r))

    This is incorrect and should be replaced by

    ((r - result).abs < 0.5) or ((r - result).abs = 0.5 and (result > r))

  • Reported: OCL 2.0b1 — Fri, 1 Sep 2000 04:00 GMT
  • Disposition: Resolved — OCL 2.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:38 GMT

Role 'collectionTypes' should be 'collectionType'

  • Key: OCL23-39
  • Legacy Issue Number: 13915
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    In Section 8.2.2, in Classifier well-formedness rules, 'collectionTypes' is used instead
    of 'collectionType'. This is not correct since in OCL, by convention, when not provided explicitly
    the name of an opposite role takes the name of the target class with first letter lowerized.

  • Reported: OCL 2.1 — Tue, 5 May 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:36 GMT

The property 'unspecified' can be removed from the metamodel

  • Key: OCL2_-92
  • Legacy Issue Number: 8821
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Because UnspecifiedValueExp is a special kind of OclExpression, it is not necessary to define an explicit unspecified property. One can check the type of the OclExpression to see whether we are in the unspecified situation. This also make useless the need to define a specific getType() helper operation for OclMessageArg since the type can direcly be obtained.

  • Reported: OCL 2.0b2 — Wed, 25 May 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Instanciation of collection types

  • Key: OCL2_-94
  • Legacy Issue Number: 8823
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    In 8.2 the sentence "Users will never instanciate these types explicitly" is not entirely true. When a OCL writer defines a helper operation that returns a set, he explicitly declares the Set to be returned. Also, according to the OCL metamodel, an expression always has a type (OclExpression::type has multiplicity equal to 1). So when using the metamodel to exchange OCL specifications (XMI exchange) this implies that all used types, including expressions yielding to collection types have to be instanciated for the XMI to be well-formed.

  • Reported: OCL 2.0b2 — Wed, 25 May 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

The metaclass 'OclMessageArg' can be removed from the metamodel

  • Key: OCL2_-93
  • Legacy Issue Number: 8822
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    A OclMessageExp can directly represent the arguments without the need of an intermediate class, just as OperationCallExp refer to its arguments

  • Reported: OCL 2.0b2 — Wed, 25 May 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

The composition associations in figure 9 are missing

  • Key: OCL2_-91
  • Legacy Issue Number: 8820
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    The composition associations in figure 9 are missing. In particular, a message
    expression (OclMessageExp) should contain its arguments, its target expression, are –probably – specified call action. Otherwise the model cannot be properly instanciated

  • Reported: OCL 2.0b2 — Wed, 25 May 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

The superclass of UnspecifiedValueExp is not ModelElement

  • Key: OCL2_-90
  • Legacy Issue Number: 8819
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    According to figure 9, the UnspecifiedValueExp does not inherits from OclExpression. However this is contradictory with the text description of the metaclass (and it own name).

  • Reported: OCL 2.0b2 — Wed, 25 May 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Reusing TypedElement for UnspecifiedValueExp

  • Key: OCL2_-89
  • Legacy Issue Number: 8818
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    The type property of UnspecifiedValueExp can be obtained from a superclass (for instance TypedElement or OclExpression

  • Reported: OCL 2.0b2 — Wed, 25 May 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

An UnlimitedNaturalExp should be added in the metamodel

  • Key: OCL2_-88
  • Legacy Issue Number: 8817
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    An UnlimitedNaturalExp should be added in the metamodel to be used to access upper bound values in multiplicity specifications. This will be conformant with UML2 primitive literals

  • Reported: OCL 2.0b2 — Wed, 25 May 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

The Ocl prefix should be avoided as much as possible in metaclass names

  • Key: OCL2_-87
  • Legacy Issue Number: 8816
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Except for the abstract OclExpression metaclass which differentiates from the UML class Expression, the other metaclasses OclMessageType, OclMessageExp and OclMessageArg should better be renamed MessageType, MessageExp and MessageArg to improve uniformity and readability of the metamodel.

  • Reported: OCL 2.0b2 — Wed, 25 May 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Should avoid using the OclHelper stereotype

  • Key: OCL2_-86
  • Legacy Issue Number: 8815
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Referring to the OclHelper stereotype in the well-formedness rules should be avoided since not strictly necessary. It should be possible yo use OCL in UML without using stereotypes

  • Reported: OCL 2.0b2 — Wed, 25 May 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Inconsistency in the way to represent Tuple literal part

  • Key: OCL2_-85
  • Legacy Issue Number: 8814
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    In the well-formedness rules there is a class named TupleLiteralExpPart but in the diagram VariableDeclaration is strangely used to represent the literal tuple parts.

  • Reported: OCL 2.0b2 — Wed, 25 May 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

The naming of the parts properties in literals is not consistent

  • Key: OCL2_-84
  • Legacy Issue Number: 8813
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    The naming to refer to the parts of tuple literals and collection literals should be uniformized. For tuples it is called 'tuplePart' and for collection literals it is called 'parts'. Also the CollectionLiteralExp::parts and TupleLiteralExp::tuplePart properties is only depicted in the diagrams (missing in the class descriptions)

  • Reported: OCL 2.0b2 — Wed, 25 May 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

The set of possible values of CollectionKind is missing

  • Key: OCL2_-83
  • Legacy Issue Number: 8812
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    The description of the CollectionKind should indicate the list of possible values

  • Reported: OCL 2.0b2 — Wed, 25 May 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Use a uniform convention to name multivalued properties

  • Key: OCL2_-82
  • Legacy Issue Number: 8811
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    In particular the properties NavigationCallExp::qualifiers, OperationCallEXp::arguments should be renamed NavigationCallExp::qualifier and OperationCallEXp::argument.

  • Reported: OCL 2.0b2 — Wed, 25 May 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

make link explicit

  • Key: OCL2_-79
  • Legacy Issue Number: 8794
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    The link between a variable representing a parameter and the parameter should be made explicit.

    The link between a variable and a parameter is currently not explicitly modelled in the OCL abstract syntax. It depends on name comparison. This adds unnecessary complexity to implementers.

  • Reported: OCL 2.0b2 — Wed, 18 May 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

The container for self and return variables is missing

  • Key: OCL2_-78
  • Legacy Issue Number: 8793
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    The OCL spec does not define who is the container of the 'self', the 'result' and other variables bound to the parameters of an operation. This makes the OCL instanciation incomplete and invalid.

  • Reported: OCL 2.0b2 — Wed, 18 May 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Inherited or non navigable properties should not appear in class descriptio

  • Key: OCL2_-81
  • Legacy Issue Number: 8810
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    In the association list of the OclExpression metaclass description, the 'appliedProperty', 'parentOperation' and 'initializedVariable' are non navigable and should be removed. In addition the 'type' property should be inherited from the UML2 metaclass TypedElement.

  • Reported: OCL 2.0b2 — Wed, 25 May 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Should compare the value of the slots and not the objects itself

  • Key: OCL2_-80
  • Legacy Issue Number: 8809
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    In the well-formedness rules of OclMessageType (section 8.2.2), the self.feature cannot be equal to the result of the asParameter() operation. The rule need to be rewritten so that the value of the slots are compared (the 'name' and 'type' instead of comparing the object themselves).

    A similar problem occurs in the well-formedness rule [2] of OclMessageType (section 8.2.2), the self.feature cannot be equal to the result of the 'referredSignal.feature' since in that case the referred features will be contained twice.

  • Reported: OCL 2.0b2 — Wed, 25 May 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

VariableDeclaration should be renamed Variable

  • Key: OCL2_-77
  • Legacy Issue Number: 8792
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    The concept representing a parameter declaration is not called ParameterDeclaration but Parameter. Similarily, the concept corresponding to variable declaration should be called Variable. Also this concept already exists in UML2 and the name chosen for the metaclass is Variable.

    Also the name property of the variable can be taken from the super class NamedElement instead of having a specific varName attribute.

  • Reported: OCL 2.0b2 — Wed, 18 May 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Specific inheritance links at M1 level should be removed

  • Key: OCL2_-76
  • Legacy Issue Number: 8791
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Figure 28 defines specific inheritance links between M1 types that are
    not inferred from M2 types. This links should be suppressed since it brings
    confusion and unnecessary complexity to the standard library
    definition. The particular compliance rules of OclVoid and OclAny can be defined independently of the "inheritance" formalism.

  • Reported: OCL 2.0b2 — Wed, 18 May 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

OclAny cannot be an instance of Classifier

  • Key: OCL2_-75
  • Legacy Issue Number: 8790
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Classifier is an abstract class. It is then not possible to define the OclAny of the standard library as a direct instance of classifier.

    Suggestion: Define a AnyType metatype

  • Reported: OCL 2.0b2 — Wed, 18 May 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Section: 11.9.2 reject

  • Key: OCL2_-74
  • Legacy Issue Number: 8664
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    On the left side of the equals symbol is the word "select" correct or should it be "iterate?"

  • Reported: OCL 2.0b2 — Wed, 30 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Section: 11.9.1 exists

  • Key: OCL2_-73
  • Legacy Issue Number: 8663
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Now it is too early in the morning because the statement "Results in true if body evaluates to true for at least one element in the source collection" does not make sense with the OCL notation on the right side of the equals symbol "source->iterate(iterators; result:Boolean = false | result or body)." One says true, the other says false.

  • Reported: OCL 2.0b2 — Wed, 30 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Section: 11.7.2

  • Key: OCL2_-72
  • Legacy Issue Number: 8662
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    It's late in the day but I do not see that the OCL definition for union(s:Set(T)): Set(T) is totally accurate because it does not mention that self and s cannot contain the same element or the union of self and s would be a bag not a set. I am also confused by the last post for bothe asSequenced(): Sequence(T) and asBag(): Bag(T) where the result->count(elem)=1. Should this be result->count(elem)>=1 in both cases because you're writing about sequences and bags?

  • Reported: OCL 2.0b2 — Tue, 29 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

’StringValue.iterators

  • Key: OCL2_-71
  • Legacy Issue Number: 7547
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    39. The association between ’StringValue.iterators’ and ’LoopExpEval’ should be ordered on the side
    of ’StringValue.iterators’.

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

context Classifier

  • Key: OCL2_-70
  • Legacy Issue Number: 7499
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    def: lookupAttribute(attName : String) : Attribute =
    self.allAttributes->any(me | me.name = attName)
    def: lookupAssociationEnd(name : String) : AssociationEnd =
    self.allAssociationEnds->any (ae | ae.name = name)
    def: lookupAssociationClass(name : String) : AssociationClass =
    self.allAssociationClasses->any (ae | ae.name = name)
    def: lookupOperation (name: String, paramTypes: Sequence(Classifier)):
    Operation =
    self.allOperations->any (op | op.name = name and
    op.hasMatchingSignature(paramTypes))
    def: lookupSignal (sigName: String, paramTypes: Sequence(Classifier)):
    Operation =
    self.allReceptions.signal->any (sig | sig.name = sigName and
    sig.hasMatchingSignature(paramTypes))
    ==> all references to operations like allAttributes are missing brackets, and the returnType of lookup-
    Signal should be Signal. The whole expression should be:
    context Classifier
    def: lookupAttribute(attName : String) : Attribute =
    self.allAttributes()->any(me | me.name = attName)
    def: lookupAssociationEnd(name : String) : AssociationEnd =
    self.allAssociationEnds()->any (ae | ae.name = name)
    def: lookupAssociationClass(name : String) : AssociationClass =
    self.allAssociationClasses()->any (ae | ae.name = name)
    def: lookupOperation (name: String, paramTypes: Sequence(Classifier)):
    Operation =
    self.allOperations()->any (op | op.name = name and
    op.hasMatchingSignature(paramTypes))
    def: lookupSignal (sigName: String, paramTypes: Sequence(Classifier)):
    Signal =
    self.allReceptions().signal->any (sig | sig.name = sigName and
    sig.hasMatchingSignature(paramTypes))

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

context TTupleType::...

  • Key: OCL2_-69
  • Legacy Issue Number: 7498
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    30. context TTupleType::make(atts : Sequence(UML14::Core::Attribute) ) : TTupleType
    post: result.features = atts
    post: result.stereotype.name = ’OclHelper’
    ==> should be: context TTupleType::make(atts : OrderedSet(UML14::Core::Attribute) ) :
    TTupleType
    post: result.feature = atts
    post: result.stereotype.name = ’OclHelper’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

referredOperation

  • Key: OCL2_-68
  • Legacy Issue Number: 7497
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    29. – [2] The parameters of the referredOperation become attributes of the instance
    – of OclMessageType
    context OclMessageType
    inv: referredOperation->size() = 1 implies
    self.feature = referredOperation.parameter.asAttribute()
    ==> ’parameter’ should be Parameter
    ==> ’.asAttribute()’ should be ’->collect(p | p.asAttribute().oclAsType(UML14::Core::Feature) ).asOrderedSet()’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

"Bag"

  • Key: OCL2_-67
  • Legacy Issue Number: 7496
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    28. – [1] The name of a bag type is "Bag" followed by the element type’s name in
    – parentheses.
    context BagType
    inv: self.name = ’Bag(’ + self.elementType.name + ’)’
    [1] The name of a collection type is "Collection" followed by the element
    – type’s name in parentheses.
    context CollectionType
    inv: self.name = ’Collection(’ + self.elementType.name + ’)’
    [1] The name of a set type is "OrderedSet" followed by the element type’s name
    – in parentheses.
    context OrderedSetType
    inv: self.name = ’OrderedSet(’ + self.elementType.name + ’)’
    [1] The name of a sequence type is "Sequence" followed by the element type’s
    – name in parentheses.
    context SequenceType
    inv: self.name = ’Sequence(’ + self.elementType.name + ’)’
    [1] The name of a set type is "Set" followed by the element type’s name in
    – parentheses. context SetType
    inv: self.name = ’Set(’ + self.elementType.name + ’)’
    ==> ’’ should be replaced by ’concat’ or ’’ should be allowed as concrete syntax for the String concat
    operation.
    inv: self.name = ’Bag(’.concat( self.elementType.name).concat(’)’)
    inv: self.name = ’Collection(’.concat(
    self.elementType.name).concat(’)’)
    inv: self.name = ’OrderedSet(’.concat(
    self.elementType.name).concat(’)’)
    inv: self.name = ’Sequence(’.concat( self.elementType.name).concat(’)’)
    inv: self.name = ’Set(’.concat( self.elementType.name).concat(’)’)

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

context TTupleType::make(atts : sequence(Attribute) ) : TTupleType

  • Key: OCL2_-66
  • Legacy Issue Number: 7495
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    27. context TTupleType::make(atts : sequence(Attribute) ) : TTupleType
    post: result.features = atts
    post: result.stereotype.name = ’OclHelper’ ==> ’sequence(Attribute)’ should be ’Sequence(UML14::Core::Attribute)’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

type of a TupleLiteralExp

  • Key: OCL2_-65
  • Legacy Issue Number: 7494
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    26. – [1] The type of a TupleLiteralExp is a TupleType with the specified parts.
    context TupleLiteralExp
    inv: type.oclIsKindOf (OclAbstractSyntax::Types::TTupleType)
    and
    tuplePart->forAll (tlep |
    type.allAttributes()->exists (tp | tlep.attribute = tp))
    and
    tuplePart->size() = type.allAttributes()->size()
    ==> should be
    context TupleLiteralExp
    inv: type.oclIsKindOf (OclAbstractSyntax::Types::TTupleType)
    and
    tuplePart->forAll (tlep |
    type.allAttributes()->exists (tp | tlep.asAttribute().name = tp.name and
    tlep.asAttribute().type = tp.type and
    tlep.asAttribute().initExpression = tp.initExpression))
    and
    tuplePart->size() = type.allAttributes()->size()

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

type of a TupleLiteralExp

  • Key: OCL2_-62
  • Legacy Issue Number: 7491
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    23. – [1] The type of a TupleLiteralExp is a TupleType with the specified parts.
    context TupleLiteralExp
    inv: type.oclIsKindOf (TupleType) and
    tuplePart->forAll (tlep |
    type.oclAsType (TupleType).allAttributes()->exists (tp | tlep.attribute
    = tp))
    and
    tuplePart->size() = type.oclAsType (TupleType).allAttributes()->size()
    ==> should be:
    context TupleLiteralExp
    inv: type.oclIsKindOf (OclAbstractSyntax::Types::TTupleType)
    and
    tuplePart->forAll (tlep |
    type.allAttributes()->exists (tp | tlep.asAttribute().name = tp.name and
    tlep.asAttribute().type = tp.type and
    tlep.asAttribute().initExpression = tp.initExpression))
    and
    tuplePart->size() = type.allAttributes()->size()

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

The type of the attribute is the type of the value expression.

  • Key: OCL2_-64
  • Legacy Issue Number: 7493
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    25. – [1] The type of the attribute is the type of the value expression.
    context TupleLiteralExpPart
    inv: attribute.type = value.type
    ==> should be removed, the type ’TupleLiteralExpPart’ does not exist.

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

tuple literal expression

  • Key: OCL2_-63
  • Legacy Issue Number: 7492
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    24. – [2] All tuple literal expression parts of one tuple literal expression have
    – unique names.
    context TupleLiteralExp
    inv: tuplePart->isUnique (attribute.name)
    ==> should be:
    context TupleLiteralExp
    inv: tuplePart->isUnique (name)

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

message is a send action,

  • Key: OCL2_-61
  • Legacy Issue Number: 7490
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    22. – [2] If the message is a send action, the arguments must conform to the
    – attributes of the signal.
    context OclMessageExp
    inv: sentSignal->notEmpty() implies
    arguments->forAll (a | a.getType().conformsTo
    (self.sentSignal.signal.feature.oclAsType(StructuralFeature)
    >at (arguments>indexOf (a)).type))
    ==> should be:
    context OclMessageExp
    inv: sentSignal->notEmpty() implies
    arguments->forAll (a | a.getType().conformsTo
    (self.sentSignal.signal.feature
    >at (arguments>indexOf
    (a)).oclAsType(UML14::Core::StructuralFeature).type) )

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    Discussion:
    This well-formed rule is correct in the current OCL 2.0 specification. It is a duplicate of the issue 7471.
    Disposition: See Issue 7471 for disposition

  • Updated: Sun, 8 Mar 2015 13:35 GMT

message is a call action,

  • Key: OCL2_-60
  • Legacy Issue Number: 7489
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    21. – [1] If the message is a call action, the arguments must conform to the
    – parameters of the operation.
    context OclMessageExp
    inv: calledOperation->notEmpty() implies
    arguments->forAll (a | a.getType().conformsTo
    (self.calledOperation.operation.Parameter->
    select( kind = UML14::Core::ParameterDirectionKind::In )
    >at (arguments>indexOf (a)).type))

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

’parameter’ should be ’Parameter’

  • Key: OCL2_-59
  • Legacy Issue Number: 7488
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    20. – [1] If the message is a call action, the arguments must conform to the
    – parameters of the operation.
    context OclMessageExp
    inv: calledOperation->notEmpty() implies
    arguments->forAll (a | a.getType().conformsTo
    (self.calledOperation.operation.parameter->
    select( kind = ParameterDirectionKind::In )
    >at (arguments>indexOf (a)).type))
    ==> ’parameter’ should be ’Parameter’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

the property ’refParams’ is not present in OperationCallExp

  • Key: OCL2_-58
  • Legacy Issue Number: 7487
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    ==> add the following:
    context OperationCallExp
    def: refParams: Sequence(UML14::Core::Parameter) =
    self.referredOperation.Parameter->asSequence()
    ==> see also number 21.

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

forall’ should be ’forAll’

  • Key: OCL2_-57
  • Legacy Issue Number: 7486
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    18. – [1] All the arguments must conform to the parameters of the referred operation
    context OperationCallExp
    inv: arguments->forall (a | a.type.conformsTo
    (self.refParams->at (arguments->indexOf (a)).type))
    ==> ’forall’ should be ’forAll’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

attributes of the signal.

  • Key: OCL2_-54
  • Legacy Issue Number: 7483
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    15. – [2] If the message is a send action, the arguments must conform to the
    – attributes of the signal.
    context OclMessageExp
    inv: sentSignal->notEmpty() implies
    arguments->forall (a | a.getType().conformsTo
    (self.sentSignal.signal.feature.oclAsType(StructuralFeature)
    >at (arguments>indexOf (a)).type))
    ==> ’forall’ should be ’forAll’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

parameters of the operation.

  • Key: OCL2_-53
  • Legacy Issue Number: 7482
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    14. – [1] If the message is a call action, the arguments must conform to the
    – parameters of the operation.
    context OclMessageExp
    inv: calledOperation->notEmpty() implies
    arguments->forall (a | a.getType().conformsTo
    (self.calledOperation.operation.parameter->
    select( kind = ParameterDirectionKind::In )
    >at (arguments>indexOf (a)).type))
    ==> ’forall’ should be ’forAll’

  • Reported: OCL 2.0b2 — Mon, 14 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

5] The target of an OCL message cannot be a collection.

  • Key: OCL2_-56
  • Legacy Issue Number: 7485
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    context OclMessageExp
    inv: not target.type.oclIsKindOf (CollectionType)
    ==> ’CollectionType should be ’OclAbstractSyntax::Types::CollectionType’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

’sentMessage’ should be ’sentSignal’

  • Key: OCL2_-55
  • Legacy Issue Number: 7484
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    16. – [4] An OCL message has either a called operation or a sent signal.
    context OclMessageExp
    inv: calledOperation->size() + sentMessage->size() = 1
    ==> ’sentMessage’ should be ’sentSignal’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

The type of the condition of an if expression must be Boolean.

  • Key: OCL2_-48
  • Legacy Issue Number: 7477
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    context IfExp
    inv: self.condition.type.oclIsKindOf(Primitive) and
    self.condition.type.name =
    ’Boolean’
    ==> ’Primitive’ should be ’UML14::Core::Primitive’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

result type

  • Key: OCL2_-50
  • Legacy Issue Number: 7479
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    [2] The result type of the collect operation on a sequence type is a sequence,
    – the result type of ’collect’ on any other collection type is a Bag. The type
    – of the body is always the type of the elements in the return collection.
    context IteratorExp
    inv: name = ’collect’ implies
    if source.type.oclIsKindOf(SequenceType) then
    type =
    expression.type.collectionType->select(oclIsTypeOf(SequenceType))-
    >first()
    else
    type = expression.type.collectionType->select(oclIsTypeOf(BagType))-
    >first()
    endif
    ==> should be
    context IteratorExp
    inv: name = ’collect’ implies if source.type.oclIsKindOf(OclAbstractSyntax::Types::SequenceType) then
    self.type = StandardLibrary::StdLib::Sequence
    and
    self.Body.type = Body.type
    else
    self.type = StandardLibrary::StdLib::Bag
    and
    self.Body.type = Body.type
    endif

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

iterator

  • Key: OCL2_-49
  • Legacy Issue Number: 7478
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    [1] If the iterator is ’forAll’, ’isUnique’, or ’exists’ the type of the
    – iterator must be Boolean.
    context IteratorExp
    inv: name = ’exists’ or name = ’forAll’ or name = ’isUnique’
    implies type.oclIsKindOf(Primitive) and type.name = ’Boolean’
    ==> ’Primitive’ should be ’UML14::Core::Primitive’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

type of each iterator var. must be type of the elements of source collectio

  • Key: OCL2_-52
  • Legacy Issue Number: 7481
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    context IteratorExp
    inv: self.iterators->forAll(type = source.type.oclAsType
    (CollectionType).elementType)
    ==> ’CollectionType should be ’OclAbstractSyntax::Types::CollectionType’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

1] The type of the source expression must be a collection.

  • Key: OCL2_-51
  • Legacy Issue Number: 7480
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    context LoopExp
    inv: source.type.oclIsKindOf (CollectionType)
    ==> ’CollectionType should be ’OclAbstractSyntax::Types::CollectionType’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

collection literal expression

  • Key: OCL2_-47
  • Legacy Issue Number: 7476
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    [2] The type of a collection literal expression is determined by the
    – collection kind selection and the common supertype of all elements. Note that
    – the definition below implicitly states that empty collections have OclVoid as
    – their elementType.
    context CollectionLiteralExp
    inv: kind = CollectionKind::Set implies type.oclIsKindOf (SetType )
    inv: kind = CollectionKind::Sequence implies type.oclIsKindOf (SequenceType)
    inv: kind = CollectionKind::Bag implies type.oclIsKindOf (BagType )
    inv: type.oclAsType (CollectionType).elementType = parts->iterate (p; c
    :
    Classifier = OclVoid | c.commonSuperType (p.type))
    ==> should be
    context CollectionLiteralExp
    inv: kind = CollectionKind::Set implies type =
    StandardLibrary::StdLib::Set
    inv: kind = CollectionKind::OrderedSet implies type =
    StandardLibrary::StdLib::OrderedSet
    inv: kind = CollectionKind::Sequence implies type =
    StandardLibrary::StdLib::Sequence
    inv: kind = CollectionKind::Bag implies type =
    StandardLibrary::StdLib::Bag
    inv: type.oclAsType
    (OclAbstractSyntax::Types::CollectionType).elementType =
    parts->iterate (p; c :
    Classifier = StandardLibrary::StdLib::OclVoid | c.commonSuperType
    (p.type))

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

7. context AttrubuteCallExp

  • Key: OCL2_-46
  • Legacy Issue Number: 7475
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    inv: type = referredAttribute.type
    ==> ’AttrubuteCallExp’ should be ’AttributeCallExp’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

context TupleType::make(atts : sequence(Attribute) ) : TupleType

  • Key: OCL2_-45
  • Legacy Issue Number: 7474
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    post: result.features = atts
    post: result.stereotype.name = ’OclHelper’
    ==> ’sequence’ should be ’OrderedSet’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

In section 3.3.9

  • Key: OCL2_-44
  • Legacy Issue Number: 7473
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    5. In section 3.3.9 the operations "OclExpression::withAtPre() : OperationCallExp" and "OclExpression::
    withAsSet() : OperationCallExp" should be prefixed with the keyword ’context’.

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

context Operation

  • Key: OCL2_-43
  • Legacy Issue Number: 7472
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    context Operation
    def: hasMatchingSignature(paramTypes: Sequence(Classifier)) : Boolean =
    – check that operation op has a signature that matches the given
    parameter lists
    = let sigParamTypes: Sequence(Classifier) = self.allAttributes.type in
    (
    ( sigParamTypes->size() = paramTypes->size() ) and
    ( Set

    {1..paramTypes->size()}

    ->forAll ( i |
    paramTypes->at .conformsTo (sigParamTypes->at )
    )
    )
    )
    ==> remove the ’=’ after Boolean
    ==> same error occurs in "context Signal def: hasMatchingSignature...."

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

If message is a send action, arguments must conform to attributes of signal

  • Key: OCL2_-42
  • Legacy Issue Number: 7471
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    context OclMessageExp
    inv: sentSignal->notEmpty() implies
    arguments->forall (a | a.getType().conformsTo
    (self.sentSignal.signal.feature.oclAsType(StructuralFeature) )
    >at (arguments>indexOf (a)).type))
    ==> should be:
    context OclMessageExp
    inv: sentSignal->notEmpty() implies
    arguments->forAll (a | a.getType().conformsTo
    (self.sentSignal.signal.feature
    >at (arguments>indexOf
    (a)).oclAsType(UML14::Core::StructuralFeature).type) )

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

The type of body expression must conform to declared type of result variabl

  • Key: OCL2_-41
  • Legacy Issue Number: 7470
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    context IterateExp
    Body.type.conformsTo(result.type)
    ==> missing ’inv:’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    This typo has already been corrected in the last OCL 2.0 release.

    Disposition: Close, no change

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Errors in the abstract syntax chapter 1. -- [1] Integer conforms to real.

  • Key: OCL2_-40
  • Legacy Issue Number: 7469
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    context Primitive
    inv: (self.name = ’Integer’) implies
    Primitive.allInstances()->forAll (p | (p.name = ’Real’) implies
    (self.conformsTo(p))))
    ==> one closing bracket ’)’ too many

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

The classifier name TupleType is also a reserved word

  • Key: OCL2_-39
  • Legacy Issue Number: 7468
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    The classifier name TupleType is also a reserved word. In order to check the constraints we have
    changed it into TTupleType.

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

change rollnames

  • Key: OCL2_-38
  • Legacy Issue Number: 7467
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    1. The keywords ’pre’, ’body’, ’in’ and ’context’ are being used in the OCL expressions themselves to
    indicate role names. Actually this is an error. These can be avoided by changing the following
    rolenames:
    • - ’body’ of AbstractSyntax::Expression::LoopExp
    • - ’pre’ of OclDomain::Values::LocalSnapshot
    • - ’context’ of OclDomain::Evaluations::OclExpEval
    • - ’in’ of AbstractSyntax::Expression::LetExp
    • - ’in’of UML14::Core::ParameterDirectionKind
    To check the expressions we have changed the above names into the same word beginning with an
    upperclass character.

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

OclMessageArg metaclass that is currently defined, could be removed.

  • Key: OCL2_-37
  • Legacy Issue Number: 7465
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    11. The OclMessageArg metaclass that is currently defined, could be removed. We propose the configuration
    depicted in figure 1, together with the following constraints. Note that a similar set of constraint
    must be added to chapter "The Use of Ocl Expressions in UML Models", depending on the
    exact alignment with the UML metamodel. Also note that both the first and second constraint of
    OclMessageExp on page 54 of the final adopted spec need to be changed: "arguments->forAll( a |
    a.getType() ...." should be "arguments->forAll( a | a.type ....".
    – an unspecified value expression may not have an applied property
    context UnspecifiedValueExp
    10 June 2004,
    page 2 of 22
    Klasse Objecten
    © Copyright Klasse Objecten
    inv: self.appliedProperty->isEmpty()
    – an unspecified value expression may not be used anywhere but as
    – argument to an OclMessageExp
    context OclExpression
    inv: not appliedProperty.oclIsTypeOf(UnspecifiedValueExp)
    context LoopExp
    inv: not body.oclIsTypeOf(UnspecifiedValueExp)
    context VariableDeclaration
    inv: not initExpression.oclIsTypeOf(UnspecifiedValueExp)
    context LoopExp
    inv: iterators->forAll(i | not i.oclIsTypeOf(UnspecifiedValueExp))
    context IterateExp
    inv: not result.oclIsTypeOf(UnspecifiedValueExp)
    context OperationCallExp
    inv: arguments->forAll( i | not i.oclIsTypeOf(UnspecifiedValueExp))
    context NavigationCallExp
    inv: qualifiers->forAll( i | not i.oclIsTypeOf(UnspecifiedValueExp))
    context IfExp
    inv: not thenExpression.oclIsTypeOf(UnspecifiedValueExp)
    context IfExp
    inv: not elseExpression.oclIsTypeOf(UnspecifiedValueExp)
    context IfExp
    inv: not condition.oclIsTypeOf(UnspecifiedValueExp)
    context LetExp
    inv: not in.oclIsTypeOf(UnspecifiedValueExp)

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

tostring operation for Integer, Real and Boolean

  • Key: OCL2_-36
  • Legacy Issue Number: 7464
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    It would be convenient to have a tostring operation for Integer, Real and Boolean.

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

plus (infix) operator (’+’)

  • Key: OCL2_-35
  • Legacy Issue Number: 7463
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    9. It would be very convenient to allow the plus (infix) operator (’+’) as concrete syntax for the String
    concat.

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

flatten operation

  • Key: OCL2_-34
  • Legacy Issue Number: 7462
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    It is not clear from the specification whether the flatten operation is meant to be a deep or a shallow
    flatten. We prefer a deep flatten, but perhaps both options should be available.

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

result of applying the collect operation to a Sequence

  • Key: OCL2_-30
  • Legacy Issue Number: 7458
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    The result of applying the collect operation to a Sequence should be a Sequence, not a Bag. Likewise,
    the result of applying the collect operation to an OrderedSet should be a Sequence, not a Bag.

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Remove the composition symbol at the end of PropertyCallExp

  • Key: OCL2_-29
  • Legacy Issue Number: 7456
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    Remove the composition symbol at the end of PropertyCallExp in the association between Property-
    CallExp (rolename appliedProperty) and OclExpression (rolename source). This should be a normal
    association.
    Composition implies lifetime dependency, therefore this use of composition is incorrect. An OclExpression
    exists independent of its (optional) applied property and they have no lifetime dependency.

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

There should be an OclTypeLiteralExp metaclass

  • Key: OCL2_-33
  • Legacy Issue Number: 7461
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    There should be an OclTypeLiteralExp metaclass, subtype of LiteralExp. It should have an association
    with UML::Classifier.

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

There should be an OclTypeLiteralExp metaclass

  • Key: OCL2_-32
  • Legacy Issue Number: 7460
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    There should be an OclStateLiteralExp metaclass, subtype of LiteralExp. It should have an association
    with UML::State.

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

There should be an OclUndefinedLiteralExp metaclass

  • Key: OCL2_-31
  • Legacy Issue Number: 7459
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    There should be an OclUndefinedLiteralExp metaclass, subtype of PrimitiveLiteralExp. The type of
    its instances should always be OclVoid.

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

section 7.4.6 (Re-typing or casting) on p.13

  • Key: OCL2_-28
  • Legacy Issue Number: 7341
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    In section 7.4.6 (Re-typing or casting) on p.13, it is stated that "An object can only be re-typed to one of its subtypes". In other words, in the expression object.oclAsType(A), A must be a subtype of the type of the object. However, in section 7.5.8 (Accessing overridden properties of supertypes) on p.20 an example is given of object.oclAsType(A), where A is a supertype of object. This contradicts the assertion made earlier. In section 11.2.4 there are no constraints given on oclAsType that would rule out the usage shown in the second paragraph. However, in the semantics section on p.A-25 it is only stated that for oclAsType, the the target type must be a subtype of the source type or vice versa, supporting again the usage in the second paragraph. Judging from these, I assume that the restriction given on p.13 is incorrect.

  • Reported: OCL 2.0b2 — Sun, 16 May 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    Type-casting is more general than the set of known subtypes and supertypes. If the OCL type system can be considered as open (meaning that OCL expressions may be applied to objects of types not known in the context in which it was defined), then it must be permitted to attempt a cast to any other type. UML implements multiple inheritance, so that given any two types, it is always a possibility that an object could be classified by both, even if they do not apparently have any relationship. This is particularly important for constraints defined in type libraries.

    Because OCL provides type tests oclIsKindOf() and oclIsTypeOf(), it is reasonable that failure to cast result in invalid to indicate an error condition. Note that a type-testing expression such as self.oclAsType(SomeType).oclIsInvalid() is correct, though it may be considered as poor style.

    The effect of casting is only a parse-time re-typing to provide visibility of features not defined for the original type, and a run-time assertion of the required type of an object. It cannot change the type of an object or coerce an object to an instance of a different type, nor can it provide access to hidden or overidden features of a supertype. For this, a new syntax is required that statically indicates the definition of a feature by the classifier that defines it.

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Use the "null" keyword instead of verbose "OclUndefined".

  • Key: OCL2_-27
  • Legacy Issue Number: 6888
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Use the "null" keyword instead of verbose "OclUndefined".

  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

What's a collection?

  • Key: OCL2_-26
  • Legacy Issue Number: 6633
  • Status: closed  
  • Source: HL7 ( Grahame Grieve)
  • Summary:

    OCL 2 does not clarify what makes a type a collection. It's clear that
    any multiple attributes and associations are collections. And from
    section 3.2, it's clear that parameterised classes may be treated as
    OCL collections. However not all parameterised classes can be treated
    as collections

    This needs further clarification

  • Reported: OCL 2.0b2 — Thu, 20 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Keywords "attr" and "oper"?

  • Key: OCL2_-25
  • Legacy Issue Number: 6615
  • Status: closed  
  • Source: Modeling Value Group ( Wim Bast)
  • Summary:

    Keywords "attr" and "oper" still necessary? Keywords attr and oper are defined in the keywords list, but are not included in the concrete grammar. Are they maybe superfluous? If "attr" is really a keyword, then the well-formedness rule on page 140 that uses a local variable attr must use another variable name.

  • Reported: OCL 2.0b2 — Thu, 13 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Formal Semantics of OCL 2.0 in Appendix A

  • Key: OCL2_-24
  • Legacy Issue Number: 6612
  • Status: closed  
  • Source: Modeling Value Group ( Wim Bast)
  • Summary:

    Maybe the completion of the formal semantics of OCL is an issue that is too extensive as part of the finalization process of OCL 2.0. Therefore, I suggest to just add a note in Appendix A concerning the currently still missing parts of the formal semantics, i.e., in particular OCL Messages, Ordered Set, and def-clauses. If you want you can refer to my paper about the Formal Semantics of OCL Messages, presented at the OCL Workshop at UML 2003. It can currently be found at http://i11www.ira.uka.de/~baar/oclworkshopUml03/papers/05_formal_semantics_ocl_messages.pdf

  • Reported: OCL 2.0b2 — Thu, 13 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

OclUndefined = OclUndefine ?

  • Key: OCL2_-23
  • Legacy Issue Number: 6611
  • Status: closed  
  • Source: Modeling Value Group ( Wim Bast)
  • Summary:

    Perhaps it makes sense to explicitly mention whether OclUndefined = OclUndefined results in OclUndefined (or true)? The SQL equivalent seems to cause a lot of confusion, especially since in C "NULL == NULL" resturns true. For example, the above expression would not work with excluding(OclUndefined), given (OclUndefined=OclUndefined).isOclUndefined().....

  • Reported: OCL 2.0b2 — Thu, 13 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    Technically, no change is necessary because the OclAny definition of the = operation, together with the definition of the singleton values null and invalid, is sufficient. However, being more explicit is helpful, especially as the there is no oclIsXyz() operation testing for void but not invalid.

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Enumeration approach for reflection

  • Key: OCL2_-22
  • Legacy Issue Number: 6610
  • Status: closed  
  • Source: Modeling Value Group ( Wim Bast)
  • Summary:
    • I think the enumeration approach to reflection leads to a dead end. Why not leave that out for now and add full access to the user model in OCL2.1, when the other UML parts have stabilized. I think it would be quite straightforward to simply copy the relevant properties and operations from Classifier/Class to OclType.
  • Reported: OCL 2.0b2 — Thu, 13 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Issue: OclModelElement

  • Key: OCL2_-21
  • Legacy Issue Number: 6570
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: The object OclModelElement object should be removed from the standard library, while OclModelElementType should remain in OCL type hierarchy.
    Rationale: It implies a useless level of wrapping for the model objects.

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Issue: OclType

  • Key: OCL2_-20
  • Legacy Issue Number: 6569
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: OclType should disappear from the OCL type hierarchy.
    Rationale: OclType should be only present in the standard library to support values for the type expression used in functions like oclAsType(), oclIsKindOf(), and oclIsTypeOf().

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Issue: oclIUndefined() versus isEmpty()

  • Key: OCL2_-19
  • Legacy Issue Number: 6568
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: OCL offers two choices to test if a value is undefined or not: isEmpty and oclIsUndefined.
    Rationale: Most of the modern programming languages contain null values. The best OCL mapping for null value is the undefined value. Using isEmpty to test if a value is null/undefined is some how confusing:

    • the result of property->isEmpty() must be true if the value of the property is null/undefined
    • the result of Set {1/0}

      ->isEmpty() must be false
      because the expression property->isEmpty() is converted according to the OCL specification to Set

      {property}

      ->empty()
      These situations are a source of errors and confusion at the implementation level. I think that isEmpty() should be used only to test if a collection is empty or not; the null/undefined values should be tested using ocIslUndefined. This operation should be also valid on collections. This approach will also work nice and clear for nested collections. On the other hand I don't think that () should not be optional if the called operation has no arguments. This is feature specific to old languages like TAL and Pascal, while in modern languages like C, C++ the meaning of f and f() is different.

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Issue: Attributes and Association Ends versus Properties

  • Key: OCL2_-18
  • Legacy Issue Number: 6567
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: The submission uses the terms of Attributes and Association Ends, which are no longer used in UML 2.0.
    Rationale: In order to align OCL 2.0 and UML 2.0 specifications I think that the expression package should look like: I also think that the OCL grammar should be rewritten accordingly

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Issue: Operator precedence

  • Key: OCL2_-17
  • Legacy Issue Number: 6564
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: Section 4.3.2 does not specify precedence for operators like div, mod, ^^, or ^.
    Rationale: The operator precedence must be as precise as possible in order to provide a platform-independent implementation. I think that logical operators should be organized on different levels of precedence:
    'not'
    'and'
    'or'
    'xor'
    'implies'

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    See issue 6544 for disposition

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Issue: Keywords

  • Key: OCL2_-16
  • Legacy Issue Number: 6562
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: OCL 2.0 uses keywords (e.g. and, or, xor, implies etc.) that cannot be used elsewhere.
    Rationale: This means that these names cannot be used to identify properties, classes or packages. There are two options to solve this problem: either UML 2.0 specifies the names that cannot be used or the OCL concept of keywords has to be revised.

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Issue: Set of characters

  • Key: OCL2_-15
  • Legacy Issue Number: 6560
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: The OCL 2.0 specification should describe the set of characters allowed in the OCL constructions (e.g. Unicode or ASCII).
    Rationale: This will help implementers to solve another ambiguity and to produce portable implementations. Unicode will be in my opinion the best choice.

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Issue: General section to define OCL concepts

  • Key: OCL2_-14
  • Legacy Issue Number: 6558
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: The specification should contain an introductory section containing definitions of the terms used in the specification and other notations that are used (e.g. well-formed expression, ill-formed expression, behaviour, undefined-behaviour etc.).
    Rationale: This will avoid ambiguities and provide a better specification of the OCL (see specifications for C++, Java, and C#).

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Reintroduce allAttributes operator

  • Key: OCL2_-13
  • Legacy Issue Number: 6556
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Herman Balsters (h.balsters@bdk.rug.nl)
    Description: Reintroduce allAttributes operator
    Rationale:
    In pre-OCL 2.0 versions, there was an operator called "allAttributes": this operator (to be applied to class objects) returns the set of attributes of that object. (This operator should also be applicable to tuples as well, by the way.) Now the strange thing has happened that this most useful operator has vanished in OCL 2.0 I propose that it be re-introduced.

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Missing equality and inequality operations on collection types

  • Key: OCL2_-12
  • Legacy Issue Number: 6555
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Hubert Baumeister (baumeist@informatik.uni-muenchen.de),
    Rolf Hennicker (hennicke@informatik.uni-muenchen.de),
    Alexander Knapp (knapp@informatik.uni-muenchen.de)
    Description: Missing equality and inequality operations on collection types
    Rationale:
    The collection types Set, Sequence, and Bag show a predefined = operation. However, this operation is not defined for the abstract type Collection.
    Moreover, the operation <> is missing for all collection types.

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Clarify definition of collectNested for Set, Bag, and Sequence

  • Key: OCL2_-11
  • Legacy Issue Number: 6552
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Hubert Baumeister (baumeist@informatik.uni-muenchen.de),
    Rolf Hennicker (hennicke@informatik.uni-muenchen.de),
    Alexander Knapp (knapp@informatik.uni-muenchen.de)
    Description: Clarify definition of collectNested for Set, Bag, and Sequence
    Rationale:
    For Set, Bag, and Sequence the definition of collectNested (page 6-17ff.) actually defines collect which should read collectNested.
    As a minor detail, the definition of collectNested seems to be the only one using iterators as iterator variable. This should be aligned with select, reject, etc.

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Undefined values, isEmpty() and Collections

  • Key: OCL2_-10
  • Legacy Issue Number: 6546
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Octavian Patrascoiu (O.Patrascoiu@kent.ac.uk)
    Description: Most of the modern OO languages support null values, but OCL does not. In order to map null values into OCL concepts we used the undefined value. Unfortunately, OCL offers two choices to test if a value is undefined or not: isEmpty and oclIsUndefined. Using isEmpty for such a purpose is some how confusing:
    the result of property->isEmpty() must be true if the value of the property null/undefined
    the result of Set

    {1/0, 1/0}

    ->isEmpty() must be false
    These situations are a source of errors and confusion at the implementation level. I think that isEmpty() should be used only to test if a collection is empty or not; the undefined values should be tested using ocIslUndefined. This operation should be also valid on collections. This approach will also work nice and clear for nested collections.

  • Reported: OCL 2.0b2 — Mon, 10 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    The submitter’s assertion about appropriate usage of oclIsUndefined() and isEmpty() is a matter of style. OCL does support null values, even in collections, so that a collection containing a single element that is null is not empty. The isEmpty() operation applied to scalar values that are null is an inevitable consequence of the coercion of scalars to sets. It is reasonable that a scalar null is coerced to an empty set while a non-null scalar is coerced to a non-empty set. Moreover, oclIsUndefined() is true not only for null, but also for invalid, which is not permitted in collections.

    Disposition: Closed, no change

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Flagging recursive definitions

  • Key: OCL2_-7
  • Legacy Issue Number: 6543
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Jörn Guy Süß (jgsuess@cs.tu-berlin.de)
    Description: Interpreter to warn of recursive definitions
    Rationale:
    While recursive definitions are necessary to express certain constructs, they may lack a fixpoint. Specification should require implementations to provide either an occurs check or structured time-out/stack-trace to handle these situations.

  • Reported: OCL 2.0b2 — Mon, 10 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Attributes and Association Ends versus Properties

  • Key: OCL2_-9
  • Legacy Issue Number: 6545
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Octavian Patrascoiu (O.Patrascoiu@kent.ac.uk)
    Description: The submission uses the terms of Attributes and Association Ends, which are no longer used in UML 2.0. In order to align OCL 2.0 and UML 2.0 specifications I think that the expression package should look like:

    I also think that the OCL grammar should be rewritten accordingly.

  • Reported: OCL 2.0b2 — Mon, 10 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Operator precedence

  • Key: OCL2_-8
  • Legacy Issue Number: 6544
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Octavian Patrascoiu (O.Patrascoiu@kent.ac.uk)
    Description: Logical operators 'and', 'or', and 'xor' have the same precedence, which in my opinion is not natural. I think that the precedence of these operators should be from highest to lowest as follows:

    'and'
    'or'
    'xor'

    Also, the precedence of some useful operators like 'div', 'mod', '', and '^', is not specified in section 4.3.2.

  • Reported: OCL 2.0b2 — Mon, 10 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Consider OclType as a powertype

  • Key: OCL2_-4
  • Legacy Issue Number: 6532
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: OclType is currently a subtype of OclAny and seen as an enumeration type. This leads to some drawbacks w.r.t. the specification of operations like oclAsType(), oclIsKindOf(), and oclIsTypeOf(), that need to reason about type conformance. As this cannot be done without accessing the metalevel, OclType should rather be considered as a powertype (cf. OCL Workshop paper at UML 2003: S.Flake, OclType - A Type or Metatype?).

  • Reported: OCL 2.0b2 — Mon, 10 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Flagging insecure cast from Set to Sequence

  • Key: OCL2_-6
  • Legacy Issue Number: 6542
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Jörn Guy Süß (jgsuess@cs.tu-berlin.de)
    Description: Interpreter to warn of nondeterministic cast
    Rationale:
    If an OCL expression contains a cast from Set to Sequence types, nondeterminism is introduced through the order of the new sequence. Either such casts should be disallowed, or the specification should require that implementations give feedback that nondeterministic behavior is to be expected

  • Reported: OCL 2.0b2 — Mon, 10 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

domain for library operations /, div

  • Key: OCL2_-5
  • Legacy Issue Number: 6537
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Thomas Baar (thomas.baar@epfl.ch)
    Description: clarify, whether x/0 is undefined
    Rationale: On page 6/6, 6-7 the semantics of operation / is decribed informally as 'The value of self divided by r (respective i).' It remains unclear what self / 0 evaluates to.
    On page 6/7 the div-operation is specified in terms of /-operation, however with a pre-condition pre: i <> 0.
    Why is div handled differently from / ?

  • Reported: OCL 2.0b2 — Mon, 10 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Omit predefined type OclModelElement.

  • Key: OCL2_-3
  • Legacy Issue Number: 6531
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: OclModelElement is currently defined in the OCL Standard Library. It can simply be omitted, as it is actually never used. OclModelElementType, however, must remain in the metamodel, e.g., for the mapping of OclState.

  • Reported: OCL 2.0b2 — Mon, 10 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

oclIsNew for a collection

  • Key: OCL2_-2
  • Legacy Issue Number: 6529
  • Status: closed  
  • Source: Ecole Polytechnique Federale de Lausanne ( Alfred Strohmeier)
  • Summary:

    Description: Provide an operation for creating a collection of new objects
    Rationale:
    Consider the case where you want to create a new smartcard for a set of persons. Any solution is currently longwinded. It would be nice to be able to have an operation oclIsNew that applies to a collection (or perhaps only to a Set), and states the number of objects to be created, e.g.:
    let: s: Set(SmartCards) in s.oclIsNew(self.person->size())...

  • Reported: OCL 2.0b2 — Mon, 10 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    closed no change

  • Updated: Sun, 8 Mar 2015 13:35 GMT

OCL 2.0/international character sets

  • Key: OCL2_-1
  • Legacy Issue Number: 6393
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    The OCL 2.0 FAS makes several references to ASCII (pg. 22), lowercase and uppercase characters (pg. 33-34) that violate the requirement for allowing international character sets to be used with UML. This is unacceptable since it limits the use of UML.

  • Reported: OCL 2.0b2 — Thu, 30 Oct 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:35 GMT

Problems with OCL definition of Package::makesVisible

  • Key: OCL24-13
  • Legacy Issue Number: 18965
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Nearly a year ago we put the UML OCL through Eclipse OCL and were able to eliminate 'all' (many hundreds of) syntactic errors and many semantic errors. Not all semantic errors, because Eclipse OCL is steadily adding stronger WFRs. Since then the authors have been using Eclipse OCL in the guise of IBM RSA and the errors have stayed away. Final checks of the UML 2.5 candidate UML.xmi identified only one semantic error.

    Your report is marginal as a semantic error; perhaps a warning would be appropriate for the useless compare. I suspect an inadequacy in the Eclipse OCL determination of the application OCLAny::= specialization.

    Realistically UML 2.5 paves the way for the start of a virtuous circle as feedback identifies the outright functional errors that occur when validating real models and the much harder inadequacies where the constraints are too weak.

  • Reported: OCL 2.3.1 — Thu, 26 Sep 2013 04:00 GMT
  • Disposition: Resolved — OCL 2.4
  • Disposition Summary:

    issue already raised in the UML 2.6 RTF

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Section: A/2.3 Enumeration Types

  • Key: OCL21-353
  • Legacy Issue Number: 12457
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This may be simply my misunderstanding of what is intended. In the final sentence before Definition A.18 (Semantics of Enumeration Types), the word "interpreted" seems inappropriate. "Defined" is often used in such sentences is mathematics. I just wanted to draw attention to this in case it is a mistake. If not then my apologies

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    issue withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Section 6.6.2

  • Key: OCL2-6
  • Legacy Issue Number: 5581
  • Status: closed  
  • Source: Capital One Bank (Europe) plc ( Matt Staples)
  • Summary:

    Section 6.6.2

    In the paragraph after the OCL sample should the word "reject" be "collect" instead?

  • Reported: UML 1.4 — Tue, 20 Aug 2002 04:00 GMT
  • Disposition: Resolved — OCL 2.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:40 GMT

OCL 2.1 12 Typos

  • Key: OCL23-19
  • Legacy Issue Number: 14597
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    12.12 para 3 "OCl" for "OCL".

    12.8 para 1 last sentence, 12.9 para 1 last sentence; both are unreadable.

    12.12.2 No [B] rule

    12.12.1/12.12.2 contextDeclCS/contextDeclarationCS

  • Reported: OCL 2.1 — Sat, 31 Oct 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    The OCl typo is fixed in OCL 2.3.
    The grammar typos are easily fixed.
    While making the multiplicity statements readable, we can make one small step towards aligning OCL with UML 2.x properties.

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

OCL 2.1 12.2.3 Incomplete resolution of Issue 9796 for attrOrAssocContextCS

  • Key: OCL23-18
  • Legacy Issue Number: 14587
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    When Issue 9796 updated terminology to use PropertyCallExpCS, attrOrAssocContextCS should have been updated to propertyContextCS.

  • Reported: OCL 2.1 — Wed, 28 Oct 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    In 12.12.2 contextDeclarationCS replace
    [A] contextDeclarationCS ::= attrOrAssocContextCS
    by
    [A] contextDeclarationCS ::= propertyContextDeclCS
    Replace
    12.12.3 attrOrAssocContextCS
    This production rule represents a context declaration for expressions that can be coupled to an attribute or
    association end. The path name refers to the “owner” of the attribute or association end, the simple name
    refers to its name, the type states its type.
    attrOrAssocContextCS ::= ‘context’ pathNameCS ‘::’ simpleName’:’ typeCS initOrDerValueCS
    by
    12.12.3 propertyContextDeclCS
    This production rule represents a context declaration for expressions that can be coupled to a property. The
    path name refers to the “owner” of the property, the simple name refers to its name, the type states its type.
    propertyContextDeclCS ::= ‘context’ pathNameCS ‘::’ simpleName’:’ typeCS initOrDerValueCS

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

OCL 2.1 11.2 Conflicting {OclVoid, OclInvalid}::{oclIsTypeOf, oclIsKindOf, oclAsType} semantics

  • Key: OCL23-26
  • Legacy Issue Number: 14985
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    11.2.3 states clearly that "Any property call applied on null results in OclInvalid, except for the operations oclIsUndefined() and oclIsInvalid()." This is being revised by Issue 14197 in OCL 2.3 to: "Any property call applied on OclVoid results in invalid, except for the operations oclIsUndefined(), oclIsInvalid(), =(OclAny) and <>(OclAny)."

    11.2.4 states clearly that "Any property call applied on invalid results in OclInvalid, except for the operations oclIsUndefined() and oclIsInvalid()." This is being revised by Issue 14197 in OCL 2.3 to: "Any property call applied on OclInvalid results in invalid, except for the operations oclIsUndefined() and oclIsInvalid()."

    Therefore invalid.oclIsTypeOf(OclInvalid) => invalid and null.oclIsTypeOf(OclVoid) => invalid.

    But the above are widely used in the specification as for example:

    "oclIsUndefined() : Boolean
    Evaluates to true if the self is equal to OclInvalid or equal to null.
    post: result = self.isTypeOf( OclVoid ) or self.isTypeOf(OclInvalid)"

    clearly expecting isTypeOf (a typo) to return true/false, not invalid sometimes.

    Issue 14197 relaxed the OclVoid property list to allow = and <>. Perhaps all oclXXX operations should have an explicitly defined semantics for OclVoid and OclInvalid, supporting rather than denying reflective usage of the values as in self.isTypeOf( OclVoid ).

  • Reported: OCL 2.2 — Sun, 17 Jan 2010 05:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    Merged with Issue 18437.
    Disposition: See issue 18437 for disposition

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

OCL 2.1 Implicit Conversion to Collection Literal

  • Key: OCL23-25
  • Legacy Issue Number: 14981
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The specification is very vague as to how and when a non-collection is converted to a collection.

    11.2.3 states that 'If the source is the null literal, it is implicitly converted to Bag{}'.

    7.5.3 states that 'Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set.'

    The collection type inconsistency between Bag{} and Set

    {x}

    makes compile-time type resolution difficult, since the null-ness of x cannot be known till run-time. It would be better to have either Set or Bag uniformly as the conversion collection type. Bag{} as the least useful seems more appropriate.

    When a conversion is applicable is unclear.

    In the example, self.manager->isEmpty() is intended to be interpreted as

    if self.manager.isUndefined() then Set{} else Set

    {self.manager}

    endif->isEmpty()

    so that null->isEmpty is also valid.

    However is

    null->excludesAll(null)

    equivalent to

    Bag{}->excludesAll(Bag{})

    and so true?

    A simple policy of 'wherever a collection is required and a non-collection is provided perform an implicit conversion to collection-literal' resolves this.

    However are

    null = Bag{}

    or

    Bag{} = null

    both equivalent to

    Bag{} = Bag{}

    and so true?

    In this case we have a problem of asymmetric overloading.

    null = Bag{} satisfies the signature for OclVoid::=(OclAny) and so returns false.

    Bag{} = null could satisfy the signature for Bag::=(Bag) and so return true with the help of an implicit conversion.

    Presumably an additional OclVoid::=(Collection) overload is needed to restore symmetry.

  • Reported: OCL 2.2 — Sun, 17 Jan 2010 05:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    Resolved by Issue 15009, where the explicit synthesis of oclAsSet() avoids the troublesome conversions above.
    Disposition: See issue 15009 for disposition

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

String.equalsIgnoreCase(String) should result in Boolean

  • Key: OCL23-29
  • Legacy Issue Number: 15134
  • Status: closed  
  • Source: Microsoft ( Len Charest)
  • Summary:

    OCL 2.2 defines equalsIgnoreCase as returning an Integer. Given that the operation determines equivalence of two Strings, I would expect it to return Boolean: either the strings are equivalent (true) or they are not (false).

  • Reported: OCL 2.2 — Wed, 17 Mar 2010 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

OCL 2.1 11.2.3 Navigated Implicit Conversion to Collection Literal

  • Key: OCL23-28
  • Legacy Issue Number: 15009
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The Issue 14981 considered use of explicit null as a Collection.

    11.2.3 states that 'If the source is the null literal, it is implicitly converted to Bag{}'.

    Surely when the null arises as a navigation result, the isOrdered and isUnique characteristics of the navigated property should determine what CollectionKind the null result is converted to?

    However meta-modelling tools and meta-modellers pay little attention to the isUnique and isOrdered characteristics of zero and unit multiplicity properties. Using this overlooked information may cause surprises.

  • Reported: OCL 2.2 — Fri, 29 Jan 2010 05:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    7.6.3 Navigation over Associations with Multiplicity Zero or One suggests non-collection are converted to Sets. Similarly 7.6.5, 9.7. So there is a contradiction in the normative conversion to Set or Bag. Set seems more sensible and what the non-normative clauses suggest.
    Using the accidental ordered/unique attributes of non-collections would lead to horrible surprises for existing usage, so it must be conversion to a set.
    Since the conversion of null yields an empty set, whereas any other object yields a single element set, the Set size is data dependent and so must be determined at run-time and cannot be expressed as a CollectionLiteralExp. Rather, evaluation of PropertyCallExp and OperationCallExp must detect a mismatch between a non-collection source type and a collection-type referredOperation class.
    Delayed resolution is inconsistent with OCL's static typing, so let us make it explicit by defining OclAny::oclAsSet() for the static analysis to invoke and perform the conversion. The conversion is represented as a regular OperationCallExp in the AST and only type-dependent run-time decisions need to be made.
    Note that the revisions below do not address the deficiencies in the normative Clause 9 text raised by Issue 15790. We continue to rely on the final sentence of 9.7: "The mapping is not formally defined in this document but should be obvious."

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

OCL 2.1 11.2.5 Numeric = and <> operations should compare values rather than objects

  • Key: OCL23-24
  • Legacy Issue Number: 14918
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    OCLAny::=() is defined as 'True if self is the same object as object2.'

    This is not overloaded for numeric types, and it is not specified that a numeric value may not have multiple instances.

    The definition therefore implies that:

    1 = 1

    may often evaluate to false, and that

    1.0 = 1

    must evaluate to false even though (1.0 <= 1) and (1.0 >= 1) will evaluate true

    Suggest overload

    {Boolean, Real, String}

    ::

    {=,<>}

    to use values rather than objects.

  • Reported: OCL 2.2 — Sat, 2 Jan 2010 05:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    The use of object should be clarified so that
    Class instances are compared by object identity.
    DataType instances are compared by value.
    This resolution overlaps with null/invalid clarification and so the change below includes changes for Issue 18437.

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

OCL 2.1 8.3.8 OclInvalid::allInstances

  • Key: OCL23-27
  • Legacy Issue Number: 15005
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    8.3.8 states that in regard to allInstances

    "returns all instances of the classifier and the classifiers specializing it. May only be used for classifiers that have a finite
    number of instances. This is the case, for example, for user defined classes because instances need to be created explicitly,
    and for enumerations, the standard Boolean type, and other special types such as OclVoid and OclInvalid."

    While it is true that OclInvalid has exactly one instance, the corresponding return of Set

    {invalid}

    is not well-formed.

    Therefore the invocation OclInvalid.allInstances() must return invalid.

    Suggest:

    Replace "and OclInvalid" by ". But not for OclInvalid, for which the return is invalid"

  • Reported: OCL 2.2 — Mon, 25 Jan 2010 05:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

wrong variable name

  • Key: OCL23-23
  • Legacy Issue Number: 14886
  • Status: closed  
  • Source: Universidad Nacional del Litoral ( Javier Godoy)
  • Summary:

    subclause [10])

    It reads: let foundElement ... in result = if foundAttribute ... else foundElement ...

    (foundAttribute is undefined, I understand it means to "foundElement")

  • Reported: OCL 2.1 — Sat, 19 Dec 2009 05:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    simple typo

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

Undefined operation tail() on p 130

  • Key: OCL23-22
  • Legacy Issue Number: 14883
  • Status: closed  
  • Source: Universidad Nacional del Litoral ( Javier Godoy)
  • Summary:

    Related to Issue 7539)

    It reads: isOclKind

    It should read: oclIsKindOf

    Rationale: per section 7.5.9 the operation name is "oclIsKindOf"

  • Reported: OCL 2.1 — Sat, 19 Dec 2009 05:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    This typo is addressed by Issue 14882
    Disposition: Merged

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

OCL 2.1 12.2.5 named-self classifierContextDeclCS

  • Key: OCL23-17
  • Legacy Issue Number: 14586
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The second half of 7.3.3 uses a named-self syntax that is missing from 12.2.5.

    context c : Company inv:
    c.numberOfEmployees > 50

  • Reported: OCL 2.1 — Wed, 28 Oct 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    In 12.12.2 classifierContextDeclCS replace
    This production rule represents a context declaration for expressions that can be coupled to classifiers.
    classifierContextDeclCS ::= ‘context’ pathNameCS invOrDefCS
    by
    This production rule represents a context declaration for expressions that can be coupled to classifiers. The
    variable declaration to the classifier context is 'self' for the A form and explicitly specified for the B form.
    [A] classifierContextDeclCS ::= ‘context’ pathNameCS invOrDefCS
    [B] classifierContextDeclCS ::= ‘context’ simpleNameCS ':' pathNameCS invOrDefCS

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

Undefined operation tail()

  • Key: OCL23-21
  • Legacy Issue Number: 14882
  • Status: closed  
  • Source: Universidad Nacional del Litoral ( Javier Godoy)
  • Summary:

    (Related to Issue 7539)

    It reads: isOclKind

    It should read: oclIsKindOf

    Rationale: per section 7.5.9 the operation name is "oclIsKindOf"

  • Reported: OCL 2.1 — Sat, 19 Dec 2009 05:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

Undefined operation tail()

  • Key: OCL23-20
  • Legacy Issue Number: 14881
  • Status: closed  
  • Source: Universidad Nacional del Litoral ( Javier Godoy)
  • Summary:

    subclause [4]

    It reads: names->tail()

    It should read:
    names->subSequence(2, names.size())

    Rationale: tail() is not an operation of Sequence

  • Reported: OCL 2.1 — Sat, 19 Dec 2009 05:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

The t should be subscripted next to the equal sign

  • Key: OCL231-36
  • Legacy Issue Number: 16306
  • Status: closed  
  • Source: CumuloCogitus Inc. ( Dominic Roy)
  • Summary:

    At the top of the page, there is a formula to define the equal operator. The formula begins with I(=t). That t should be subscripted as we see in the sentence that precedes the formula.

  • Reported: OCL 2.3 — Wed, 1 Jun 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    The original report against OCL 2.3 A.2.2 has migrated to A.4.2 in OCL 2.3.1.

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

Comparison operators don't exist for Boolean

  • Key: OCL231-35
  • Legacy Issue Number: 16305
  • Status: closed  
  • Source: CumuloCogitus Inc. ( Dominic Roy)
  • Summary:

    In the table A.1 (Schema for operations on basic types), the operations

    {<, >, <, >}

    are defined as applicable to

    {UnlimitedNatural, Integer, Real, String, Boolean}

    .
    While the result is certainly Boolean, the parameters can't be Boolean in general, unless UML defined such operators for Booleans. According to section 11.5.4, there is no definition for the operators. Then Boolean should be removed in the set.

  • Reported: OCL 2.3 — Wed, 1 Jun 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    No Data Available

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

Issue nnnn: Japan PAS Ballot Comment 9 (ocl2-rtf) Section 7.4.8

  • Key: OCL231-14
  • Legacy Issue Number: 16132
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Whereas there are some infix operator definitions in later document, this list of infix operators isn’t described sufficient. For example, there is ‘>’ definition on 7.6.1. However, ‘>’ is not included in this list. Additionally, ‘=’ is defined on 11.6.1, 11.6.2, 11.6.4, 11.6.5. However, there isn’t ‘=’ on this list. By the way. ‘=’ is not defined for Integer, and Real. Is that no problem? Furthermore, “implies” definition could not be found. Add infix operator sufficiently. And, clarify the operator definition.

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Not much of a title.
    Section 7.5.8 is not normative so it is not necessary to enumerate every infix operator.
    None of the logical operators, and, or, xor, implies are listed.
    The "->" and "." tokens occur between their arguments and so could be regarded as infix, however navigation operators are not normally regarded as infix operators and so listing them would be more confusing than omitting them.
    In most languages, "=" is not an infix operator, however in OCL it is, so omitting it when all other operators with punctuation spelling are listed is indeed a bit confusing.
    (The punctuation of the list is dreadful.)
    Issue 15009 introduces a missing section on "->" and "." operators.
    Issue 14918 revises the definition of OclAny::= to be sensible for DataTypes.
    implies is defined in 11.5.4

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

Issue nnnn: Japan PAS Ballot Comment 8 (ocl2-rtf) Section 10.3.2 OperationCallExpEval P127

  • Key: OCL231-13
  • Legacy Issue Number: 16131
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    It is difficult to understand which “latter” indicates. Make clear which “latter” implies.

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Initial Comment: Make clear which “latter” implies.

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

Japan PAS Ballot Comment 24 (ocl2-rtf) 10.1 Introduction

  • Key: OCL231-22
  • Legacy Issue Number: 16147
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    1st paragraph: Single quote does not close in two places:
    ’The Expressions Package
    ’The Types Package
    Complete the quote like the following.
    ’The Expressions Package’
    ’The Types Package’

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Initial Comment:
    Complete the quote like the following.
    ’The Expressions Package’
    ’The Types Package’
    Comment: Close as Fixed by OCL 2.3
    Disposition: Closed

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

Japan PAS Ballot Comment 23 (ocl2-rtf) 10 Semantics Described Using UML

  • Key: OCL231-21
  • Legacy Issue Number: 16146
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Main text. References like [Kleppe2001] and [Clark2000] are not appropriate in the main text of International Standards. Modify the text as appropriate

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Initial Comment/Suggestion: Modify the text as appropriate.
    Comment: The explicit academic referenced may remain in the informative bibliography but
    should not remain in the core document of the specification

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

Japan PAS Ballot Comment 18 (ocl2-rtf)

  • Key: OCL231-19
  • Legacy Issue Number: 16141
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Section 9.3.18 BooleanLiteralExpCS, 9.3.19 CallExpCS, 9.3.24 TypeCS,, 9.3.37 OclMessageExpCS, 9.3.39 For instance in case of 9.3.18, numbered list are shown like below.
    [2] [A] BooleanLiteralExpCS ::= ‘true’
    [3] [B] BooleanLiteralExpCS ::= ‘false’”
    The numbering are not consistent with others.
    PROPOSED RESOLUTION: For instance, replace
    [2] [A] BooleanLiteralExpCS ::= ‘true’
    [3] [B] BooleanLiteralExpCS ::= ‘false’”
    with
    [A] BooleanLiteralExpCS ::= ‘true’
    [B] BooleanLiteralExpCS ::= ‘false’”.
    Apply the same type of modifications to all identified clauses.

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Initial Comment:
    For instance, replace
    [2] [A] BooleanLiteralExpCS ::= ‘true’
    [3] [B] BooleanLiteralExpCS ::= ‘false’”
    with
    [A] BooleanLiteralExpCS ::= ‘true’
    [B] BooleanLiteralExpCS ::= ‘false’”.
    Apply the same type of modifications to all identified clauses.
    Comment: Close as Fixed by OCL 2.3

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

Japan PAS Ballot Comment 17 (ocl2-rtf) Section 9.3.4 simpleNameCS

  • Key: OCL231-18
  • Legacy Issue Number: 16140
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Abstract syntax mapping and Synthesized attributes
    (two places)
    Reference” simpleNameGr” is incorrect, Replace this with simpleNameCS

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Initial comment: Replace this with simpleNameCS.
    Comment: Close as Fixed by OCL 2.3
    Disposition: Closed

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

Issue nnnn: Japan PAS Ballot Comment 7 (ocl2-rtf) Section 7.4.5 table 7.3

  • Key: OCL231-12
  • Legacy Issue Number: 16130
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Table 7.3 doesn’t understand easily, because “condition” column doesn’t give sufficient explanation. Write more explicit explanation

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    The condition is an extra rule which must be satisfied in order to say that the type in the first
    column conforms to the type in the second column. An extra sentence to explain that will be
    provided. Besides, the UnlimitedNatural condition looks like an explanation rather than a
    condition. So this explanation will be rather located below the table.

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

Issue nnnn: Japan PAS Ballot Comment 6 (ocl2-rtf)

  • Key: OCL231-11
  • Legacy Issue Number: 16129
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    There are same element names in both OCL and UML. Those are confusing. I wonder whether those are UML elements or OCL elements. Besides, it seems there is no clear distinction between UML/OCL (upper case letter) term and general term (lower case letter), since these are used in mixture.

    • It is confusing to distinguish OCL “Constraint” from UML “Constraint” in the text. Furthermore, there are some “constraint” s (in a lower case letter). The lower case letter/upper case letters for “constraint” are mixed.
      OCL “Constraint” should be distinguishable from UML “Constrain”.
  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Not much of a title.
    There are many element names that are the reused in UML; presumably class names were meant. I think that these are all distinct and not confusing to me. No convincing example is given. The example of a Constraint is where UML and OCL overlap so it is obviously the same class.
    Spelling is separately raised as Issue 16126 so there is no need to address it here as well.
    Disposition: Closed, no change

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

Issue from PAS Ballot comment for ISO/IEC DIS 19507 Section 9.3.29 OperationCallExpCS

  • Key: OCL231-20
  • Legacy Issue Number: 16142
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Synthesized attributes, [B] The if-then-else-endif indentation of “The referred operation” part is not appropriate. Replace that part with the list below this table (Listing#1).

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Initial Comment/Suggestion: Replace that part with the list below this table (Listing#1).

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

Issue nnnn: Japan PAS Ballot Comment 10 (ocl2-rtf) Section 7.4.9 list of keywords

  • Key: OCL231-15
  • Legacy Issue Number: 16133
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    As keywords, it is necessary to include “forAll”, “exists”, “any”, “one”, collect”, “select”, “reject” etc., since there are definitions for these on p161 and other clause. This key word list is insufficient. Add “forAll”, “exists”, “any”, “one”, “collect”, “select”, “reject”.

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    No Data Available

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

Japan PAS Ballot Comment 16 (ocl2-rtf) - Section 9.3.3 VariableExpCS

  • Key: OCL231-17
  • Legacy Issue Number: 16139
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Disambiguating rules. [1] [1] is redundant. Replace this with [1].

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Initial comment: Replace this with [1].
    Comment: Close as Fixed by OCL 2.3
    Disposition: Closed

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

Issue nnnn: Japan PAS Ballot Comment 11 (ocl2-rtf) p 35 line 1

  • Key: OCL231-16
  • Legacy Issue Number: 16134
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Typo. "This clause describes teh abstract syntax ...""This clause describes the abstract syntax ..."

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Closed as Fixed by OCL 2.3
    Disposition: Closed

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

OCL 2.0, 2.1 Loop iterators are not ordered and other inconsistencies

  • Key: OCL23-5
  • Legacy Issue Number: 14198
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The iterators of LoopExp and LoopExpEval are not ordered, but the well-formedness constraints on them use ->at() which is only available for ordered collection. Usage of the AST property is subject to a variety of spelling, ordering and multiplicity inconsistencies.

    Section 7.6.3 and 7.6.4 define extended variants of forAll and exists that have two iterators.

    Figure 8.2 and Figure 13.3 show an unordered * multiplicity for LoopExp.iterator. The positioning of the VariableExp.referredVariable 0..1 multiplicity makes the diagram easy to mis-read.

    Section 8.3.1 LoopExp defines iterator as "The iterator variables. These variables are, each in its turn, " implying an ordered collection.

    Section 8.3.7 LoopExp [2] and [3] use iterator->forAll implying a collection.

    Section 9.3 IteratorExpCS synthesized attributes use iterators->at(1) and at(2) requiring an ordered collection.

    Section 9.3 IterateExpCS concrete syntax supports at most one iterator and one accumulator.

    Section 9.3 IterateExpCS synthesized attributes use iterator.initExpression requiring a non-collection.

    Figure 10.7 shows LoopExpEval.iterators as unordered 1..n.

    Section 10.3.1 LoopExpEval defines iterators as "The names of the iterator variables".

    Section 10.3.7 IterateExpEval [1] uses iterators->at(1) and iterators->at(2) implying an ordered collection with upper bound 2.

    Section 10.3.7 LoopExpEval [1] has a two way if = 1 else, implying the upper bound is 2.

    Section 10.3.7 LoopExpEval [3] uses iterators->at(1) and iterators->at(2) implying an ordered collection with upper bound 2.

    Section 11.9.1 defines the mapping of forAll to iterate for multiple iterators, but IterateExpCS only supports a single iterator.

  • Reported: OCL 2.1 — Sat, 22 Aug 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    Revised Text:
    In Figure 8.2 and Figure 13.3 change LoopExp.iterator from 0..1 to 1..2

    {ordered}.
    In Figure 8.2 and Figure 13.3 reposition the VariableExp.referredVariable multiplicity to avoid confusion.

    In Figure 10.7 change LoopExpEval.iterators from 1..n to 1..2 {ordered}

    .

    In Section 8.3.1 LoopExp iterator replace
    The iterator variables
    by
    The ordered set of one or two iterator variables.

    In Section 9.3 IteratorExpCS replace
    IteratorExpCS.ast.iterators->size() = 1
    else
    IteratorExpCS.ast.iterators->at(2).name = VariableDeclarationCS[2].ast.name
    and
    IteratorExpCS.ast.iterators->at(2).type =
    ...
    [A] IteratorExpCS.ast.iterators->forAll(initExpression->isEmpty())
    ...
    [C, D] IteratorExpCS.ast.iterator.type =
    ...
    body.source.oclAsType (VariableExp).referredVariable = IteratorExpCS.ast.iterator
    by
    IteratorExpCS.ast.iterator->size() = 1
    else
    IteratorExpCS.ast.iterator->at(2).name = VariableDeclarationCS[2].ast.name
    and
    IteratorExpCS.ast.iterator->at(2).type =
    ...
    [A] IteratorExpCS.ast.iterator->forAll(initExpression->isEmpty())
    ...
    [C, D] IteratorExpCS.ast.iterator->at(1).type =
    ...
    body.source.oclAsType (VariableExp).referredVariable = IteratorExpCS.ast.iterator->at(1)

    In Section 9.3 IterateExpCS replace
    IterateExpCS.ast.iterator.name = if VariableDeclarationCS[1]->isEmpty() then ‘’
    ...
    IterateExpCS.ast.iterator.type =
    ...
    IterateExpCS.ast.iterator.initExpression->isEmpty()
    by
    IterateExpCS.ast.iterator->at(1).name = if VariableDeclarationCS[1]->isEmpty() then ‘’
    ...
    IterateExpCS.ast.iterator->at(1).type =
    ...
    IterateExpCS.ast.iterator->at(1).initExpression->isEmpty()

    In Section 10.3.1 LoopExpEval iterators replace
    The names of the iterator variables in the loop expression
    by
    The ordered set of names of the one or two iterator variables in the loop expression.

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

OCL 2.0, 2.1 inconsistent definition of null and invalid

  • Key: OCL23-4
  • Legacy Issue Number: 14197
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The attached surprisingly large set of revised text recommendations endeavours to resolve every inconsistent use of invalid and null/void types and the failure to update the specification when undefined was split into null and invalid. The recommendations also correct many conversion errors that crept in when Word Processor formats were changed. Once these changes are incorporated, a very careful proof read against at least Annex A of 03-01-07 should be performed.

    The initial discussion identifies that the approved resolutions of Issues: 6611, 10433, 10434, 12349, 12378, 12484 and 12485 are at best deficient

  • Reported: OCL 2.1 — Sat, 22 Aug 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

OCL 2.1 7.4.7 Inconsistent Operator Associativity and Precedence

  • Key: OCL23-13
  • Legacy Issue Number: 14582
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Issue 11098 resolved the missing precedence of let-in as lowest. This requires "2 * let a:Integer=1 in a + 1" to be interpreted as "(2 * (let a:Integer=1 in a)) + 1" making use of a non-trivial let body surprising and needlessly complicated. The problem with the open-ended right hand side can be resolved by assigning let-in the highest atomic expression precedence and defining its resolution as right-associative. The above example then has the obvious meaning "2 * (let a:Integer=1 in (a + 1))".

    Issue 6544 introduces ^ and ^^ at higher precedence than . and ->. However since these operators can only return left hand arguments for each other, there is no need to assign these to different levels.

    if-then-else-endif has an intermediate precedence in OCL 2.1. Since this term has keywords at start and end, the term is equivalent to an atomic expression. In so far as precedence is meaningful it is a high precedence.

    Parentheses should be bulletted at high precedence.

    Non commutative operators such as / have no defined order of evaluation leaving the value of "8 / 4 / 2" undefined. Binary operators should be specified as left-associative; i.e "(8 / 4) / 2".

    Section 9.3.2 duplicates 7.4.7.

  • Reported: OCL 2.1 — Tue, 27 Oct 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

OCL 2.1 Resolution of missing Concrete Syntaxes and Reserved Words

  • Key: OCL23-12
  • Legacy Issue Number: 14357
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Define the concrete syntax of a simpleNameCS to avoid punctuation collisions, support Unicode characters, and add a double quoted form with escape sequences for awkward names.

    Define the concrete syntax of a StringLiteralExpCS to support escape sequences for awkward characters.

    Define the concrete syntax of RealLiteralExpCS and IntegerLiteralExpCS.

    Define a variety of effectively reserved words such as true, self, Bag, String as reserved.

  • Reported: OCL 2.1 — Thu, 10 Sep 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

Missing specification of UnlimitedNatural

  • Key: OCL23-3
  • Legacy Issue Number: 14196
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The specification of the UnlimitedNatural type is largely missing and often trivially inconsistent.

  • Reported: OCL 2.1 — Sat, 22 Aug 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    see pages 24 - 35 of OMG document ptc/2010-12-01

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

Erroneous operation names 'isOclType' and 'asOclType'

  • Key: OCL23-2
  • Legacy Issue Number: 14094
  • Status: closed  
  • Source: Open Canarias, SL ( Victor Sanchez)
  • Summary:

    Erroneous operation names 'isOclType' and 'asOclType'. The operation 'isOclType' appears four times throughout the document. I presume it refers to 'oclIsTypeOf'. The operation 'asOclType' appears six times throughout the document. I presume it refers to 'oclAsType'.

  • Reported: OCL 2.1 — Sat, 25 Jul 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

[OCL-2.1 RTF] Transitive closure operator


OCL 2.1 7.4.9 true, self, Bag and String are not reserved words

  • Key: OCL23-14
  • Legacy Issue Number: 14583
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    [Splitting a major issue off from a number of minor issues in 14357, so that the resolutions do not get confused.]

    Define a variety of effectively reserved words such as true, self, Bag, String as reserved.

    Define which Complete OCL reserved words are Essential OCL reserved words.

  • Reported: OCL 2.1 — Tue, 27 Oct 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

Inconsistent lookup for underscored symbols

  • Key: OCL23-9
  • Legacy Issue Number: 14224
  • Status: closed  
  • Source: Individual ( Alexander Igdalov)
  • Summary:

    Description:

    9.3 Concrete Syntax
    As a convention to the concrete syntax, conflicting properties or conflicting class names can be aliased using the «» (underscore) prefix. Inside an OCL expression that is written with the concrete syntax, when a property name or a class name is found to start with a «›, firstly the symbol is lookup in the metamodel. If not found, the same symbol with the «_» skipped is tried.

    Should be

    As a convention to the concrete syntax, conflicting properties or conflicting class names can be aliased using the «» (underscore) prefix. Inside an OCL expression that is written with the concrete syntax, when a property name or a class name is found to start with a «», the symbol with the «_» skipped is looked up in the metamodel.

    Explanation: Consider that some class in the metamodel has two properties called '_self' and 'self' correspondingly. With the resolution rule defined in 9.3 one can never access 'self' property. On one hand, you cannot refer to it directly because it clashed the keyword self. One the other hand, '_self' would refer to '_self' property according to 9.3. Thus, both variants 'aClass.self' and 'aClass._self' are not helpful here.

  • Reported: OCL 2.1 — Thu, 27 Aug 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    Discussion:
    Issue 14357 introduces a new underscore-prefix string syntax (_'self') to access awkward
    spellings. This solves the problem of accessing either _'self' or _'_self'.

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

OCL 2.1 Inconsistent implementation of Issue 6532 and contradictory resolution of Issues 7341 and 10437

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

    Issue 7341 resolved that a bad oclAsType in 7.4.6 should return invalid.

    Issue 10437 resolved that the revised text for bad oclAsType in 11.2.5 should return null.

    Issue 6532 resolved that oclAsType in 7.5.9. return a Classifier. The changed specification has OclType.

  • Reported: OCL 2.1 — Wed, 26 Aug 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    Issue 7341 is correct.; invalid should be returned by oclAsType when the type
    does not conform. Issue 10437 is wrong. The 10437 revised text also incorrectly
    uses t rather than T.
    Issue 6532 specified an 'instance of Classifier' return for oclAsType. The
    convenience document has not been updated.

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

OCL 2.1 9.3 Missing TypeLiteralExpCS

  • Key: OCL23-16
  • Legacy Issue Number: 14585
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The expression

    'a'.oclAsType(String)

    is not well-formed since the invocation of oclAsType is an OperationCallExpCS[E] for which String must be an OclExpressionCS.

    String is intended to be a literal expression with a Classifier value, but there is no well-formed OclExpressionCS that can represent such a value.

    Syntactically:

    String could be a VariableExpCS but is not the name of a visible VariableDeclaration.

    String could be a PropertyCallExpCS[B or C] or AssociationClassCallExpCS[B] but is not the name of a property.

    A TypeLiteralExpCS is required to allow use of at least typeCS[A] and more flexibly any typeCS.

  • Reported: OCL 2.1 — Wed, 28 Oct 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    In 9.3 LiteralExpCS add
    [E] LiteralExpCS ::= TypeLiteralExpCS
    and
    [E] LiteralExpCS.ast = TypeLiteralExpCS.ast
    and
    [E] TypeLiteralExpCS.env = LiteralExpCS.env
    In 9.3 add
    TypeLiteralExpCS
    This production rule references a type name.
    Abstract syntax mapping
    TypeLiteralExpCS ::= typeCS
    Synthesized attributes
    TypeLiteralExpCS.ast = typeCS.ast
    Inherited attributes
    typeCS.env = TypeLiteralExpCS.env
    Disambiguating rules
    – none

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

OCL 2.1 9.3 Inferred TupleLiteralExp part type

  • Key: OCL23-15
  • Legacy Issue Number: 14584
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Disambiguating rule 1 for TupleLiteralExp requires each VariableDeclaration to have a type and initExpression.

    However some examples in 7.5.15 omit the type, which is easily inferred from the initializer.

    However neither 8.3.7 nor 9.3 specifies this inference.

    Presumably the type is optional and to be inferred when omitted.

  • Reported: OCL 2.1 — Tue, 27 Oct 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    The synthesized attributes for VariableDeclarationCS should infer when possible.

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

OCL 2.0 and 2.1 Section 9.3 CollectionRangeCS incorrect operator spelling

  • Key: OCL23-11
  • Legacy Issue Number: 14237
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The definition of the CollectionRangeCS grammar is

    CollectionRangeCS ::= OclExpressionCS[1] ‘,’ OclExpressionCS[2]

    but everywhere else the operator is '..'

    Suggest change to

    CollectionRangeCS ::= OclExpressionCS[1] ‘..’ OclExpressionCS[2]

  • Reported: OCL 2.1 — Sat, 29 Aug 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    simple typo

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

OCL 2.1 Incomplete resolution 9913 InvalidLiteralExpCS and NullLiteralExpCS

  • Key: OCL23-10
  • Legacy Issue Number: 14236
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Issue 9913 defines the missing InvalidLiteralExpCS and NullLiteralExpCS, but they are never referenced in the grammar.

    Suggest:

    Add to PrimitiveLiteralExpCS

    [E] PrimitiveLiteralExpCS ::= NullLiteralExpCS
    [F] PrimitiveLiteralExpCS ::= InvalidLiteralExpCS

    and

    [E] PrimitiveLiteralExpCS.ast = NullLiteralExpCS.ast
    [F] PrimitiveLiteralExpCS.ast = InvalidLiteralExpCS.ast

    (not forgetting UnlimitedNaturalLiteralExpCS

  • Reported: OCL 2.1 — Sat, 29 Aug 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    Yes; resolution 9913 is incomplete

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

OCL 2.0 Inadequate Headings and PDF index

  • Key: OCL23-7
  • Legacy Issue Number: 14200
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The OCL 2.0 specification would be much easier to read if:

    1) The PDF had a full set of titles visible in the bookmarks:

    8.3.*, Annex A.2 , Annex B and Index are missing completely.

    A.1 and A.3 apppear as subsections of 13.3.

    2) There are a number of large sections such as 8.3.*, 9.3 and 10.4 with unnumbered headings for each AS or CS class.
    [11.5 is much better in this respect.]

    These are not in alphabetical order, not page aligned and not particularly distinct.

    It would be helpful to

    a) give them numbers so that they appear in the Bookmarks and are more distinct.
    b) put them in alphabetical order.
    [c) consider page aligning them.]

    [It would be good if the index was much more comprehensive too.

    e.g "at", "null", "any", "iterator", "UnlimitedNatural" ...]

  • Reported: OCL 2.1 — Sat, 22 Aug 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    PDF bookmarks were fixed in OCL 2.3.
    Alphabeticizing must wait until autogenerated in OCL 2.5.
    Provision of a manually maintained index in OMG specifications is strongly discouraged.
    Disposition: Closed, no change

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

OCL 2.0, 2.1 Inaccurate well-formedness constraints for IteratorExp

  • Key: OCL23-6
  • Legacy Issue Number: 14199
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The well-formedness constraints for IteratorExp are confusing, incomplete and sometimes wrong.

  • Reported: OCL 2.1 — Sat, 22 Aug 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    The revised text below resolves these issues

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

Prime symbol lacking in the explanation preceding the formula

  • Key: OCL231-33
  • Legacy Issue Number: 16302
  • Status: closed  
  • Source: CumuloCogitus Inc. ( Dominic Roy)
  • Summary:

    In the 3rd item of the definition A.12 (System State), the paragraph before the formula ends by :
    "whereas the function i(l) projects all but the ith component):"

    The function is exactly the same as the first function in the same sentence. It appears that a prime symbol is missing in the function. Indeed, a prime symbol appears in the formula.

  • Reported: OCL 2.3 — Wed, 1 Jun 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    The overline operator got lost when the Latex was FrameMakered

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

Confusing usage of the "precedes" symbol for generalization hierarchy

  • Key: OCL231-32
  • Legacy Issue Number: 16291
  • Status: closed  
  • Source: CumuloCogitus Inc. ( Dominic Roy)
  • Summary:

    The symbol ≺ is used in this page. According to Unicode definition, this symbol represents a mathematical symbol whose definition is "precedes". Here is the reference of that definition :
    http://unicode.org/cldr/utility/character.jsp?a=227A

    I'm not a mathematician and I don't know precisely what this symbol means for mathematicians, even if I searched in many books and on the Internet. However, I find very confusing to use a symbol that means "precedes" to means "is the child of".

    There is another symbol ≻ which means 'succeeds' that would be less confusing in the sense of "C1 succeeds C2" to means that C1 is the child of C2.

    As I'm not mathematician, I may be completely wrong and I would greatly appreciate a sound reference where this symbol is defined formally.

  • Reported: OCL 2.3 — Sat, 28 May 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    The current operator has not been significantly changed by the Latex to FrameMaker conversion and so corresponds to an informed academic choice.
    The requested change is less-informed and subjective.
    Disposition: Closed, no change

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

Japan PAS Ballot Comment 34 (ocl2-rtf) 13.3 Diagrams figure 13.8

  • Key: OCL231-29
  • Legacy Issue Number: 16157
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Same diagrams are duplicated. Remove either. The referred operation:
    OperationCallExpCS.ast.referredOperation =
    if OclExpressionCS.ast.type.oclIsKindOf(CollectionType)
    then – this is a collection operation called on a collection
    OclExpressionCS.ast.type.lookupOperation(simpleNameCS.ast,
    if (argumentsCS->notEmpty())
    then argumentsCS.ast->collect(type)
    else Sequence{} endif )
    else – this is a set operation called on an object => implicit Set with one element
    SetType.allInstances()->any(st|st.elementType = OclExpressionCS.ast.type).lookupOperation(simpleNameCS.ast,
    if (argumentsCS->notEmpty())
    then argumentsCS.ast->collect(type)
    else Sequence{} endif )
    endif

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    The unique difference, that the first diagram misses the CollectionKind.Collection
    Enumeration literal. Remove the first diagram.

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

Japan PAS Ballot Comment 33 (ocl2-rtf) 13.3.3 String page 144

  • Key: OCL231-28
  • Legacy Issue Number: 16156
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    “ASCII or Unicode” is confusing. Use the same UML description

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Initial Comment/Suggestion: Use the same UML description
    Comment : Resolved by using uml infrastructure 13.2.4 definition for string type:

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

Japan PAS Ballot Comment 28 (ocl2-rtf) 10.2.3 Additional Operations for the Values Package

  • Key: OCL231-25
  • Legacy Issue Number: 16151
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    ObjectValue [1] The text refers to name parameter of snapshot, but LocalSnapshot in Figure 10.2 does not have “name: String” Add name parameter to LocalSnapshot in Figure 10.2.

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    “The value that is bound to the name parameter in the latest snapshot” implies the use of
    the LocalSnapshot's bindings (NameValueBinding). Perhaps, including the word
    “bindings” may avoid confusions

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

Japan PAS Ballot Comment 27 (ocl2-rtf) Section 10.2.1 Definitions of Concepts for the Values Package

  • Key: OCL231-24
  • Legacy Issue Number: 16150
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Figure 10.3 Explanation of TupleValue (page 107) describes its association with element, but this association is not included in Figure 10.3. Add this association to Figure 10.3

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    IIn section 10.2.1, the TupleValue description states the following:
    “In the metamodel, this is shown as an association from TupleValue to NameValueBinding.”
    Therefore the text, diagram and association description are consistent.
    Disposition: Closed

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

Use of the word meta

  • Key: OCL231-30
  • Legacy Issue Number: 16235
  • Status: closed  
  • Source: CumuloCogitus Inc. ( Dominic Roy)
  • Summary:

    I want to signal that the use of the word "meta" is confusing. Here is an example on page 47.

    TypeExp
    A TypeExp is an expression used to refer to an existing meta type within an expression.

    According to Merriam-Webster, "meta" is usually a prefix that could be added at the beginning of a word. This particle should be merged to the main word (like in metabasis) or attached using an hyphen (like meta-analysis).

    In consequence, we should read "metatype" which seems to hold the correct meaning. It is coherent with metaclass, for example. By the way, "metatype" is used at many places in the document.

    In some contexts and in the familiar language, you can use "meta" as a diminutive for something when its meaning is obvious. For example, "the meta is broken" when you mean the metacarpus. In a specification document and in a context where we have to differentiate many metaconcepts, it doesn't have its place.

    It is seen at many places in this document and may be other. In this one, we see "meta model" and "meta-model", while the word "metamodel" should be and is effectively used.

  • Reported: OCL 2.3 — Fri, 13 May 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    yes

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

Japan PAS Ballot Comment 30 (ocl2-rtf) 10.3 The Evaluations Package, 2nd paragraph

  • Key: OCL231-26
  • Legacy Issue Number: 16153
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    This paragraph is confusing. It starts with Figure 10.6 but talks about elements not included in Figure 10.6. In addition it talks about “OclEvaluation” twice, which do not appear in any of the following diagrams.Split the paragraph into two. Fist one should be just about summary of Figure 10.6, and the second one should introduce Figure 10.7with associated elements

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Initial suggestion:
    Split the paragraph into two. Fist one should be just about summary of Figure 10.6, and the second one
    should introduce Figure 10.7with associated elements.

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

on page 153 oclIsInState is used instead of oclInState

  • Key: OCL231-31
  • Legacy Issue Number: 16260
  • Status: closed  
  • Source: Vienna University of Economics and Business ( Bernhard Hoisl)
  • Summary:

    On page 153 oclIsInState(statespec : OclState) is used to check if an object is in a specified state. But in Section 7.5.9 on page 22 oclInState(statespec : OclState) is used for this purpose and examples are given.

    There is one more occurrence of oclIsInState on page 47 of Section 8.3.1, but this is talking about the abstract syntax, therefore it could be valid. But I think definitely not for the concrete syntax of the OCL.

    Strangely enough the Eclipse Interactive OCL Console implements oclIsInState() and not oclInState().

    I would appreciate a clarification which statement to use very much!

  • Reported: OCL 2.3 — Fri, 20 May 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    If it was a popularity contest, oclInState would win because there are many occurences in Clause 7, but Clause 7 is not normative.
    Excluding clause 7, oclIsInState has two occurences to oclInState's one. More importantly, the definition in 11.3.1 is oclIsInState.
    Stylistically, all other ocl-prefixed methods returning boolean are oclIs...
    Let's go for oclIsInState

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

Japan PAS Ballot Comment 25 (ocl2-rtf) 10.1 Introduction, 3rd and 4th paragraphs

  • Key: OCL231-23
  • Legacy Issue Number: 16148
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The term “OMG 4-layered architecture” may need to be explained or used with proper references. Modify the text as appropriate.

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Not much of a title.
    Anyone familiar with modeling should really know who the OMG is and what a 4-layered architecture is.
    However it is surprisingly difficult to find any primary OMG references. MOF for instance refers to "a ‘Four layered metamodel architecture’ which is referred to in various OMG specifications" so maybe MOF will get some adverse comments from PAS too.

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

Japan PAS Ballot Comment 31 (ocl2-rtf): 10.3.1 Definitions of Concepts for the Evaluations Package

  • Key: OCL231-27
  • Legacy Issue Number: 16154
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    OperationCallExp. This heading should read “OperationCallExpEval.”. Modify the heading as appropriate.

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Suggested action: Modify the heading as appropriate.

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

Unbalanced parenthesis in the formula

  • Key: OCL231-34
  • Legacy Issue Number: 16303
  • Status: closed  
  • Source: CumuloCogitus Inc. ( Dominic Roy)
  • Summary:

    The last formula in the definition A.12 has unbalanced parenthesis.
    The first parenthesis after the = sign seems in excess.

  • Reported: OCL 2.3 — Wed, 1 Jun 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    No Data Available

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

OCL 2.2 UML Alignment of association names

  • Key: OCL23-33
  • Legacy Issue Number: 15235
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    In accordance with Nicolas Rouquette's observations in the discussion on "15233 – OCL 2.2 Correction to Issue 9796 for AssociationEndCall":

    The problem with OCL 2.2, Fig 7.1 are:

    • give a name to the association end near Bank, e.g. 'bankAccount'
    • fix the multiplicity of: Person::bankAccount from 0..1 to * – i.e., a person can have zero or more bank accounts!
    • fix the multiplicity of Bank::customer from 0..* to 0..1 – i.e., there is zero or one customer for a given 'accountNumber' value.
    • give a name to the association itself, e.g., BankAccount, or, if you want to use the UML notation convention, A_customer_bankAccount

    and

    The OCL examples for Figure 7.2, currently:

    context Person inv: self.employeeRanking[bosses]->sum() > 0
    context Person inv: self.employeeRanking[employees]->sum() > 0
    context Person inv: self.employeeRanking->sum() > 0 – INVALID!
    context Person inv: self.job[employer]

    should be fixed to:

    context Person inv: self.EmployeeRanking[bosses]->sum() > 0
    context Person inv: self.EmployeeRanking[employees]->sum() > 0
    context Person inv: self.EmployeeRanking->sum() > 0 – INVALID!
    context Person inv: self.Job[employer]

    That is, 'EmployeeRanking' is the name of the association shown in Fig 7.2
    That figure does not have anything called 'employeeRanking' and it is misleading to suggest that in OCL the name of the association could be written with a lowercase initial letter when the name of the association itself has an initial capital letter. Since lexical names are case-sensitive in both UML and OCL, case-sensitivity should be respected to avoid creating confusion and potential ambiguity with other names that are lexically different only by their upper/lower case letter.

    and

    In particular, the text in clause 7.5.4 about using the name of an association class with a lowercase initial letter should be removed.
    That is, change the following, currently:

    To specify navigation to association classes (Job and Marriage in the example), OCL uses a dot and the name of the association class starting with a lowercase character:

    context Person inv: self.job

    The sub-expression self.job evaluates to a Set of all the jobs a person has with the companies that are his/her employer. In the case of an association class, there is no explicit rolename in the class diagram. The name job used in this navigation is the name of the association class starting with a lowercase character, similar to the way described in the sub clause “Missing AssociationEnd names” above.

    to:

    To specify navigation to association classes (Job and Marriage in the example), OCL uses a dot and the name of the association class:

    context Person inv: self.Job

    The sub-expression self.Job evaluates to a Set of all the jobs a person has with the companies that are his/her employer. In the case of an association class, there is no explicit rolename in the class diagram. The name Job used in this navigation is the name of the association class.

  • Reported: OCL 2.2 — Fri, 30 Apr 2010 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

OCL 2.2 11.5.3 What is a locale?

  • Key: OCL23-32
  • Legacy Issue Number: 15224
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The new toUpperCase, toLowerCase and equalsIgnoreCase refer to case conversion if appropriate to the locale without ever defining what a locale is or defining the preconditions for appropriateness.

    These methods closely resemble Java Library methods, perhaps they should reference rather than duplicate the Java specification.

    The Java toUpperCase method provides locale-dependent and local-independent variants.

    Is it right for OCL to make it difficult to achieve predictable results under a Turkish locale?

    It seems that the OCL standard library must provide access to the Locale and provide both Java's toUpperCase variants.

  • Reported: OCL 2.2 — Fri, 23 Apr 2010 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

OCL 2.2 11.7.1 Why must + be commutative for Collection::sum()

  • Key: OCL23-31
  • Legacy Issue Number: 15223
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Collection::sum() requires that its T::+() is commutative and associative.

    Associativity is necessary for predictable results.

    Commutativity is not necessary, most trivially for String::+ for which sum() could usefully
    concatenate an OrderedSet.

    Suggest: remove the requirement for commutativity.

  • Reported: OCL 2.2 — Fri, 23 Apr 2010 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

OCL 2.2 11.7.1 Why must + be associative for Collection::sum()

  • Key: OCL23-30
  • Legacy Issue Number: 15222
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Collection::sum() requires that its T::+() is commutative and associative.

    Associativity is necessary for predictable results.

    However what if it isn't?

    Is there an obligation on the OCL runtime to detect non-associativity and return invalid?

    • probably not possible.

    Is there a permission on the OCL runtime to detect non-associativity and return invalid?

    • difficult to ensure implementation portability

    Is there just an informal caution to users that non-associativity may lead to unpredictable results?

    Suggest: reword to permit an implementation to return invalid and caution users about unpredictable results.

  • Reported: OCL 2.2 — Fri, 23 Apr 2010 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

OCL 2.3 Ballotted: Retracting resolutions for Issue 10439/13076

  • Key: OCL23-37
  • Legacy Issue Number: 15761
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    I am no longer happy with my resolution of 10439/13076 which provides a
    very high resolution LALR grammar. This is inefficient to emulate with
    LL and cannot provide the flexibility of configurable precedence. It
    will also be very difficult to accommodate a template parameter parse
    with similarly high precision. I now favour a low precision syntactic
    parse augmented by high precision disambiguation/semantic checks.

    If the high precision LALR grammar may need retraction, it seems
    undesirable to put it into 2.3 only to remove it in 2.4.

    Suggest retract the resolutions for OCL 2.3 and rewrite for OCL 2.4 once
    UML-alignment of templates has been accommodated

  • Reported: OCL 2.2 — Sat, 9 Oct 2010 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

toLowerCase() declared as returning Integer

  • Key: OCL23-36
  • Legacy Issue Number: 15528
  • Status: closed  
  • Source: yahoo.com ( Scott Forbes)
  • Summary:

    In section "11.4.3 String" on p145 toLowerCase() is declared as returning Integer, correct type is String

  • Reported: OCL 2.2 — Tue, 14 Sep 2010 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

the use of the keyword 'attr'

  • Key: OCL23-34
  • Legacy Issue Number: 15254
  • Status: closed  
  • Source: UPCT ( Pedro Alcover)
  • Summary:

    I've seen, in the version 2.0, the existence of the keyword 'attr'. But then, in fact, there isn't any reference or explanation about the use of this keyword.
    I've seen that this keyword is not in the new versión 2.2. But, you use it in the page 25, ln 12.

  • Reported: OCL 2.2 — Fri, 14 May 2010 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    The 'attr' is a relic of a former (pre OCL 2.0) syntax.
    The 'attr' should be omitted, and 'TupleType' should be 'Tuple'.

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

The opertion "collect" is confused with the operation "reject"

  • Key: OCL23-38
  • Legacy Issue Number: 15980
  • Status: closed  
  • Source: gmail.com ( Fedor Ermishin)
  • Summary:

    "Reject" should be replaced with "collect" in the following line:
    "The value of the reject operation is the collection of the results of all the evaluations of expression-with-v."

  • Reported: OCL 2.2 — Mon, 24 Jan 2011 05:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    yes

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

Definition for symmetric difference is wrong

  • Key: OCL23-35
  • Legacy Issue Number: 15270
  • Status: closed  
  • Source: gmail.com ( Gustav Munkby)
  • Summary:

    symmetricDifference: is defined as (S1 u S2) - (S1 u S2), but this always yields the empty set. I believe the intended writing is (S1 u S2) - (S1 n S2).

  • Reported: OCL 2.2 — Tue, 1 Jun 2010 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

US PAS Ballot Comment 3 (ocl2-rtf) paragraph 1

  • Key: OCL231-7
  • Legacy Issue Number: 16123
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The nature of the relationship between this specification and the OCL in UML 1.4 should be clarified in an informative manner.
    UML 1.4.1 needs to remain in force, because many UML models in many standards throughout the world are specified using UML 1.x notation, which is not backwards compatible with the notation in UML 2.x.
    Replace:

    This specification replaces the specification of OCL given in UML 1.4.1 and UML 1.5.

    With:

    This specification replaces the specification of OCL given in OCL 2.0.
    The version of OCL specified in ISO/IEC 19501:2005 is intended for use in models based on UML 1.4.1 and UML 1.5. However, use of the OCL specified by ISO/IEC 19501:2005 is not prescribed by this specification.
    The version of OCL specified in this International Standard is not directly applicable to models based on ISO/IEC 19501:2005. ”

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    No Data Available

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

US PAS Ballot Comment 2 (ocl2-rtf) References

  • Key: OCL231-6
  • Legacy Issue Number: 16122
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The references need to include links to the formal OMG published specifications.

    The Scope clause refers to UML 2.2, however the reference is UML 2.0

    Informal references to UML 1.4.1 and UML 1.5 are included as part of explanatory text in the OCL 2.2 spec which refers to UML 1.x to explain differences of this new version of OCL.. The ISO/IEC 10151 (UML 1.4.1) needs to be added as an informative reference, for use in these explanations.
    Change:

    3 Normative References
    The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
    • UML 2.0 Superstructure Specification
    • UML 2.0 Infrastructure Specification
    • MOF 2.0 Core Specification
    • UNICODE 5.1 Standard: http://www.unicode.org/versions/Unicode5.1.0/
    «
    To :
    «
    3 References
    3.1 Normative References
    The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
    • UML 2.2 Superstructure Specification <omg spec Ref URL>
    • UML 2.2 Infrastructure Specification <omg spec Ref URL>
    • MOF 2.0 Core Specification <omg spec Ref URL>
    • UNICODE 5.1 Standard: http://www.unicode.org/versions/Unicode5.1.0/
    3.2 Informative References
    The following specifications are referenced in informative text:
    • ISO/IEC 19501:2005 Information technology – Open Distributed Processing – Unified Modeling Language (UML) Version 1.4.2 , also <omg Spec Ref URL>

    Change all uses of the informal UML 1.x references in the text From:

    UML 1.x” or “UML 1.4.x”

    To:

    ISO/IEC 19501:2005

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    No Data Available

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

Issue on Alignment of next OCL version and references UML 2.4/ MOF 2.4

  • Key: OCL231-2
  • Legacy Issue Number: 15877
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Nature of problem:

    Informal references to UML 1.4.1 and UML 1.5 are included
    as part ofexplanatory text in the OCL 2.2 spec which refers
    to UML 1.x to explain differences of this new version of
    OCL.. The ISO/IEC 10151 (UML 1.4.1) needs to be added as
    an informative reference, for use in these explanations.

    UML 1.4.1 needs to remain in force, because so many UML
    models in may standards throughout the world are specified
    using UML 1.x notation, which is not backwards compatible
    with the new notation in UML 2.x.

    Given the normative content of OCL 2.3 (after RTF
    completes) is aligned technically with UML 2.4 and MOF 2.4,
    its normative references should be updated before
    publication of the RTF output, so that the OMG spec cross
    references will remain appropriate..

    The references, and their uses in the OCL 2.3spec, need to
    be updated to reflect these latest UML/MOF versions.

    In addition, the Output of the OCL 2.3 RTF should be
    labeled as OCL 2.4, to avoid clarify the technical
    alignment of OMG’s latest versions of UML and MOF.

    Proposed Changes:

    Change version in title to OCL 2.4.

    Change all self references in the text from “OCL version
    2.2” to “this OMG Specification”.

    Change all references from UML 2.0 and MOF 2.0 to UML 2.4
    and MOF 2.4.

    In Section 1 ­ Scope Clause:

    Change:

    This specification defines the Object Constraint Language
    (OCL), version 2.3. OCL version 2.3 is the version of OCL
    that is aligned with UML 2.3 and MOF 2.0.

    to

    This specification defines the Object Constraint Language
    (OCL), version 2.4. OCL version 2.4 is the version of OCL
    that is aligned with UML 2.4 and MOF 2.4.

    Section 3 ­ Normative References

    Change:

    3 Normative References
    The following normative documents contain provisions which,
    through reference in this text, constitute provisions of
    this specification. For dated references, subsequent
    amendments to, or revisions of, any of these publications
    do not apply.
    • UML 2.0 Superstructure Specification
    • UML 2.0 Infrastructure Specification
    • MOF 2.0 Core Specification
    • UNICODE 5.1 Standard:
    http://www.unicode.org/versions/Unicode5.1.0/
    «
    To :
    «
    3 References
    3.1 Normative References
    The following normative documents contain provisions which,
    through reference in this text, constitute provisions of
    this specification. For dated references, subsequent
    amendments to, or revisions of, any of these publications
    do not apply.
    • UML 2.4 Superstructure Specification <omg spec Ref URL>
    • UML 2.4 Infrastructure Specification <omg spec Ref URL>
    • MOF 2.4 Core Specification <omg spec Ref URL>
    • UNICODE 5.1 Standard:
    http://www.unicode.org/versions/Unicode5.1.0/
    3.2 Informative References
    The following specification is reference in explanatory
    text, which describes differences between this
    specification and the version of OCL included in the
    existing standard. Its provisions do not constitute
    provisions of this specification.
    • ISO/IEC 19501:2005 Information technology – Open
    Distributed Processing – Unified Modeling Language (UML)
    Version 1.4.2 , also <omg Spec Ref URL>

    Change all uses of the reference in the text
    From

    UML 1.x” or “UML 1.4.x”

    To:

    ISO/IEC 19501:2005

    In Section 6.1 “Changes to Adopted OMG Specifications”

    Replace:

    This specification replaces the specification of OCL given
    in UML 1.4.1 and UML 1.5.

    With:

    This specification replaces the specification of OCL given
    in OCL 2.2.

    The version of OCL specified in ISO/IEC 19505:2005 is
    intended for use in models based on UML 1.4.1 and UML 1.5.
    However, use of the OCL specified by ISO/IEC 19505:2005 is
    not prescribed by this specification.

  • Reported: OCL 2.3 — Tue, 7 Dec 2010 05:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Although this issue was raised in conjunction with the First OCL 2.4 RTF that led to OCL 2.3.1, it seems appropriate to use this issue resolve all the 'boilerplate' changes for OCL 2.4.
    Some of the changes outlined above occurred in OCL 2.3.1 and so need only a refresh for OCL 2.4.
    The change of all OCL 2.2 references to this specification is not applicable since all references to OCL 2.2 and 2.3 intentionally refer to transitions in specified functionality.
    MOF 2.0 references occur only in the boilerplate and so have been enumerated.
    There are many UML 2.0 references associated with the TBD alignment with the UML 2.0 metamodel. These are very unfortunate but deserve to stay as the TBDs that they remain.

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

US PAS Ballot Comment 1

  • Key: OCL231-5
  • Legacy Issue Number: 16121
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The OMG OCL 2 Revision Task force has resolved a set of defect and clarification issues against the text in DIS 19507. (Preliminary Report http://doc.omg.org/ptc/10-12-01.pdf , Change Barred Spec http://doc.omg.org/ptc/10-11-41.pdf) It is important that the corrections resolving these defects be reflected in the published ISO/IEC Standard for OCL. The editing group for OCL 2 (DIS 19607) should consider all changes against the text of OCL 2.2, resulting from RTF defect resolutions in the latest minor revision to OCL 2, approved by the OMG PTC by the time of the ballot resolution.

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    This is a philosophical statement without any identifiable issues. Many related issues were raised so presumably no action is necessary here.
    Disposition: Closed, no change

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

oclIsInState()

  • Key: OCL231-4
  • Legacy Issue Number: 16048
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Since you are working on the StateMachines chapter, it may be worth considering after the first submission adding an explanation about oclIsInState().
    This query operation is unfortunately mispelled as oclInState(), see: http://www.omg.org/issues/ocl2-rtf.open.html#Issue15257
    This query operation is confusingly listed as a predefined property and explained as an operation in OCL2.2, clause 7.5.9:

    7.5.9 Predefined properties on All Objects
    There are several properties that apply to all objects, and are predefined in OCL. These are:
    oclIsTypeOf (t : Classifier) : Boolean
    oclIsKindOf (t : Classifier) : Boolean
    oclInState (s : OclState) : Boolean
    oclIsNew () : Boolean
    oclAsType (t : Classifier) : instance of OclType

    ....
    The operation oclInState(s) results in true if the object is in the state s. Possible states for the operation oclInState(s) are all states of the statemachine that defines the classifier's behavior. For nested states the statenames can be combined using the double colon “::”.

  • Reported: OCL 2.3 — Mon, 7 Mar 2011 05:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    I'm not sure that this correspondence on the UML RTF was really intended to be an OCL issue.
    The specific oclIsInState typo is resolved by Issue 16260.
    The more general discussion is appropriate for UML.
    Disposition: See issue 16260 for disposition

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

OCL 2.3 Incomplete CollectionRange well-formedness rules

  • Key: OCL231-1
  • Legacy Issue Number: 15836
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The descriptions of CollectionRange are generally vague leaving the end inclusivities unclear.

    It is only the CollectionRangeEval::getRange that provides a solid definition of well-formedness
    for e.g. Sequence

    {1..1}

    as equal to Sequence

    {1}

    .

    Unfortunately the specification is undecided about Sequence

    {2..1} since the CollectionRangeEval::getRange
    recursion never terminates.


    Rather than impose a well-formedness constraint that Sequence{2..1}

    is invalid, perhaps it should be
    made useful instead, by defining .. as operating in the direction of the last wrt the first so
    Sequence

    {2..1} = Sequence{2,1} and Set{1..2} = Set{2..1}

    = Set

    {1,2}

    .

  • Reported: OCL 2.3 — Thu, 18 Nov 2010 05:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    The generalization to allow down-counts can lead to nasty surprises for e.g. Sequence

    {1..x->size()}

    when x is empty. So just make it clear that Sequence

    {2..1}

    is invalid

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

Issue nnnn: Japan PAS Ballot Comment 5 (ocl2-rtf)

  • Key: OCL231-10
  • Legacy Issue Number: 16128
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Click here for this issue's archive.
    Nature: Issue from PAS Ballot comment for ISO/IEC DIS 19507
    Severity:
    Summary:

    See comment JP 5 in “…_JISC.doc” file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip
    Resolution:

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Not much of a title.
    Not much of a summary.
    The referenced document jumps straight from JP4 to JP6, so no action possible.
    Even if JP6 was meant rather than JP5 then we can dismiss as a duplicate of Issue 16129.
    Disposition: Closed, no change

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

Issue nnnn: Japan PAS Ballot Comment 2 (ocl2-rtf)

  • Key: OCL231-9
  • Legacy Issue Number: 16125
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The format of normative references doesn't meet ISO format.ISO/IEC 19505-1:2011 Information technology — OMG Unified Modeling Language (OMG UML) Version 2.1.2 Part 1: Infrastructure
    ISO/IEC 19505-2:2011 Information technology — OMG Unified Modeling Language (OMG UML) Version 2.1.2 Part 2: Superstructure
    ISO/IEC 19502:2005 Information technology – Meta Object Facility (MOF)
    ISO/IEC 10646:2003 Information technology – Universal Multiple-Octet Coded Character Set (UCS)
    If you want to refer OMG’s documents, see directive.

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Resolved as Issue 16122. See US 1, Added 10646 as ref for Unicode. Will Fix at BRM to
    most appropriate formal references, either ISO or OMG spec refs
    Disposition: See issue 16122 for disposition

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

typo in ptc/2010-11-42 and pas/2010-08-02

  • Key: OCL231-3
  • Legacy Issue Number: 15922
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    Regarding ptc/10-11-42 and pas/10-08-02,
    It seems to be typo.

    In ptc/10-11-42, 11.6.5, and
    in pas/10-08-02, 11.5.5

    Threre is
    "A Sentence is not a subtype of Bag. The common supertype of Sentence and Bags is Collection."
    ^^^^^^^ ^^^^^^^^

    These two "Sentence"s seem to be typo.

    Substitute "Sequence" for "Sentence".

  • Reported: OCL 2.3 — Mon, 10 Jan 2011 05:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Yes. Bags is also a typo and the English can be improved

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

Japan PAS Ballot Comment 1 (ocl2-rtf)

  • Key: OCL231-8
  • Legacy Issue Number: 16124
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Because the content of table 2.1 is empty, this table is meaningless. Fill the table.

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    As the text above the table 2.1 explains, said template table is intended to be filled by OCL Tool
    implementors.
    Disposition: Closed

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

Exact type of Set{} and missing Set(MyType){} literal definitions

  • Key: OCL21-347
  • Legacy Issue Number: 12953
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Summary:
    It is not clear what is the concrete type of Set{}. Is it Set(Object), Set(Void)
    Also it seems there is no way to explicitly define an empty collection with a given
    type for the elements.

  • Reported: OCL 2.0 — Fri, 10 Oct 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Discussion of this issue suggested a number of options:
    Option 1: The type of Set{} is Set(OclVoid)
    This does not work because
    Set{}->including(1)
    is an error since "1" or indeed anything other than null or invalid does not
    conform to OclVoid.
    Option 2: The type of Set{} is Set(OclAny)
    This does not work because
    acc : Set(Integer) = Set{}->including(1)
    is an error since Set(OclAny) is not compatible with Set(Integer).
    Option 3: The type of Set{} is a new built-in type EmptySet(ET) where ET is
    determined in some way.
    This does not work because given the RHS of
    acc : Set(Integer) = Set{}>including(1.0)
    >including(Classifier)>excluding(1.0)>excluding(Classifier)
    it is difficult to see how ET could be determined more precisely than OclAny
    causing the same problem as Option 2.
    Option 4: The type of Set{} is Set(null)
    Since Set{} and Set(null) have no precise OCL 2.1 semantics there is some
    discretion in defining them, but eventually a dynamic type validation is needed for
    acc : Set(String) = Set(null)

    {getInitialValue()}

    . The impact on evaluation could be
    mitigated by synthesis of an oclAsType() in the Abstract Syntax Tree, but it is not
    18
    possible to provide a static type for the CollectionLiteralExp. This option could
    work but requires revision of abstract syntax and evaluation specifications.
    Option 5: The type of Set{} is back-propagated
    For instance in
    acc : Set(Real) = Set{}>including(1)>including(-1)
    the type of Set{} is Set(Real) since that is the eventual result type. This involves
    unusual reverse semantics.
    Option 6: The type of Set{} is Set(T) with T chosen for well-formedness of the
    expression in which the Set{} is used.
    For instance in
    acc : Set(Real) = Set{}>including(1)>including(-1)
    the type of Set{} is initially Set(T) where T <= OclVoid. Propagation of the type to
    Set(T)::including(UnlimitedNatural) requires T <= UnlimitedNatural. Propagation
    to Set(T)::including(Integer) requires T <= Integer. Finally, propagation to the
    initializer requires Real <= T. Therefore any Real <= T <= Integer is well-formed.
    The lower bound, Set(Real), is preferred since it avoids many type conversions.
    It is also the same result as Option 5.
    Option 6 involves only additional forward static semantics, has no impact on
    evaluation, no impact on parsing, and gives the intuitively correct OCL 2.1
    results.


    In order to impose a user-specified element type and so get static type checking
    of user intent, a collection element type can be specified as:
    acc : Set(Integer) = Set(Integer){}
    It is difficult to parse this in OCL 2.1 because Set is not a reserved word and so
    lookahead is required to determine whether Set(someName) is the start of a
    StringLiteralExpCS or an OperationCallExpCS, with someName perhaps being a
    complicated nested type/value ambiguity.
    Issue 14357 introduces the concept of a restricted word preventing the
    unqualified use of Set as an operation name. The extension is then
    straightforward.

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