1. OMG Mailing List
  2. OCL 2.5 Revision Task Force

Closed Issues

  • Issues resolved by a task force and approved by Board
  • Name: ocl2-rtf
  • Issues Count: 251

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
OCL23-39 Role 'collectionTypes' should be 'collectionType' OCL 2.1 OCL 2.2 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
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-34 Unbalanced parenthesis in the formula OCL 2.3 OCL 2.3.1 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-31 on page 153 oclIsInState is used instead of oclInState 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-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-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-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-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-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-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-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-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-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
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-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-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-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-8 Japan PAS Ballot Comment 1 (ocl2-rtf) OCL 2.3 OCL 2.3.1 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-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-3 typo in ptc/2010-11-42 and pas/2010-08-02 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-1 OCL 2.3 Incomplete CollectionRange well-formedness rules OCL 2.3 OCL 2.3.1 Resolved closed
OCL23-6 OCL 2.0, 2.1 Inaccurate well-formedness constraints for IteratorExp OCL 2.1 OCL 2.3 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-3 Missing specification of UnlimitedNatural OCL 2.1 OCL 2.3 Resolved closed
OCL23-35 Definition for symmetric difference is wrong 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-33 OCL 2.2 UML Alignment of association names OCL 2.2 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-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-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-27 OCL 2.1 8.3.8 OclInvalid::allInstances 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-38 The opertion "collect" is confused with the operation "reject" 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-15 OCL 2.1 9.3 Inferred TupleLiteralExp part type 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-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-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-20 Undefined operation tail() OCL 2.1 OCL 2.3 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-17 OCL 2.1 12.2.5 named-self classifierContextDeclCS 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-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-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-7 OCL 2.0 Inadequate Headings and PDF index OCL 2.1 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-21 Undefined operation tail() OCL 2.1 OCL 2.3 Resolved closed
OCL21-293 Section: 7.4.7, 7.4.9, 9.3.2 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-290 8.2.2 Well-formedness Rules for the Types Package 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-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-285 Naming of Constraints 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-282 11.2.5 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-279 11.2.3 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-276 Section 7.6.3 OCL 2.0 OCL 2.1 Resolved closed
OCL21-275 Section: 7.8 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-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-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-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-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-343 Incosistency between UnlimitedInteger and UnlimitedNatural OCL 2.0 OCL 2.1 Resolved closed
OCL21-342 Making OclAny denote any object 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-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-337 OCL 2.0: CollectionType constraint for invalid elements is incorrect 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-334 Section: A.3.1.2 Semantics of Expressions 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-301 Section: A/1.1.6 Generalization 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-298 Section: A/1.1.5 Associations 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-295 CollectionType and CollectionKind OCL 2.0 OCL 2.1 Resolved closed
OCL21-294 Section 8.2 InvalidType OCL 2.0 OCL 2.1 Resolved closed
OCL21-309 OrderedSet collection OCL 2.0 OCL 2.1 Resolved closed
OCL21-308 The Tuple constructor is problematic 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-305 Section: A/2.2 Common Operations on All Types 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-316 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-314 Section: A.2.5.5 Collection Operations 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-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-331 Section: A.3.1.2 Semantics of Expressions 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-328 Section 8.2 page 35 InvalidType 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-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-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-322 Section: A.3.1.1 Syntax of Expressions 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-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-318 Section: A.2.5.6 Set 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-271 Section: 8.3.5 OCL 2.0 OCL 2.1 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-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-262 The spec does not describes the syntax of integer, real or string literals OCL 2.0b2 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-259 Section: 11.5.4 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-272 Section: 7.5.9 OCL 2.0 OCL 2.1 Resolved closed
OCL21-251 Section: 7.4.5 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-250 Section: 7.4 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-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-246 value of a collection range 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-256 Section: 7.6.2 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-255 Section: 7.5.13 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-252 Section: 7.5.3 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-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-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-245 value of a collection range 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-243 result value of an attribute call expression OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-242 elements in a tuple value OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-241 The operation allPredecessors 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-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-205 The index seems incomplete 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-202 Issue: Unspecified syntax and semantics for Integer, Real, and String 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-199 Clarify the semantics of forAll 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-196 Exception of strict evaluation (forAll, exists) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-195 Exception of strict evaluation (implies) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-220 context State::getStateMachine() : StateMachine 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-217 Add a generic text formatter operator '% 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-232 arguments 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-229 add ’and’ between both expression parts 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-226 sub evaluations (in sequence bodyEvals) have different environment. 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-223 context LocalSnapshot 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-214 Automatic casting between strings and enumeration values 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-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
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

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

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

The t should be subscripted next to the equal sign

  • Key: OCL231-36
  • Legacy Issue Number: 16306
  • Status: closed  
  • Source: DMR Consulting Group ( 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: DMR Consulting Group ( 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

Unbalanced parenthesis in the formula

  • Key: OCL231-34
  • Legacy Issue Number: 16303
  • Status: closed  
  • Source: DMR Consulting Group ( 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

Prime symbol lacking in the explanation preceding the formula

  • Key: OCL231-33
  • Legacy Issue Number: 16302
  • Status: closed  
  • Source: DMR Consulting Group ( 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: DMR Consulting Group ( 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

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

Use of the word meta

  • Key: OCL231-30
  • Legacy Issue Number: 16235
  • Status: closed  
  • Source: DMR Consulting Group ( 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 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 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

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

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

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 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

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

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

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

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

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

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 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

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

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

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

typo in ptc/2010-11-42 and pas/2010-08-02

  • Key: OCL231-3
  • Legacy Issue Number: 15922
  • Status: closed  
  • Source: Fujitsu ( 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

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

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

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

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

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

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

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

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.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

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

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 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

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

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

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

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.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

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

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


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

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 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

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.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

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.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

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

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

Section: 7.4.7, 7.4.9, 9.3.2

  • Key: OCL21-293
  • Legacy Issue Number: 11098
  • Status: closed  
  • Source: Jet Propulsion Laboratory / Caltech ( Nicolas F. Rouquette)
  • Summary:

    The operator precedence rules in 9.3.2 are identical to the precedence rules in 7.4.7. Both sets are incomplete in that they do not specify the precedence of the 'let' operator. For example, in a UML profile, a constraint on a 'Property' stereotype might be: not self.base_Property.allNamespaces()>exists(oclIsKindOf(Profile) or oclIsKindOf(Stereotype)) implies let prop:Property=self.base_Property in prop.defaultValue>isEmpty() To parse properly (with RSA 7.0.0.2), this constraint must instead be written as: not self.base_Property.allNamespaces()>exists(oclIsKindOf(Profile) or oclIsKindOf(Stereotype)) implies (let prop:Property=self.base_Property in prop.defaultValue>isEmpty()) This suggests that the 'let' operator has a lower precedence than that of the 'implies' operator. Of course, there is an alternative way to write this constraint that does not expose this issue: let prop:Property=self.base_Property in not prop.allNamespaces()>exists(oclIsKindOf(Profile) or oclIsKindOf(Stereotype)) implies prop.defaultValue>isEmpty() The suggestion is to revise 7.4.7 and 9.3.2 to account for all keywords in 7.4.9. The keywords defined in 7.4.9 but not accounted for in 7.4.7 or in 9.3.2 are: - attr - context - def - endpackage - in - inv - let - oper - package - post - pre The keywords referenced in 7.4.7 or in 9.3.2 that are not defined in 7.4.9 are: - @pre Nicolas F. Rouquette Principal Computer Scientist http://www.jpl.nasa.gov Jet Propulsion Laboratory, Caltech M/S 301-270 Pasadena, CA 91109, USA phone: +1-818-354-9600 fax: +1-818-393-4100 e-mail: nicolas.f.rouquette@jpl.nasa.gov

  • Reported: OCL 2.0 — Tue, 5 Jun 2007 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Dynamic typing with allInstances()

  • Key: OCL21-292
  • Legacy Issue Number: 11097
  • Status: closed  
  • Source: No Magic, Inc. ( Tomas Juknevicius)
  • Summary:

    I have an issue with OclAny::allInstances() method, as described in the
    11.2.5 section of the OCL2 spec (06-05-01.pdf).

    If I understand correctly, OCL is a statically typed language (e.g. as stated
    in the beginning of 8.2 section or 8.3 section OclExpression paragraph).
    Every expression has a type and this type can be statically determined by
    analyzing the expression and its context.

    Most of the concepts in the OCL spec follows this rule, however I have
    an issue with the allInstances() method, defined on OclAny. Specifically,
    the "Returns all instances of self. Type T is equal to self." statement is problematic.

    When allInstances is used on the literal type specifier, there is no problem.
    E.g.

    context classFoo inv:
    somepackage::classBar.allInstances()->size() < self.limit

    Here, return type of the expression "somepackage::classBar.allInstances()" can be determined
    by static analysis ("at compile time") - it is Set(classBar).

    However when allInstances is invoked on variable, calculated by some expression,
    and all the staticallity of OCL crumbles and the hell breaks loose .
    And there are no restrictions, on what objects allInstances() can be invoked, the only rules are
    that the object to be classifier and the instance set be finite.

    E.g.
    (singleton rule - all the classes must have at most 1 instance)
    context Class inv:
    self.allInstances()->size() <= 1

    Now, what is the type of the self.allInstances() expression? Well, it depends on what is the self object -
    and self object is supplied at run time. If we evaluate this constraint on classFoo,
    we see that type of "self.allInstances()" must be Set(classFoo), if we evaluate this constraint on
    classBar, type of expression must be Set(classBar). Hence the type of expression can not be determined
    at "compile time", it must be determined at "run time".

    E.g. we have 2 classes classFoo and classBar; classFoo has a field someField, classBar doesn't.

    context whatever inv:
    let s:Set(Classifier) = Set

    {classFoo, classBar} in
    s->allInstances()>any(true)>any(true).someField = someValue


    Now what is the type of s->allInstances()>any(true)>any(true) expression?
    We have:
    expression |expression type |expression value
    ---------------------------------------------------------------------------------
    s |Set(Classifier) |Set{classFoo, classBar}

    s->allInstances() |Set(Set(???)) |Set

    { Set_of_instances_of_classFoo, Set_of_instances_of_classBar}

    s->allInstances()->any(true) |Set(???) |either Set_of_instances_of_classFoo or Set_of_instances_of_classBar
    s->allInstances()>any(true)>any(true) |???? |either instance of classFoo or instance of classBar

    Now the question arises: can we access someField property?
    Here we must have a runtime introspection check in the OCL evaluation code -
    if s->allInstances()>any(true)>any(true) returned instance of classFoo,
    we can access the field, if instance of classBar - we must runtime-fail here.

    Please advise. Is this a problem of the spec or I am wrong somewhere?

    Granted, we are making jumps 2 levels down in metamodel hierarchy here
    (first from metamodel to model elements-classes, then from classes to instances of those classes),
    but there is nothing in the spec, what precludes this.

  • Reported: OCL 2.0 — Mon, 11 Jun 2007 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

missing closing parethesis inthese two expressions

  • Key: OCL21-291
  • Legacy Issue Number: 11086
  • Status: closed  
  • Source: YMS ( Peter Klein)
  • Summary:

    missing closing parethesis inthese two expressions: [2]The parameters of the referredOperation become attributes of the instance of MessageType. context MessageType: inv: referredOperation->size()=1 implies Set

    {1..self.ownedAttribute->size()}>forAll(i | self.ownedAttribute.at.cmpSlots( referredOperation.ownedParameter.asProperty()>at) [3]The attributes of the referredSignal become attributes of the instance of MessageType. context MessageType inv: referredSignal->size() = 1 implies Set{1..self.ownedAttribute->size()}

    >forAll(i | self.ownedAttribute.asOrderedSet().at.cmpSlots( referredSignal.ownedAttribute.asOrderedSet()>at)

  • Reported: OCL 2.0 — Thu, 31 May 2007 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

8.2.2 Well-formedness Rules for the Types Package

  • Key: OCL21-290
  • Legacy Issue Number: 11085
  • Status: closed  
  • Source: YMS ( Peter Klein)
  • Summary:

    Thhis expression context TupleType inv: TupleType.allInstances()>forAll (t | ( t.allProperties()>forAll (tp | – make sure at least one tuplepart has the same name – (uniqueness of tuplepart names will ensure that not two – tupleparts have the same name within one tuple) self.allProperties()>exists(stp|stp.name = tp.name) and – make sure that all tupleparts with the same name conforms. self.allProperties()>forAll(stp | (stp.name = tp.name) and stp.type.conformsTo(tp.type)) ) implies self.conformsTo(t) ) ) should be context TupleType inv: TupleType.allInstances()>forAll (t | ( t.allProperties()>forAll (tp | – make sure at least one tuplepart has the same name – (uniqueness of tuplepart names will ensure that not two – tupleparts have the same name within one tuple) self.allProperties()>exists(stp|stp.name = tp.name) and – make sure that all tupleparts with the same name conforms. self.allProperties()>forAll(stp | (stp.name = tp.name) implies stp.type.conformsTo(tp.type)) ) implies self.conformsTo(t) ) ) it means "implies" instead of "and" in this part: (stp.name = tp.name) and stp.type.conformsTo(tp.type)

  • Reported: OCL 2.0 — Thu, 31 May 2007 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Usage of initialization and derivation constraints on the same property

  • Key: OCL21-289
  • Legacy Issue Number: 10969
  • Status: closed  
  • Source: International Business Machines ( Andreas Maier)
  • Summary:

    The OCL 2.0 spec seems to allow usage of initialization constraints
    and derivation constraints on the same property. For example in
    7.3.7, it says "Initial and derivation expressions may be mixed
    together after one context.", which is a string indication that it is
    not precluded. Having both initialization and derivation constraints
    is an overspecification of the initial value of the property, since
    the derivation constraint must be satisfied at any time, which
    probably includes the initialization time.

    Also, the spec does not seem to contain a statement about how many
    initialization and derivation constraints are allowed on a property.
    By the nature of these constraints, it seems sensible to have at most
    one of them.

    The following clarifications are suggested to address this issue:
    (1) clarify whether "at any time" for derivation constraints
    includes the initialization. Suggestion: Derivation should include
    initialization.
    (2) clarify whether both kinds of constraints are allowed on the
    same property. Suggestion: Both are allowed but must not be
    contradictory.
    (3) clarify how many initialization and derivation constraints are
    allowed on a property. Suggestion: At most one initialization
    constraint and at most one derivation constraint.

  • Reported: OCL 2.0 — Wed, 25 Apr 2007 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Collection element type serialization

  • Key: OCL21-288
  • Legacy Issue Number: 10946
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The OCL abstract syntax for Collections has no property to persist the element type
    of the collection.

    It is therefore not possible to serialise a TypeExp.referredType referring to
    for example OrderedSet(String) without synthesising an
    OrderedSet_String and finding some artificial scope for it .. and then encountering
    ambiguities as to whether two distinct OrderedSet_String types are really distinct.

    Suggest:

    Introduce a CollectionTypeExp extending TypeExp to add
    CollectionTypeExp.referredElementType : Type[0..1]
    with the constraint that the inherited TypeExp.referredType be a collection type.

  • Reported: OCL 2.0 — Mon, 26 Mar 2007 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

TypeType

  • Key: OCL21-287
  • Legacy Issue Number: 10921
  • Status: closed  
  • Source: Hendryx & Associates ( Stan Hendryx)
  • Summary:

    I would like to log the following issue against OCL formal/06-05-01.

    TypeType, appearing on Fig. 8.1 (p.34), Fig. 13.1 (p.172), and section
    11.3.2 (p.140) is not defined

  • Reported: OCL 2.0 — Mon, 16 Apr 2007 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

ownership of association ends does not matter for traversal in OCL

  • Key: OCL21-286
  • Legacy Issue Number: 10825
  • Status: closed  
  • Source: International Business Machines ( Andreas Maier)
  • Summary:

    during work on the definition of the UML Profile for CIM (an activity
    performed jointly between OMG and DMTF), we recently found the following
    issue with OCL 2. Please record this issue officially and let me know the
    issue number for it.

    Issue: No explicit statement that ownership of association ends does not
    matter for traversal in OCL
    Nature: Clarification
    Severity: Minor
    Summary:

    The UML Superstructure spec 2.1.1 defines in section 6.5.2 "Diagram
    Format" that any meta-association has two ends, regardless of whether
    the ends are owned by the association or the associated classifiers.
    However, the Superstructure spec only describes those association
    ends that are owned by the associated classifiers. Furthermore, a
    major OCL engine (from Eclipse) does not currently support
    meta-association traversal in OCL towards ends owned by the
    meta-association.

    This may leave the impression to some readers that OCL would only
    support meta-association traversal in the direction of ends owned by
    the associated classifiers.

    I understand that the intention is in OCL to support traversal of
    meta-associations in any direction, regardless of whether the target
    end is owned by the association or the associated classifier. It
    would be helpful to state that explicitly in the OCL specification.

  • Reported: OCL 2.0 — Sat, 17 Mar 2007 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Naming of Constraints in OCL

  • Key: OCL21-285
  • Legacy Issue Number: 10782
  • Status: closed  
  • Source: Dell Technologies ( George Ericson)
  • Summary:

    I find in the OCL document section "7.3.3. Invariants" that I can name an invariant as in:

    "context" <contextdeclaration> "inv" <constraintname> ":" ...

    I haven't figured out how to parse the document well enough to be clear if this is formally defined.

    And the real question is whether this applies to pre, post, body, init, and derived constraints.

    Does it?

    If not it would be useful to add.

  • Reported: OCL 2.0 — Thu, 8 Feb 2007 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

11.7.1

  • Key: OCL21-284
  • Legacy Issue Number: 10438
  • Status: closed  
  • Source: NIST ( Peter Denno)
  • Summary:

    null "conforms to all other types." Thus I suppose null->isEmpty() and
    null->notEmpty() are defined. What do these methods evaluate to when applied
    to null? This should be discussed in this section.

  • Reported: OCL 2.0 — Thu, 2 Nov 2006 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

11.2.5 (02)

  • Key: OCL21-283
  • Legacy Issue Number: 10437
  • Status: closed  
  • Source: NIST ( Peter Denno)
  • Summary:

    oclAsType(typespec : OclType) : T
    "Evaluates to self, where self is of the type identified by typespec.
    post: (result = self) and result.oclIsTypeOf(typeName)

    (BTW , that ought to be "typespec" not typeName).

    This description is inadequate. The text in 7.4.6 describes the important
    condition on the use of this method ("An object can only be re-typed to one
    of its subtypes.") But chapter 7 is informative, not normative. Even with
    that text moved into 11.2.5, additional discussion is required. For example,
    referring to the properties that are only defined on the subtype, what would
    the value of those properties be, once the object is re-typed?

  • Reported: OCL 2.0 — Thu, 2 Nov 2006 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

11.2.5

  • Key: OCL21-282
  • Legacy Issue Number: 10436
  • Status: closed  
  • Source: NIST ( Peter Denno)
  • Summary:

    oclIsTypeOf(typespec : OclType) : Boolean
    "Evaluates to true if the self is of the type identifid by typespec.."
    oclIsKindOf(typespec : OclType) : Boolean
    "Evaluates to true if the self conforms to the type identified by typespec"

    >From those descriptions I cannot distinguish these two. Isn't a dog "of the
    type" mammal" and wouldn't a dog "conform to the type" mammal? (Subtypes
    always conform to the supertype).

    I suspect that you intend that one of these evaluates to TRUE if and only if
    self is of type typespec and not also of a subtype of typespec . You might
    say just that.

  • Reported: OCL 2.0 — Thu, 2 Nov 2006 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

11.8.1

  • Key: OCL21-281
  • Legacy Issue Number: 10435
  • Status: closed  
  • Source: NIST ( Peter Denno)
  • Summary:

    "When new iterator expressions are added to the standard library, there
    mapping to existing constructs should be fully defines.

    • What does that mean? It sounds like an admonition to spec writers.
    • also "defined" not "defines"
    • also "their" not "there"
  • Reported: OCL 2.0 — Thu, 2 Nov 2006 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

11.2.4 (OclInvalid) - similar criticism as 11.2.3

  • Key: OCL21-280
  • Legacy Issue Number: 10434
  • Status: closed  
  • Source: NIST ( Peter Denno)
  • Summary:

    11.2.4 (OclInvalid) - similar criticism as 11.2.3 (issue 10433)

  • Reported: OCL 2.0 — Thu, 2 Nov 2006 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

11.2.3

  • Key: OCL21-279
  • Legacy Issue Number: 10433
  • Status: closed  
  • Source: NIST ( Peter Denno)
  • Summary:

    "The type OclVoid is a type that conforms to all other types. It has one
    single instance called null which corresponds with the UML Null Literal value
    specification. "

    This text could be clearer. What does "called null" mean? Is it saying that
    the name "null" refers to this instance? A suggested rewrite: "It has one
    instance, identified by 'null.' The instance null corresponds to the UML Null
    Literal."

  • Reported: OCL 2.0 — Thu, 2 Nov 2006 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section "IteratorExpCS"

  • Key: OCL21-278
  • Legacy Issue Number: 10432
  • Status: closed  
  • Source: NIST ( Peter Denno)
  • Summary:

    There is a left-paren in rule [A] . Rules [D] and [E] are identical.

  • Reported: OCL 2.0 — Thu, 2 Nov 2006 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section 9.2.2

  • Key: OCL21-277
  • Legacy Issue Number: 10431
  • Status: closed  
  • Source: NIST ( Peter Denno)
  • Summary:

    "The OCL specification puts no restriction on visibility."

    I don't think this statement is true. For example, self is bound to the
    instance in context. There is a whole prior section on scoping.

  • Reported: OCL 2.0 — Thu, 2 Nov 2006 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section 7.6.3

  • Key: OCL21-276
  • Legacy Issue Number: 10430
  • Status: closed  
  • Source: NIST ( Peter Denno)
  • Summary:

    "The forAll operation has an extended variant in which more than one iterator
    is used. Both iterators..."

    Which is it "more than one" (two, three...) or "Both" (two) ?

  • Reported: OCL 2.0 — Thu, 2 Nov 2006 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: 7.8

  • Key: OCL21-275
  • Legacy Issue Number: 10346
  • Status: closed  
  • Source: None (Graduate from MSC Univ of Brighton UK looking for job) ( Guillaume Finance)
  • Summary:

    Hello I recently wrote a comment about the OCL keyword list to amend if I'm correct. As I continue reading through the specification, I found that in "7.8 Resolving Properties", 2 inv contraints are specified and mentionned to have a different meaning. I specified the difference between the 2 below and was wondering if you wanted maybe to check that 1. it was correct and 2. add it to the specs so people can make sure they understand well where the difference stands, despite it is fairly straightforward from the explanation in this chapter. >From your specs: context Person inv: employer->forAll(employee->exists(p | p.lastName = name)) inv: employer->forAll(employee->exists(self.lastName = name)) Given explanation on the difference: Invariant constraint 1: Specifies that in the Company a person works for, there exists for all the employees of the company (Person instances) the value of their attribute lastName matching the value of the attibute Name in an instance of Company Invariant constraint 2: Specifies that in the Company a person works for, there exists for all the employees of the company (Person instances) the value of the person's attribute lastName matching the value of the attibute Name in an instance of Company iterator The difference is that in the invariant 1, we specify that the value of the lastName attribute for all the Person instances employed by a company must be found in an instance of the Company by matching the name attribute's value, whereas in the invariant 2, we specify that the value in the lastName attribute of a Person p working for a Company must match the value of the name's attribute in one of the Company's set of Person/employees, thus its related instance. I hope it makes sense and look forward hearing about your comments.

  • Reported: OCL 2.0 — Tue, 12 Sep 2006 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: 7.4.9

  • Key: OCL21-274
  • Legacy Issue Number: 10344
  • Status: closed  
  • Source: None (Graduate from MSC Univ of Brighton UK looking for job) ( Guillaume Finance)
  • Summary:

    Hi, I'm reading through the latest OCL spec to get up to date before applying for a System Analyst job, I saw a possible minor issue in the list of the OCL keywords. Indeed, having read it so far, I would add the following ones but pls let me know if there is a reason why it wouldnt apply: body, derive, init, and self

  • Reported: OCL 2.0 — Mon, 11 Sep 2006 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Using "def"

  • Key: OCL21-273
  • Legacy Issue Number: 9915
  • Status: closed  
  • Source: LIANTIS GmbH ( Constantin Szallies)
  • Summary:

    Using "def" I would like to specify static (classifier scoped) properties and operations.

  • Reported: OCL 2.0 — Tue, 11 Jul 2006 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

have tuple fields and let variables to have the declaration of their types explicity?

  • Key: OCL21-352
  • Legacy Issue Number: 13537
  • Status: closed  
  • Source: Anonymous
  • Summary:

    have tuple fields and let variables to have the declaration of their types explicity?

  • Reported: OCL 2.0 — Fri, 20 Feb 2009 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

type of the iterator variable is expected or not?

  • Key: OCL21-351
  • Legacy Issue Number: 13536
  • Status: closed  
  • Source: Imdea Software ( Miguel Angel Garcia de Dios)
  • Summary:

    I wrote an issue similar than this one but not equal so, the body could seem equal but it is not the case. I have a few doubts about the iterator variables. Reading the specification I am not sure about, for each iterator, if the type of the iterator variable is expected or not. For example: collection->select( v : Type | boolean-expression-with-v ) collection->select( v | boolean-expression-with-v ) Looking at sections 7.6 and 11.9 my conclusion is the following: -select --> It is NOT obligatory to write the type of the iterator variable. It appears in section 7.6. -reject --> It is NOT obligatory to write the type of the iterator variable. It appears in section 7.6. -collect --> It is NOT obligatory to write the type of the iterator variable. It appears in section 7.6. -forAll --> It is NOT obligatory to write the type of the iterator variable. It appears in section 7.6. -exists --> It is NOT obligatory to write the type of the iterator variable. It appears in section 7.6. -iterate --> In section 7.6 it seems that in both, for the iterator variable and for the accumulator variable, it is obligatory to write the type. -collectNested --> It is NOT obligatory to write the type of the iterator variable. It is a similar case than the collect. -one --> It is NOT obligatory to write the type of the iterator variable. -any --> It is NOT obligatory to write the type of the iterator variable. -isUnique -->It is NOT obligatory to write the type of the iterator variable. Is my conclusion correct in everything? or in which parts am I confused? I think that both, iterator variable and accumulator variable of the iterate iterator should have their types optional. In other words, to write the type of the iterator variable or the type of the accumulator variable should not be obligatory.

  • Reported: OCL 2.0 — Fri, 20 Feb 2009 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    It is clear from the various examples in Section 7 that the type declaration of the iterator is optional in collection operations. By default VariableDeclarationCS is defined so that the type of the variable declared is optional.

    Disposition: Close, no change

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

doubts about the iterator variables

  • Key: OCL21-350
  • Legacy Issue Number: 13535
  • Status: closed  
  • Source: Imdea Software ( Miguel Angel Garcia de Dios)
  • Summary:

    I have a few doubts about the iterator variables. Reading the specification I am not sure about, for each iterator, how many iterator variables can have. Looking at sections 7.6 and 11.9 my conclusion in the following: -select --> It has zero or one iterator variables. (0..1) -reject --> It has zero or one iterator variables.(0..1) -collect --> It has zero or one iterator variables.(0..1) -forAll --> There is no restriction about the number of iterator variables. (0..) -exists --> Unlike forAll, in section 7.6 there is no text saying anything about the number of variables. But in section 11.9 it seems that it is the same case that forAll. (0..) -iterate --> It has one iterator variable. -collectNested --> It has zero or one iterator variables.(0..1) -one --> It has zero or one iterator variables.(0..1) -any --> It has zero or one iterator variables.(0..1) -isUnique -->It has zero or one iterator variables.(0..1) Is my conclusion correct in everything? or in wich parts am I confused? How can the most of the iterators be defined by the iterate iterator if iterate iterator can have only one variable iterator? I think the iterate iterator should not have restrictions about the number of iterator variables (0..*).

  • Reported: OCL 2.0 — Fri, 20 Feb 2009 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

The following collection operations would be useful for the HL7 GELLO project:

  • Key: OCL21-349
  • Legacy Issue Number: 13077
  • Status: closed  
  • Source: InferMed Ltd ( Craig Lucas)
  • Summary:

    The HL7 GELLO project would find it useful to have additional collection operators in OCL. A method to define these in the underlying model would be good. Alternatively, we request the addition of the following operations:

    max, min: To determine the maximum or minimum value in a collection

    firstN: Returns a sequence with the first n elements of this sequence

    lastN: Returns a sequence with the last n elements of this sequence

    reverse: Returns a sequence in reverse order

    join(namesOfCollections; namesOfProperties; booleanExpression; orderByExpression)

    Where:

    • namesOfCollections is a list of strings separated by commas, where each

    string represents the name of a collection from where data is retrieved.

    • namesOfProperties is a list of strings separated by commas, where each

    string is the full description of the properties from the objects in the

    collections we want to get in the result.

    • booleanExpression is a valid boolean expression containing the

    conditions the elements from the collections defined in listOfCollections

    must satisfy in order to be included in the result

    • booleanExpression is a valid boolean expression containing the

    conditions the elements from the collections defined in listOfCollections

    must satisfy in order to be included in the result

    average: Calculate the average value in a collection

    stdev: Calculate the standard deviation of a collection

    variance: Calculate the variance of a collection

    median: Calculate the median of a collection

    mode: Calculate the mode of a collection

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

    No Data Available

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

The concrete syntax given is extremely difficult to implement

  • Key: OCL21-348
  • Legacy Issue Number: 13076
  • Status: closed  
  • Source: InferMed Ltd ( Craig Lucas)
  • Summary:

    The concrete syntax given is extremely difficult to implement, as documented in several places, including University of Dresden http://dresden-ocl.sourceforge.net/papers/ParserDesign.pdf Many languages have a syntax specified in a machine-readable form, (e.g. lex/yacc format). A standard, working, syntax for OCL would be very useful.

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

    Disposition: See issue 10439 for disposition

  • 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

Use of simple quotes and double quotes in strings

  • Key: OCL21-346
  • Legacy Issue Number: 12952
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Summary: Use of simple quotes in place of double quotes should be allowed,
    Specially in situations where the string contains double quotes (to avoid explicit
    use of escaping characters).

  • Reported: OCL 2.0 — Fri, 10 Oct 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The freedom to use single or double quotes risks causing confusion for novices as well as being helpful. OCL is the basis for extended languages which may have their own usage for double quotes, so extending OCL into this syntax area seems unwise.
    Disposition: Closed, no change

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

Use of MOF reflection in EssentialOCL should be clarified

  • Key: OCL21-345
  • Legacy Issue Number: 12951
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Summary: There is no clear indication weather MOF reflection is available
    in EssentialOCL (except in the provided xmi, ecore files of essential ocl).

  • Reported: OCL 2.0 — Fri, 10 Oct 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The BasicOCL/EssentialOcl cannot merge EMOF reflection since we have conflict in metaclasses. The role of Object is played by AnyType. At M1 level, OCL has its own reflection mechanism. A clarification sentence is added.

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

No way to represent type parameters in the standard library

  • Key: OCL21-344
  • Legacy Issue Number: 12950
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Summary: The OCL metamodel does not provide means to encode type parameters
    in operations like the generic ones that are defined by Collection type in the standad library.

  • Reported: OCL 2.0 — Fri, 10 Oct 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Adding a TemplateParameterType. This promotes the solution to this problem as found in QVT.

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

Incosistency between UnlimitedInteger and UnlimitedNatural

  • Key: OCL21-343
  • Legacy Issue Number: 12949
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Summary: In Figure 8.6 we have UnlimitedNatural but in other parts of the spec there is
    a UnlimitedInteger definition.

  • Reported: OCL 2.0 — Fri, 10 Oct 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Making OclAny denote any object

  • Key: OCL21-342
  • Legacy Issue Number: 12948
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Summary: In the actual OCL2 spec OclAny represents any object except collections.
    However this is unaligned with UML2 and MOF2 where such kind of type does not exist
    Instead in MOF we have the generic Object which represents any object including
    primitive and collection values.
    Also, looking at the list of operations defined for OclAny we see that there is no real
    justification for creating this special type. Operations like 'allInstances' and 'oclIsNew' are
    also invalid for primitive types and hence are not specifically invalid for collections.
    Making OclAny to represent any object (equivalent to MOF::Object) will simplify the stdlib
    and will be consistent with UML2 and MOF2.

  • Reported: OCL 2.0 — Fri, 10 Oct 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    OclAny denotes now any object including collections. This makes the type system aligned with MOF.

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

Clarify the common supertype of Bag and Sequence

  • Key: OCL21-341
  • Legacy Issue Number: 12947
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Summary:
    Does an OrderedSet conforms to a Set? Does an OrderedSet conforms to a Sequence?
    It seems that there is no automatic conformance between these concrete collection
    types (hence an explicit conversion need to be done when needed)
    However, for clarification, this should be stated in the definition of the respective concrete
    collection types to avoid OCL writers making wrong assumptions.

  • Reported: OCL 2.0 — Fri, 10 Oct 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Adding clarification sentences

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

The operation asSet, asSequence, asBag and asOrderedSet missing for OrderedSets

  • Key: OCL21-340
  • Legacy Issue Number: 12946
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    The operation asSet, asSequence, asBag and asOrderedSet are not defined for
    OrderedSets in 11.7.3. Also, since these operations are available in all collections
    we would expect their definition at Collection level.

  • Reported: OCL 2.0 — Fri, 10 Oct 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Disposition: See issue 4451 for disposition

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

Missing definition of of iterators for OrderedSets

  • Key: OCL21-339
  • Legacy Issue Number: 12945
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Summary:Since the iterators are redefined for each concrete collection type
    We would expect a "11.9.5 OrderedSet" section.
    Moreover, when defining nestedCollect for OrderedSet we should expect the type
    to be a Sequence (in constrast to Set::nestedCollect which type is a Bag).

  • Reported: OCL 2.0 — Fri, 10 Oct 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The missing operations are added. Notice that the list of operations is the union of those supported by sequences and those supported by sets.

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

Type of a type expression

  • Key: OCL21-338
  • Legacy Issue Number: 12944
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    In the TypeExp definition (within section 8.3) there is no indication of what is the
    type returned by a type expression. Is it the generic object representing all types
    (oclType) or the referred type itself?
    We guess it is the referred type itself, but this need to be explicitly stated.

  • Reported: OCL 2.0 — Fri, 10 Oct 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Disposition: See issue 9171 for disposition

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

OCL 2.0: CollectionType constraint for invalid elements is incorrect

  • Key: OCL21-337
  • Legacy Issue Number: 12943
  • Status: closed  
  • Source: Zeligsoft, Inc. ( Christian Damus)
  • Summary:

    The second constraint on CollectionType in Section 8.2.2 does not make
    sense. The instances of CollectionType are not collections, but the
    types of collections. Thus, a collection type does not have elements
    to be iterated. This constraint should be struck from Section 8.2.2:

    [1] A collection cannot contain OclInvalid values.
    context CollectionType
    inv: self->forAll(not oclIsInvalid())

    and replaced by a new invariant constraint in Section 11.7.1
    “Collection” (which currently has no well-formedness rules):

    [1] A collection cannot contain OclInvalid values.
    context Collection
    inv: self->forAll(not oclIsInvalid())

  • Reported: OCL 2.0 — Thu, 9 Oct 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    As OCL does not permit the invalid value in a collection (as opposed to the null value), it should be made explicit that the evaluation of collection literals containing invalid results in invalid. The CollectionType constraint in Section 8.2.2 attempts to express this, but is incorrect because it is defined on the wrong meta-level (on CollectionType instead of Collection).

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

OCL 2.0 8.2 Collection Type packaging

  • Key: OCL21-336
  • Legacy Issue Number: 12582
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    [Pending a resolution of Issue 10946]

    In order to use a collection type, it is is necessary to define that
    type and provide some container for it. OCL provides no guidance on
    what that container should be, or upon what the relative semantics of
    A::Set(E) is with respect to B::Set(E).

    QVT 1.0 has defined all CollectionType(ElementType) to be the same type
    regardless of the accidental package used for their containment.

    OCL should adopt the QVT definition (even if 10946 is adopted).

  • Reported: OCL 2.0 — Sat, 19 Jul 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Resolution of issue 9171 contains an statement saying that collection instances may be in different containers and still represent the same type.

    Disposition: See issue 9171 for disposition

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

Section: A.3.2.2 Syntax and Semantics of Postconditions

  • Key: OCL21-335
  • Legacy Issue Number: 12493
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    In the paragraph before Definition A.32 you will find, "An environment p = (s, ß is a pair ...." The closing paren. after ß is missing

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

    No Data Available

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

Section: A.3.1.2 Semantics of Expressions

  • Key: OCL21-334
  • Legacy Issue Number: 12491
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    It would be nice to have a definition of ß{x / y) in association with Definition A.30. Maybe it's defined elsewhere, but I don't see it. From what's written in this section, including the explanation of iteration on page 205 and 206, I get only a vague idea. P.S. So realizing now that this is not a typo, my revision request two previous to this (if I've counted correctly) should be ignored. That was the one about part ii of Definition A.30.

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

    The notation "\" is the standard notation for substitution (e.g., see Winskel's book
    on formal semantics). Thus, there seems to be no need to add an explanation in
    the standard.

    Disposition: Closed, no change

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

Section: A.2.5.8 Sequence Operations

  • Key: OCL21-333
  • Legacy Issue Number: 12490
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    In the flattening expressions there are the expressions "C1 fg" and "Bag fg". These seem to stand for the creation of a new, empty collection and bag respectively. If these expressions are what was intended it would be nice to have a note explaining what they mean. I wasn't able to find any explanations or previous use of "fg".

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

    The "fg" (in both occurrences) must be replaced by "{}" (a pair of curly braces).

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

Section: A.3.1.2 Semantics of Expressions, Definition A.30 part ii

  • Key: OCL21-332
  • Legacy Issue Number: 12489
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    Definition A.30, part ii says "I[[let v = e1 in e2]](r) = I[[e2]](s, ß

    {v / I[[e1]](r)}

    )." Maybe the problem is my ignorance of the meaning of the / in that expression as well as the meaning of the notation "ß

    {...}

    ". I would have expected instead something like, "... = I[[e2]](s, ß U

    {v = I[[e1]](r)}

    )."

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

    Disposition: See issue 12488 for disposition

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

Section: A/1.1.6 Generalization

  • Key: OCL21-301
  • Legacy Issue Number: 12443
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    At the top of page 182 there are 3 definitions, all of which have the index domain, i.e. C' an element of parents(c), in the wrong place horizontally. In the first two it appears to be associated with the small union symbol, rather than with the large one as it should be. In the third it seems not to be associated with anything in particular. Additionally, in the first line on the page there is an extraneous underscore in the name of the object of the first definition.

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

    No Data Available

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

Section: A/1.1.5 Associations

  • Key: OCL21-300
  • Legacy Issue Number: 12442
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    In the definition of "navends" the symbol for "and", which was a nice looking capital lambda in previous definitions, is here a more traditional, at least in my mind, "and" sign. Consistency would be nice

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

    No Data Available

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

Section: A/1.1.5 Associations -- missing word

  • Key: OCL21-299
  • Legacy Issue Number: 12441
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    Between the definitions of "participating" and "navends" is a sentence that, "The following function navends give ...." The s is missing on "gives". It should instead read, "The following function navends gives ...."

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

    No Data Available

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

Section: A/1.1.5 Associations

  • Key: OCL21-298
  • Legacy Issue Number: 12440
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    The next to last line of Definition A.4 begins, "that associates (sa) = <oc, c>." I think this should read instead, "that associates (sa) = <c, c>." If I am mistaken, then a note to remind the reader what "oc" means would be helpful, as would a note describing why the classes are not the same.

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

    No Data Available

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

Section: A/1.1.1 Types

  • Key: OCL21-297
  • Legacy Issue Number: 12439
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    The following grammatically incorrect sentence is present in the document: All type domains include an undefined value that allows to operate with unknown or “null” values. This could be corrected in various ways, a couple of which would be: All type domains include an undefined value that allows one to operate with unknown or “null” values. or All type domains include an undefined value that allows operations with unknown or “null” values.

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

    No Data Available

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

last line on page 28

  • Key: OCL21-296
  • Legacy Issue Number: 12438
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    The last line on page 28 is an example in Java-like code that is supposed to show the accumulation of values into a Bag. The line currently is acc = <expression-with-elem-and-acc> Since such an assignment would not add to the Bag, but more likely produce a compile error in Java, I would think use of the common method name "add" would be more appropriate: acc.add(<expression-with-elem-and-acc>);

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

    No Data Available

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

CollectionType and CollectionKind

  • Key: OCL21-295
  • Legacy Issue Number: 12419
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The abstractness of CollectionType and corresponding existence of the Collection CollectionKind is inconsistent:

    9.3 collectionTypeCS synthesized attributes, page 79, contains:

    kind = CollectionKind::Collection implies collectionTypeCS.ast.oclIsKindOf(CollectionType)

    using CollectionKind::Collection.

    8.3.5 CollectionKind, page 48, Collection is not one of the enumeration values.

    11.6.1, page 144, specifies that Collection is an instance of CollectionType
    requiring Collection to not be abstract.

    8.2 CollectionType, page 34, CollectionType is identified as an abstract class.

    An expression like the following is valid:

    context Package
    def getClasses() : Set(Class) =
    let c : Collection(Type) = self.ownedType in
    c->select(oclIsKindOf(Class))->asSet()

    and demonstrates the need for a concrete CollectionType.

    Recommendation:

    Collection should not be abstract; change Fig 8.1, 8.2 CollectionType text.
    CollectionKind requires a Collection value; change Fig 8.7, 8.3.5 CollectionKind.

  • Reported: OCL 2.0 — Sat, 19 Apr 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section 8.2 InvalidType

  • Key: OCL21-294
  • Legacy Issue Number: 12378
  • Status: closed  
  • Source: Steria Mummert Consulting AG ( Torsten Binias)
  • Summary:

    For the InvalidType it is stated that: "The only instance of InvalidType is Invalid, which is further defined in the standard library. Furthermore Invalid has exactly one runtime instance called OclInvalid." It should read: "The only instance of InvalidType is OclInvalid, which is further defined in the standard library. Furthermore OclInvalid has exactly one runtime instance called invalid." because this is in line with ch. 11.2.4, p. 138:"It [OclInvalid] has one single instance called invalid. [...] OclInvalid is itself an instance of the metatype InvalidType

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

    No Data Available

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

OrderedSet collection

  • Key: OCL21-309
  • Legacy Issue Number: 12451
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The OrderedSet collection is a later adjunction with respect to previous versions of OCL. However, it has not been systematically introduced in all relevant places. As one example among many, conformance rules in Table 7.3 (p.12) do not include OrderedSet. Also, the semantics defined in Appendix A should be extended to include OrderedSet. By the way, there is no place where the difference between OrderedSet and Sequence is discussed. From my understanding, they are much like the same concept. If it is not the case, the differences must be explicitly stated.

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

    No Data Available

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

The Tuple constructor is problematic

  • Key: OCL21-308
  • Legacy Issue Number: 12450
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The Tuple constructor is problematic. It is not a first-class citizen in the specifications. It appears in many parts but it is not formally introduced.

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

    No Data Available

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

no explanations about how to manipulate optional and multivalued attributes

  • Key: OCL21-307
  • Legacy Issue Number: 12449
  • Status: closed  
  • Source: Anonymous
  • Summary:

    There are no explanations about how to manipulate optional and multivalued attributes. On the other hand optional and multivalued associations are discussed in detail. For example, while I can use context Person inv: self.job->notEmpty() implies ... to test "whether there is an object or not when navigating the association", I do not know how do a similar test for optional attributes. Is it context Person inv: self.maidenName <> `' implies ... or context Person inv: self.maidenName -> notEmpty() implies ... ?

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

    No Data Available

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

section 7.4.6 (p. 12)

  • Key: OCL21-306
  • Legacy Issue Number: 12448
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In section 7.4.6 (p. 12) it is said "An object can only be re-typed to one of its subtypes; ... If the actual type of the object is not a subtype of the type to which it is re-typed, the expression is undefined" While in section 7.5.8 (p. 19) it is said Whenever we have a class B as a subtype of class A, and a property p1 of both A and B, we can write: context B inv: self.oclAsType(A).p1 – accesses the p1 property defined in A self.p1 – accesses the p1 property defined in B and thus an example is shown where an object is retyped to its supertype. Both sections 7.4.6 and 7.5.8 should be joined into one. See slide 32 in my handouts to see a possible abstract of the joined section.

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

    The problem is fixed by resolution of issue 7341. Casting and accessing properties from a supertype are two different things.

    Disposition: See Issue 7341 for disposition

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

Section: A/2.2 Common Operations on All Types

  • Key: OCL21-305
  • Legacy Issue Number: 12447
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    This is another omission of the word "one", making the sentence grammatically incorrect. It is also useful to have an operation that allows to check whether an arbitrary value is well defined or undefined. should be "... allows one to ...." or "... allows the checking of whether ...."

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

    No Data Available

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

Section: A/1.2.4 System State

  • Key: OCL21-304
  • Legacy Issue Number: 12446
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    Definition 1.12 (System State) ends with "(the function pi(l) projects the ith component of a tuple or list l, whereas the function pi(l) projects all but the ith component):" Obviously the same notation can't mean opposite things, but what was intended here I don't yet know. Perhaps I will as I read on, but I thought I'd report this typo now so I don't forget.

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

    No Data Available

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

Section: A/1.2.1 Objects

  • Key: OCL21-303
  • Legacy Issue Number: 12445
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    In Definition A.10 Object Identifiers, part ii, you have the domain of a class c defined as: ICLASS(c') = U

    {oid(c) | c' ? CLASS ^ c' "gr<" c}

    . where I've used "gr<" for the generalization relation. I see 4 things that ought to be changed: 1. The initial c' should obviously be a c. 2. The oid(c) should be oid(c') 3. We have still another symbol for "and" 4. There's an extraneous newline before the final c.

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

    No Data Available

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

Section: A/1.1.6 Generalization - editorial issues

  • Key: OCL21-302
  • Legacy Issue Number: 12444
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    In WF-1 there is an "is an element of" sign missing just before the "ATT" in the first line. In WF-2, at a minimum, the first small omega should have a t-sub-1 a bit after it so that the sameness of arguments from t-sub-1 through t-sub-n is clear for both small omegas. Also the second colon is on the wrong side of the small omega. On the other hand, I'm not sure why you don't write it in the same form as WF-1, since it's a similar statement. I hope you can interpret my attempts to get by without sub and superscripts. Since the reader has already waded through WF-1, wouldn't it be more useful like this? ? (? : tc x t1 x …x tn ? t, ?' : tc' x t1 x …x tn ? t' ? OP*c) : (? = ?' => tc = tc' ? t = t')

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

    No Data Available

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

A.2.5.5 Collection Operations

  • Key: OCL21-316
  • Legacy Issue Number: 12469
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    In the paragraph under table A.3, toward the end, it says, "... count : Set(t) _ t ! Integer ...." These are the wrong symbols, of course. The underscore should be a cross and the ! should be an arrow. Also, just below this is the definition of I(count). This contains a 2 that should be a 0.

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

    Disposition: See Issue 12463 for disposition

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

Section: A/2.5.5 Collection Operations - just before table A.3

  • Key: OCL21-315
  • Legacy Issue Number: 12464
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    Just before Table A.3, is a sentence, "For this purpose, C, C, C2 ...." The second "C" should have a subscript "1" and the "C2" should have the 2 as a subscript.

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

    No Data Available

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

Section: A.2.5.5 Collection Operations

  • Key: OCL21-314
  • Legacy Issue Number: 12461
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    The 5th word of this section is "of" but was probably meant to be "on". Also, in Table A.3 in this section the entry in the second row, third column is pretty much unreadable because there are so many symbols written on top of each other. I checked this with Internet Explorer as well as Firefox, in case they affected Adobe Acrobat, but the entry looked equally bad in both.

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

    No Data Available

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

Section: A.2.5.2 Definition A.24 (Type Expressions)

  • Key: OCL21-313
  • Legacy Issue Number: 12460
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    This may not have been a problem with earlier versions of Adobe Acrobat/Reader but in looking at this section I see two typographical representations of "T-hat". The first two occurances are the letter T followed by a small circumflex substript. Subsequent occurances are a large circumflex followed by the letter T. It would be nice if this were fixed to be consistent, and even nicer if the circumflex could be placed over the T, as I imagine was intended.

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

    No Data Available

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

Section: Definition A.23 (Semantics of Navigation Operations)

  • Key: OCL21-312
  • Legacy Issue Number: 12459
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    Maybe I misunderstand, but it seems to me that L(as)(ci), as defined, has some problems: 1. "(c1, . . . , c i, . . . , c j , . . . , c n )" is undefined in that one doesn't know what it is, and 2. c is undefined in "sCLASS(c)". It seems to me that what you want is "L(as)(ci) =

    {cj | i ? j ? (c1, . . . , ci, . . . , cj , . . . , cn ) ? I-sub-ASSOC(as)}

    " - where the characters following the c's are subscripts and each such combination should be underlined to show that it is an object, - and where I-sub-ASSOC(as) is an italic I with a subscripted "ASSOC(as)".

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

    No Data Available

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

Section: A/2.3 Enumeration Types -- editorial

  • Key: OCL21-311
  • Legacy Issue Number: 12458
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    The last sentence of the page is missing the word "one" or, alternately, proper forms of the verbs "to follow" and "to retrieve". A correct form of this sentence would be, "Navigation operations: An object may be connected to other objects via association links. A navigation expression allows one to follow these links and to retrieve connected objects."

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

    No Data Available

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

The constraint [1] on the TupleLiteralPart metaclass is overconstrained

  • Key: OCL21-310
  • Legacy Issue Number: 12454
  • Status: closed  
  • Source: Zeligsoft, Inc. ( Christian Damus)
  • Summary:

    The constraint [1] on the TupleLiteralPart metaclass is overconstrained. It requires that the type of the value of a tuple literal part be identical to the corresponding attribute of the tuple type. However, the value type should only be required to conform to the attribute type because tuple literals may optionally specify the part types (in the same fashion as variable declarations). Thus, a more appropriate formulation of this constraint would be: context TupleLiteralPart inv: attribute.type.conformsTo(value.type )

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

    No Data Available

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

Section: A.3.1.2 Semantics of Expressions

  • Key: OCL21-331
  • Legacy Issue Number: 12488
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    Some problems with Definition A.30: 1. In the second sentence of Definition A.30 (Semantics of Expressions) it says, "I[[ e ]] : Env ? I(t)" but it seems instead that "I[[ e ]] : Exprt ? (Env ? I(t)). 2. It appears that r, which is not defined anywhere, is really supposed to be p. p, which is defined, only appears in part iv and it appears to be r there. 3. Also, it's confusing to use w in parts iii and iv since small omega (or script w maybe) is used previously. Further clarity would be added by putting empty parenthenes after omega in part iii to emphasize the fact that there are no arguments

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

    No Data Available

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

Section: A.3.1.1 Syntax of Expressions

  • Key: OCL21-330
  • Legacy Issue Number: 12487
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    Definition A.29 (Syntax of Expressions)part iii, (b) ends, "...and e2 to en the arguments." The n in "en" should be a subscript but is not.

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

    No Data Available

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

Section: A.2.7 Type Hierarchy

  • Key: OCL21-329
  • Legacy Issue Number: 12486
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    The first two sentences of Definition A.27 (Type Hierarchy) seem to have errors in them. The relation "less than or equal" seems to be represented by an underscore in the first sentence. In the second sentence 2 is used where the "is an element of" symbol was intended, 0 is used where a prime mark is intended, and c simply follows t and t0 (t prime) rather than being a subscript as intended.

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

    Replace the text of Section A.2.7 Type Hierarchy by the following text:

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

Section 8.2 page 35 InvalidType

  • Key: OCL21-328
  • Legacy Issue Number: 12485
  • Status: closed  
  • Source: Anonymous
  • Summary:

    InvalidType represents a type that conforms to all types. The only instance of InvalidType is Invalid, which is further defined in the standard library. Furthermore Invalid has exactly one runtime instance called OclInvalid. should be replaced by InvalidType InvalidType represents a type that conforms to all types. The only instance of InvalidType is OclInvalid, which is further defined in the standard library. Furthermore OclInvalid has exactly one runtime instance called invalid. This would follow the naming conventions and be in line with the notation for VoidType, OclVoid, null.

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

    Disposition: See issue 12378 for disposition

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

Section 8.2.1 Type Conformance on page 37

  • Key: OCL21-327
  • Legacy Issue Number: 12484
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Section 8.2.1 Type Conformance on page 37 [1] Invalid conforms to all other types. context InvalidType inv: Classifier.allInstances()>forAll (c | self.conformsTo (c)) on page 38 [1] Void conforms to all other types. context VoidType inv: Classifier.allinstances()>forAll(c | self.conformsTo(c)) on page 37 [6] The Conforms operation on Types is anti-symmetric context Classifier inv: Classifier.allInstances()> forAll(12,t2 | t1.conformsTo(t2) and t2.conformsTo(t1) implies t1 = t2) The first invariant yields Classifier.allInstances()>forAll (c | OclInvalid.conformsTo (c)) and thus OclInvalid.conformsTo (OclVoid) The second invariant yields Classifier.allInstances()->forAll (c | OclVoid.conformsTo (c)) and thus OclVoid.conformsTo (OclInvalid) Now the third invariant implies: OclInvalid = OclVoid

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

    No Data Available

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

Section: A.2.6.1 Definition A.26 (Special Types)

  • Key: OCL21-326
  • Legacy Issue Number: 12479
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    At the very end if this section it says "I(undefined) = ?." Shouldn't that be "I(undefined) = {?}."? Definition A.14 says the semantics maps each type to a set.

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

    No Data Available

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

Section: A.2.6 Special Types

  • Key: OCL21-325
  • Legacy Issue Number: 12478
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    The third bullet ends, "... as ? is an instance of every type." I don't know if the ? stands for OclAny, which isn't a member of the collection classes and so unlikely, or if ? is meant rather than ?. So I think this is an error.

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

    No Data Available

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

Syntax of Expressions (second sentence after Definition A..29)

  • Key: OCL21-324
  • Legacy Issue Number: 12477
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    The second sentence after Definition A.29 is "For all t’ < t: if e ? Exprt’ then e ? Exprt’ ." The last prime should be removed.

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

    No Data Available

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

Section: A.3.1.1 Syntax of Expressions (Definition A.29)

  • Key: OCL21-323
  • Legacy Issue Number: 12476
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    Definition A.29 (Syntax of Expressions), part vi reads it part, "... v1 ? Vart1, v2 ? Vart2, and ...." The first comma is a subscript along with the "t1" before it, the second one, that follows the "t2" subscript, isn't. Neither should be.

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

    No Data Available

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

Section: A.3.1.1 Syntax of Expressions

  • Key: OCL21-322
  • Legacy Issue Number: 12475
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    Definition A.29 (Syntax of Expressions), part v, appears to have several problems: 1. The symbol used for generalization is not what has always been used previously, see the two previous symbols in Definition A.10 part ii and in section A.1.2.2 just after it. 2. the first expression after the word "then", namely "(e asType t’) ? Exprt’" lacks a comma after it to separate it from the following expression. 3. I'm puzzled by the restrictions that t and t' must be related one way on the other. The restriction isn't strong enough to keep (e asType t’) from being undefined and seems unneeded for isTypeOf and isKindOf. A note here about this might help the reader. It would sure help me.

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

    Disposition: See issue 12474 for disposition

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

Section: A.3.1.1 Syntax of Expressions

  • Key: OCL21-321
  • Legacy Issue Number: 12474
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    Definition A.29 (Syntax of Expressions), part iii, b ends with, "and e2 to en the arguments." Here the 2 is a subscript as it should be but the "n" in "en" should also be a subscript and isn't.

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

    No Data Available

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

Section: A.2.5.8 Sequence Operations

  • Key: OCL21-320
  • Legacy Issue Number: 12473
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    There is one error in Table A.6 in the semantics column for the operation "first". The index should be 1, not i.

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

    No Data Available

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

Section: A.2.5.6 Set Operations Table A.4

  • Key: OCL21-319
  • Legacy Issue Number: 12472
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    Table A.4 has several rows in the Semantics column where a "union" symbol is used where an "intersection" symbol should have been used. These are rows 3, 4, 5, and 6. Table A.5 of section A.2.5.7 has the same problem in rows 3 and 4.

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

    No Data Available

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

Section: A.2.5.6 Set Operations

  • Key: OCL21-318
  • Legacy Issue Number: 12471
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    The second sentence of this section ends, "... B is a value of type t.". It should say "... B is a value of type Bag(t).

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

    No Data Available

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

There are two instances of missing and misplaced parentheses

  • Key: OCL21-317
  • Legacy Issue Number: 12470
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    There are two instances of missing and misplaced parentheses. One is near the bottom of page 195 in the definition of I(count). The line begins, "I(count : Bag)(t) x t ? Integer)". That last closing paren does not match anything. I believe the line should instead begin "(I(count) : Bag(t) x t ? Integer) The other is at the top of page 196. It is currently "I(count : Collection)(t) x t ? Integer)(c,v)" and, I believe, should be "(I(count) : Collection(t) x t ? Integer)(c,v)"

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

    Disposition: See Issue 12463 for disposition

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

Section: 8.3.5

  • Key: OCL21-271
  • Legacy Issue Number: 9913
  • Status: closed  
  • Source: LIANTIS GmbH ( Constantin Szallies)
  • Summary:

    The abstract syntax defines the classes NullLiteralExp and InvalidLiteralExp but the concrete syntax does not define these literal values. — I would like to return 'null' in certain OCL expressions for example: context Person::foo() : Person body: if age > 10 then self else null endif Currenty the only correct way to do this is not very straight forward: context Person::foo() : Person body: if age > 10 then self else OclVoid.allInstances()->any() endif The same is true for the singelton instance of OclUndefined.

  • Reported: OCL 2.0 — Tue, 11 Jul 2006 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: 7.3.4

  • Key: OCL21-270
  • Legacy Issue Number: 9796
  • Status: closed  
  • Source: none ( Jorge Bejar)
  • Summary:

    We consider a Sequence of instances of a class called 'Example'. This class has an integer attribute called 'ex'. If we have a method specification written as follow: pre: datalist->isTypeOf(Sequence(Example)) post: Sequence

    {1..datalist->size()}

    >forAll(n | datalist>at.ex = datalist@pre->at.ex) I not sure if is correct writes the same specification with the next sentences: pre: datalist->isTypeOf(Sequence(Example)) post: datalist->forAll(n | n.ex = n@pre.ex) The generic questions is: What does the '@pre' operator mean when it is applied to iterators variables (as 'n' in the example)? Is correct the @pre use in this cases? I hope you understand my dude and sorry any gramatical error because my written english is very poor.

  • Reported: OCL 2.0 — Sat, 27 May 2006 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Wrong subtyping of PropertyCallExp and NavigationCallExp

  • Key: OCL21-269
  • Legacy Issue Number: 9405
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    In section 8.3.2 of ptc/05-06-06 PropertyCall is shown as a subclass of NavigationCallExp -this seems the wrong way round: NavigationCallExp seems to be a specialization for when the Property is an AssociationEnd. To illustrate this, the description of NavigationCallExp starts with the following, which would not apply if the Property in question were an ownedAttribute of a class:
    "A NavigationCallExp is a reference to an AssociationEnd or an AssociationClass defined in a UML model."

  • Reported: OCL 2.0 — Tue, 28 Feb 2006 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

inability to uniquely reference association ends

  • Key: OCL21-268
  • Legacy Issue Number: 9404
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    Section 7.5.3 of ptc/05-06-06 starts with the following: "Starting from a specific object, we can navigate an association on the class diagram to refer to other objects and their properties. To do so, we navigate the association by using the opposite association-end:"

    However, unlike in UML 1.x, in UML2 this may well be ambiguous (since names of ends owned by Associations only have to be unique within the Association and not within the context of the Class).
    OCL should therefore explicitly allow qualification using the name of the Association itself as well as the end name (it is not clear whether this is currently allowed as part of the syntax for 'associationendname' so there should be an example to show this. This would make it consistent with the metamodel which allows reference to specific Properties.

    For example we could have associations A1 and A2 both linking classes C1 and C2 and each with ends c1 and c2 owned by the respective associations.
    OCL does not then address the fact that aC1.c2 is ambiguous - unlike the case with unnamed ends it does not even say that it may be ambiguous and is hence disallowed.
    However rather than disallowing the navigation OCL should have a syntax to allow qualification by the association name
    For example aC1.A1::c2

    The same could be used for missing association end names: If A1 had unnamed ends then one could use aC1.A1::C2

  • Reported: OCL 2.0 — Tue, 28 Feb 2006 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Introduction and oclType()

  • Key: OCL21-267
  • Legacy Issue Number: 9171
  • Status: closed  
  • Source: SAP SE ( Murray Spork)
  • Summary:

    I only recently joined the OCL rtf at the request of David Frankel (who
    is now with SAP) - I have not seen any activity on this mailing list as
    yet so I hope this is an appropriate forum to raise this question.

    First let me introduce myself - I am lead for a proof-of-concept project
    investigating the use of OCL to express integrity constraints on models.
    Hopefully I will get a chance next year to attend a f2f meeting so that
    I can meet you all.

    On to my specific question: we have noticed that some time between OCL
    1.1 and UML 1.4 "oclType", as a predefined feature, was removed. (I have
    been unable to find any versions of OCL between 1.1 and UML 1.4).

    I thought it would be best if we found out whether this removal was
    intentional before officially raising it as an issue. The reason is that
    we find a) this is a useful reflective feature to have and 2) it is
    still used in some current OMG specifications (note that it is used
    inconsistently).
    e.g.:

    • UML2 Infrastructure - (ptc/03-09-15) pg.89:
      Classifier::maySpecializeType(c : Classifier) : Boolean;
      maySpecializeType = self.oclIsKindOf(c.oclType)
    • Meta Object Facility (MOF) 2.0 Core Specification (ptc/03-10-04) -
      pg.68
      ExtentImpl::addObject(ObjectInstance o, String suppliedId
      [0..1]): String
      pre: not(self.entry.identifier includes suppliedId)
      post: oclIsNew(e) and oclType(e) = IdentifierEntry and
      e.object = o and
      self.entry includes e
      self.entry->select(ex | ex.identifier = e.identifier)->size() =
      1 – the new id is unique and
      (suppliedId <> null implies e.identifier = suppliedId)
  • Reported: OCL 2.0 — Sun, 13 Nov 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Circular imports

  • Key: OCL21-266
  • Legacy Issue Number: 8982
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Are two packages allowed to mutually import each other? I can't find
    anything preventing this in the spec, but was wondering if it causes
    some kind of "infinite" import loop.

  • Reported: OCL 2.0 — Sat, 27 Aug 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Notation for accessing class operations is inconsistent

  • Key: OCL21-265
  • Legacy Issue Number: 8937
  • Status: closed  
  • Source: International Business Machines ( Tracy Gardner)
  • Summary:

    The OCL 2.0 spec is inconsistent on whether class operations, including predefined operations, should be accessed using '.' or '::' notation.
    E.g. should it be Person.allInstances() or Person::allInstances()

    The spec uses Person.allInstances() in the text, but the concrete syntax specifies '::'.

    It seems that most tools have adopted the '.' notation used in the examples which is also backwards compatible with previous versions of OCL.
    There has also been some adoption of the '::' notation, for example in Warmer and Kleppe's OCL book, see: http://www.klasse.nl/english/boeken/ocl-book-errata.pdf

    Note: This issue was originally pointed out by Anthony Shuttleworth of Paranor.

    Proposed solution:

    The '.' notation is widely used and backwards compatible with previous versions of OCL. It should not be made invalid in OCL 2.0.
    It may be appropriate to also support the '::' notation if this has been widely adopted.

  • Reported: OCL 2.0 — Thu, 21 Jul 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Navigating across non navigable associations

  • Key: OCL21-264
  • Legacy Issue Number: 8918
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The spec ptc/03-10-14 lists navigating across non navigable associations as a compliance point. However, all text describing the rules for doing so have been removed from this version. The rules need to be defined more clearly in the OCL syntax.

    The following rules for navigation using non-navigable associations extend the text in sections 7.5.4 Navigation to Association Classes, and sections 7.5.5 Navigation from Association classes,

    When a non-navigable association is between different classes, following the association to an opposite end class is specified by:
    ("self" | <class name>) "." <association class name>["[" < opposite role name> "]"]"." <role name>

    Note the optional component is redundant, but is allowed, but not recommended.

    When a non-navigable association is between the same classes, following the association to an opposite end class is specified by:
    ("self" | <class name>) "." <association class name>"[" < opposite role name> "]." <role name>

  • Reported: OCL 2.0 — Fri, 8 Jul 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

allInstances

  • Key: OCL21-263
  • Legacy Issue Number: 8917
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    It is not entirely clear from the OCL 2.0 specification whether the allInstances operation returns instances of subclasses of the designated type. In other words, it isn't 100% clear whether t.allInstances( ) returns instances of subclasses of t.

    Recommendation:

    The best solution would be to have two operations, one which returns instances of subclasses and one which does not.

    A second-best solution would be to make it clear that allInstances returns instances of subclasses. In this case, an OCL programmer could use the oclIsTypeOf( ) operation as a filter to write a derived operation that does not return instances of subclasses. If allInstances does not return instances of subclasses, it would not be nearly as straightforward to write a derived operation that does return instances of subclasses.

  • Reported: OCL 2.0 — Tue, 12 Jul 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

The spec does not describes the syntax of integer, real or string literals

  • Key: OCL21-262
  • Legacy Issue Number: 8789
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    1) The specification does not describes the syntax of integer, real or string literals.
    The specification does not describes the syntax of integer, real or string literals.
    Specifying the syntax and the semantics of basic types will increase the portability
    of OCL programs

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

    These specifications were introduced in OCL 2.3
    Disposition: Closed, no change

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

Section: 1 - 13

  • Key: OCL21-261
  • Legacy Issue Number: 8667
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    General comments: OCL primitive types do not agree with UML primitive types. Multiplicity symbology for "infinite" is different. UML uses "*" whereas OCL uses "n." Capitalize the word "Boolean" as it is named for the 19th Century mathematicial George Boole. In most places it is capitalized but there are several places where it is not. I hope my comments have not been too annoying. Please consider everything I know about OCL I have learned from reading this document so if my comments don't make a lot of sense, then possibly clarification in the document may be needed.

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

    OCL primitive types now align, since UML has introduced Real.
    */n multiplicity is a drawing tool artefact. It may be resolved when redrawn for an autogenerated OCL 2.5.
    boolean in non-technical contexts can be corrected.

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

Section: 11.9.3 & 11.9.4

  • Key: OCL21-260
  • Legacy Issue Number: 8666
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - pg 151 change "The standard iterator expression" to "The standard iterator expressions." The reject expression for both Bag and Sequence have "source->select(iterator | not body) on the left side of the equals symbol. Shouldn't the word "iterate" be used instead of "select?" The sortedBy expression is very restrictive if the sort order must always have the lowest value first. A statement that a sort order could be by a > value would be nice.

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

    The typo is actually for Set.
    The wording for reject is correct; reject is defined as select with a not body.
    The sortedBy issue is a repeat of Issue 8665, which remains unresolved. (Maybe we need a sort(i, j | body) iteration so that body can return pairwise comparison which could be in reverse order.)

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

Section: 11.5.4

  • Key: OCL21-259
  • Legacy Issue Number: 8661
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    What is the difference in meaning between the definitions of or(b:Boolean): Boolean and xor(b:Boolean): Boolean? or(b:Boolean): Boolean says True if either self or b is true which implies "but not both" which is the ending phrase of the definition of xor(b:Boolean): Boolean.

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

    The resolution of Issue 17531 rephrased this.
    Disposition: See issue 17531 for disposition

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

Section: 7.5.9

  • Key: OCL21-272
  • Legacy Issue Number: 9914
  • Status: closed  
  • Source: LIANTIS GmbH ( Constantin Szallies)
  • Summary:

    The spec states: ---- The operation oclInState(s) results in true if the object is in the state s. Values for s are the names of the states in the statemachine(s) attached to the Classifier of object. ---- How does this relate to the uml metamodell? A BehavioredClassifier may have several ownedBehaviors but only one of those behaviors may be the behavior of the classifier himself. The other behaviors may be specifications for behavioral features of the classifier. ---- Clarification: Possible states for the operation oclInState(s) are all states of the statemachine that defines the classifier's behavior (property 'classifierBehavior' of the 'BehavioredClassifier' metaclass).

  • Reported: OCL 2.0 — Tue, 11 Jul 2006 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: 7.4.5

  • Key: OCL21-251
  • Legacy Issue Number: 8621
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - In the 2nd para, 3rd sent., the "t" of "type conformance error" is not italicized as is the rest of the phrase. Table 4 does not address the UML 2.0 (pct/04-10-02)use of UnlimitedNaturals as a type. This type probably Conforms to/Is a subtype of Real since UnlimitedNaturals are integers equal to or greater than 0.

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

    The italics are fixed in OCL 2.3.
    Subtyping is resolved by Issue 15780.
    Disposition: See issue 15780 for disposition

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

Section: 7.4

  • Key: OCL21-250
  • Legacy Issue Number: 8620
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    I'm not certain if I should report this issue to the OCL group or to the UML Superstructure group, but... the Basic Types listed in OCL do not agree with the Primitive Types listed in the UML Superstucture. OCL lists "Real" as a primitive (basic type), UML Superstructure does not, instead listing UnlimitedNatural as a primitive type. Shouldn't the two agree?

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

    UML 2.5 introduces Real. UnlimiteralNatural has been in UML for a long time.
    Disposition: Closed, no change

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

Section: 6.5.4.3 Combining Properties

  • Key: OCL21-249
  • Legacy Issue Number: 7722
  • Status: closed  
  • Source: BBDO InterOne ( Jasper Ullrich)
  • Summary:

    "[1] Married people are of age >= 18 context Person inv: self.wife->notEmpty() implies self.wife.age >= 18 and self.husband->notEmpty() implies self.husband.age >= 18" has to be "[1] Married people are of age >= 18 context Person inv: (self.wife->notEmpty() implies self.wife.age >= 18) and (self.husband->notEmpty() implies self.husband.age >= 18)" because of the precedence rules
    same mistake in http://www.omg.org/docs/ptc/03-10-14.pdf, "UML 2.0 OCL Final Adopted specification", chapter 7.5.3, page 18.

  • Reported: OCL 2.0b2 — Thu, 9 Sep 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

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

sub evaluations (02)

  • Key: OCL21-248
  • Legacy Issue Number: 7546
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    38. – [1] All sub evaluations have a different environment. The first sub evaluation
    – will start with an environment in which all iterator variables are bound to
    – the first element of the source, plus the result variable which is bound to
    – the init expression of the variable declaration in which it is defined.
    context IterateExpEval
    inv: let bindings: Sequence( NameValueBinding ) =
    iterators->collect( i |
    NameValueBinding( i.varName, source->asSequence()->first() ))
    in
    bodyEvals->at(1).environment = self.environment->addAll( bindings )
    ->add( NameValueBinding( result.name, result.initExp.resultValue ))
    ==> ’varName’ should be ’value’

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

    yes

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

sub evaluations

  • Key: OCL21-247
  • Legacy Issue Number: 7545
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    37. – [1] All sub evaluations have a different environment. The first sub evaluation
    – will start with an environment in which all iterator variables are bound to
    – the first element of the source, plus the result variable which is bound to
    – the init expression of the variable declaration in which it is defined.
    context IterateExpEval
    inv: let bindings: Sequence( NameValueBindings ) =
    iterators->collect( i |
    NameValueBinding( i.varName, source->asSequence()->first() ))
    in
    bodyEvals->at(1).environment = self.environment->addAll( bindings )
    ->add( NameValueBinding( result.name, result.initExp.resultValue ))
    ==> ’NameValueBindings’ should be ’NameValueBinding’

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

    yes

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

value of a collection range

  • Key: OCL21-246
  • Legacy Issue Number: 7544
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    36. – [1] The value of a collection range is the range of integer numbers between
    – the result value of its first expression and its last expression.
    context CollectionRangeEval
    inv: element.isOclType( Sequence(Integer) ) and
    element = getRange( first->oclAsType(Integer), last->oclAsType(Integer) ==> ’isOclType’ should be ’oclIsTypeOf’

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

    ’isOclType’ was fixed in OCL 2.3.
    Disposition: Closed, no change

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

Section: 11.2.1

  • Key: OCL21-258
  • Legacy Issue Number: 8659
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Last line on page is a sentence fragment

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

    redundant line

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

Section: 10.2.2 LocalSnapshot

  • Key: OCL21-257
  • Legacy Issue Number: 8645
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos - Change "ispre" to "isPre" and reword [2] to "...postcondition snapshot does it have an associated..."

  • Reported: OCL 2.0b2 — Mon, 28 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The typo is corrected in Issue 7524.

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

Section: 7.6.2

  • Key: OCL21-256
  • Legacy Issue Number: 8627
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    In the 2nd paragraph, shange "The value of the reject operation..." to "The value of the collect operation..."

  • Reported: OCL 2.0b2 — Thu, 24 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The typo is corrected in Issue 15980.
    Disposition: See issue 15980 for disposition

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

Section: 7.5.13

  • Key: OCL21-255
  • Legacy Issue Number: 8626
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The example using Bike and Car as two separate subtypes of Transport does not make any mention of Set(Car), Bag(car), or Collection(Car). Either delete reference to Car as a separate subtype of Transport or add some comments about a collection of some sort of Car conforming (and not conforming) to some other collection. I may be confused, but the statement "Note that Set(Bicycle) does not conform to Bag(Bicycle)" does not make a lot of sense to me. Wouldn't it be better to say that "Set(Bicycle) does not conform to Bag(car)?"

  • Reported: OCL 2.0b2 — Thu, 24 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Yes the words can be a little clearer

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

Section: 7.5.11

  • Key: OCL21-254
  • Legacy Issue Number: 8625
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The example of Set

    {1,2,5,88}

    is more of an example of an ordered set as is Set

    {'apple','orange','strawberry'}

    . The example of a Sequence

    {1,3,45,2,3}

    does not exhibit any apparent order although a Sequence is defined as an ordered Bag. It might be wise to alter these examples to: Set

    {1,88,5,2}

    , Set ['strawberry','apple','orange'} and Sequence

    {1,2,3,3,45}
  • Reported: OCL 2.0b2 — Thu, 24 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Yes. But reverse the sequence to clarify that the ordering may not be the obvious one. Also correct the punctuation.

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

Section: 7.5.9

  • Key: OCL21-253
  • Legacy Issue Number: 8624
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Although the definition of oclAsType may be obvious, this is an appropriate sub-section to place a paragraph describing oclAsType. It is the only prrdefined property on All Objects that is not defined in this section.

  • Reported: OCL 2.0b2 — Thu, 24 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

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

Section: 7.5.3

  • Key: OCL21-252
  • Legacy Issue Number: 8622
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - 2nd line of para under Missing AssociationEnd names, add a "s" to "tarting." Combining Properties example [2] does not show/express any combined properties; it just expresses the size property of the set employee.

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

    The paragraph containing the typo was removed in OCL 2.3.
    In the context of Section 7, Operation is a property so there is a combination in the example..
    Disposition: Closed, no change

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

history of an object is ordered.

  • Key: OCL21-239
  • Legacy Issue Number: 7528
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    20. – [1] The history of an object is ordered. The first element does not have a
    – predecessor, the last does not have a successor.
    context ObjectValue
    inv: history->oclIsTypeOf( Sequence(LocalSnapShot) )
    inv: history->last().succ->size = 0
    inv: history->first().Pre->size = 0
    ==> should be:
    context ObjectValue
    inv: history->oclIsTypeOf(
    StandardLibrary::StdLib.Sequence(LocalSnapShot) )
    inv: history->last().succ->size = 0
    inv: history->first().Pre->size = 0

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

    This issue seems to have been corrupted and reentered as Issue 7529..
    Disposition: Closed, no change

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

’Element’ should be ’NameValueBinding’

  • Key: OCL21-238
  • Legacy Issue Number: 7527
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    19. – [1] All elements belonging to a tuple value have unique names.inv: self.elements->isUnique(e : Element | e.name)
    ==> missing context statement: context TupleValue
    ==> ’Element’ should be ’NameValueBinding’

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

    yes

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

’element’ should be ’elements’ (02)

  • Key: OCL21-237
  • Legacy Issue Number: 7526
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    18. – [1] All elements belonging to a set value have unique values.
    inv: self.element->isUnique(e : Element | e.value)
    ==> missing context statement: context SetTypeValue
    ==> ’element’ should be ’elements’

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

    yes

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

’element’ should be ’elements’

  • Key: OCL21-236
  • Legacy Issue Number: 7525
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    17. – [1] All elements belonging to a sequence value have unique index numbers.
    inv: self.element->isUnique(e : Element | e.indexNr)
    ==> missing context statement: context SequenceTypeValue,
    ==> ’element’ should be ’elements’

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

    yes

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

Only one of the attributes isPost and isPre may be true at the same time.

  • Key: OCL21-235
  • Legacy Issue Number: 7524
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    16. – [1] Only one of the attributes isPost and isPre may be true at the same time.
    context LocalSnapshot
    inv: isPost implies isPre = false
    inv: ispre implies isPost = false
    ==> second invariant: ’ispre’ should be ’isPre’

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

    yes

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

arguments of the return message of an ocl message expression

  • Key: OCL21-234
  • Legacy Issue Number: 7523
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    15. – [5] The arguments of the return message of an ocl message expression
    – evaluation must correspond to the names given by the formal output parameters,
    – and the result type of the operation indicated in the ocl message expression.
    – Note that the Parameter type is defined in the UML 1.4 foundation package.
    context OclMessageExpEval
    inv: let returnArguments: Sequence{ NameValueBindings ) =
    resultValue.returnMessage.arguments ,
    formalParameters: Sequence

    { Parameter }

    =
    ==> ’

    {’ should be ’(’ (twice), and ’}

    ’ should be ’)’

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

    yes

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

inv: model.sentSignal->size() = 1 implies

  • Key: OCL21-233
  • Legacy Issue Number: 7522
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    Sequence

    {1.. arguments->size()}

    ->forAll( i |
    arguments->at.variable->size() = 1 implies
    model.sentSignal.signal.feature->select(
    arguments->at.variable )->notEmpty()
    and
    arguments->at.expression->size() = 1 implies
    model.sentSignal.signal.feature.oclAsType(StructuralFeature).type =
    arguments->at.expression.model
    ==> missing final closing bracket

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

    yes

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

value of a collection range

  • Key: OCL21-245
  • Legacy Issue Number: 7541
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    33. – [1] The value of a collection range is the range of integer numbers between
    – the result value of its first expression and its last expression.
    context CollectionRangeEval
    inv: element.isOclType( Sequence(Integer) ) and
    element = getRange( first->asOclType(Integer), last->asOclType(Integer)
    )
    ==> ’asOclType’ should be ’oclAsType’ (twice)

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

    ’asOclType’ was fixed in OCL 2.3.
    Disposition: Closed, no change

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

result value of a collection literal expression evaluation

  • Key: OCL21-244
  • Legacy Issue Number: 7539
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    31. – [2] The result value of a collection literal expression evaluation is a
    – collection literal value, or one of its subtypes.
    context CollectionLiteralExpEval inv:
    resultValue.isOclKind( OCLDomain::Values::CollectionValue )
    ==> ’isOclKind’ should be ’oclIsKindOf’

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

    ’isOclType’ and ’asOclType’ were fixed in OCL 2.3.
    Disposition: Closed, no change

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

result value of an attribute call expression

  • Key: OCL21-243
  • Legacy Issue Number: 7537
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    29. – [1] The result value of an attribute call expression is the value bound to the
    – name of the attribute to which it refers.
    context AttributeCallExpEval inv:
    resultValue = if source.resultValue->isOclType(
    OCLDomain::Values::ObjectValue) then
    source.resultValue->asOclType( ObjectValue )
    .getCurrentValueOf(referredAttribute.name)
    else – must be a tuple value
    source.resultValue->asOclType( TupleValue )
    .getValueOf(referredAttribute.name)
    endif
    ==> ’isOclType’ should be ’oclIsTypeOf’
    ==> ’asOclType’ should be ’oclAsType’
    ==> ’name’ should be ’value’ (twice)

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

    ’isOclType’ and ’asOclType’ were fixed in OCL 2.3.
    Yes. value rather than name

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

elements in a tuple value

  • Key: OCL21-242
  • Legacy Issue Number: 7531
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    23. – [1] The elements in a tuple value must have a type that conforms to the type
    – of the corresponding tuple parts.
    context TupleValue inv:
    elements->forAll( elem |
    let correspondingPart: Attribute =
    self.model.allAttributes()->select( part | part.name = elem.name ) in elem.value.model.conformsTo( correspondingPart.type ) )
    ==> ’Attribute’ should be ’UML14::Core::Attribute’
    ==> ’select’ should be ’any’

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

    No: OCL 2.4 does not yet have a UML-aligned type system so the UML14::Core:: is a solution for one particular tool. The prefix certainly shouldn't be UML14. It is likely that the UML aligned solution will not require a prefix at all legitimizing the original exposition.
    Yes: any rather than select

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

The operation allPredecessors

  • Key: OCL21-241
  • Legacy Issue Number: 7530
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    22. – [1] The operation allPredecessors returns the collection of all snapshots
    – before a snapshot, allSuccessors returns the collection of all snapshots after
    – a snapshot.
    context LocalSnapshot
    def: allPredecessors() : Sequence(LocalSnapshot) =
    if pred->notEmpty then
    pred->union(pred.allPredecessors())
    else
    Sequence {}
    endif
    def: allSuccessors() : Sequence(LocalSnapshot) =
    if succ->notEmpty then
    succ->union(succ.allSuccessors())
    else
    Sequence {}
    endif
    ==> ’notEmpty’ should be ’notEmpty()’ (twice)

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

    yes

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

The history of an object is ordered.(02)

  • Key: OCL21-240
  • Legacy Issue Number: 7529
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    21. – [1] The history of an object is ordered. The first element does not have a
    – predecessor, the last does not have a successor.
    context ObjectValue
    inv: history->oclIsTypeOf(
    StandardLibrary::StdLib.Sequence(LocalSnapShot) )
    inv: history->last().succ->size = 0
    inv: history->first().Pre->size = 0
    ==> ’size’ should be ’size()’ (twice)

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

    Yes, although the affected text changed slightly in OCL 2.2.

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

The notation for selecting elements should be more intuitive

  • Key: OCL21-208
  • Legacy Issue Number: 6880
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Suggestion: Use brackets as an alternate option to denote a call to the "select"
    function. Notation: mylist[iterator | condition]
    Example:
    self.ownedElementClass and name="MyClass"
    – #Class is a shorthand for oclIsKindOf(MyClass)
    equivalent to :
    self.ownedElement->select(oclIsKindOf(Class) and name="MyClass")

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

    The suggested syntax comes from QVTo.
    Non-trivial OCL expressions can be difficult to read. Introducing shorthand notations compromises readability. At present OCL has "." and "->" shorthands that cause significant difficulties. Introducing more does not seem appropriate for the standard language.
    It is not clear that introduction of another [..] syntax can avoid conflicts with the already challenging conflicts for association qualifiers and array indexes.
    Disposition: Closed, no change

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

The notation for testing the type of a metaclass is too verbose

  • Key: OCL21-207
  • Legacy Issue Number: 6879
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Suggestion: Use special characters to denote a call to oclIsKindOf and oclIsTypeOf.
    For instance, use '#ActionState' instead of 'oclIsKindOf(ActionState)'
    and use '##ActionState' instead of 'oclIsTypeOf(ActionState)'

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

    The suggested syntax comes from QVTo.
    Non-trivial OCL expressions can be difficult to read. Introducing shorthand notations compromises readability. At present OCL has "." and "->" shorthands that cause significant difficulties. Introducing more does not seem appropriate for the standard language.
    oclIsKindOf and oclIsTypeOf are already a source of confusion; oclIsTypeOf should rarely be used but is the more obvious name to new users, so providing a shorthand for oclIsTypeOf is unnecessary.
    The # syntax has no terminator so the shorthand needs an ambiguity resolution for a.#B.c()
    The suggested usage seems to conflict with the intuition of those familiar with unary prefixes of assembler languages or even OCL 1.x enumeration literals.
    If an improvement is to be made, something like
    (a as B).c()
    would contribute to rather than hamper readibility.
    Disposition: Closed, no change

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

Example with TupleType

  • Key: OCL21-206
  • Legacy Issue Number: 6614
  • Status: closed  
  • Source: Modeling Value Group ( Wim Bast)
  • Summary:

    Typo in an example with TupleType Section 7.5.15: In the example constraint, expression attr: Statistics : Set(TupleType(& This must be Tuple only, according to the concrete syntax.

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

    The typos are corrected in the overlapping Issue 15254.
    Disposition: See issue 15254 for disposition

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

The index seems incomplete

  • Key: OCL21-205
  • Legacy Issue Number: 6600
  • Status: closed  
  • Source: Modeling Value Group ( Wim Bast)
  • Summary:

    The index seems incomplete and leaves out interesting items (e.g., the definition of standard library functions).

  • Reported: OCL 2.0b2 — Wed, 12 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Inaccurate manually maintained indexes are discouraged in OMG specifications.
    The Index was accidentally omitted in OCL 2.3. It will not be re-instated.
    Disposition: Closed, no change

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

Issue: Syntax of Operation Call, Iterator, and Iterate Expressions

  • Key: OCL21-204
  • Legacy Issue Number: 6571
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: Syntax for the above constructions is extremely ambiguous and it might involve backtracking.
    Rationale: According to OCL specification

    • self.f(x, y)
    • Set {1,2,3}

      ->select(x, y| x+y = 3)

    • Set {1,2,3,4,5,6}

      ->iterate(x; acc:Integer=0 | acc + x)
      describe an operation call, an iterator, and an iterate expression.
      In order to make the distinction between an iterator call and an operation call we need in this case a three token lookahead, starting from x. The problem gets even more complicated if we consider that an argument for an operation call can be an expression.
      In order to solve this problem, which is a potential source of problems for the implementation (error-prone, inefficiency aso), we think that these OCL constructs should contain some extra syntax markers. There are several choices:

    • change the comma marker from iterator calls to something else, maybe a semicolon
    • add a syntax marker to an iterator name
    • do not allow the default types
      The above choices will allow to a deterministic parser to deal with the enumerated problems more efficiently. I do not agree with textual language in which variables are given a default type according to the context in which they are used, especially if these languages are design for industrial use. The same problems were in previous versions of C standard, which allowed implicit type int for variables in constructions like
      x;
      Now, the latest C standard states that variables with default type are not allowed.
  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The exposition of the OCL grammar is poor. In OCL 2.3 the status of iterator names was clarified as not-reserved words which makes the naive parsing approach outlined above more challenging. Instead it is necessary to pursue a syntactic parse and then resolve semantics in a tree walk. The 'problems' have not prevented OCL tool being built.
    Users would not be well-served by a major resyntaxing to introduce new punctuation.
    Disposition: Closed, no change

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

Issue: Abstract syntax tree

  • Key: OCL21-203
  • Legacy Issue Number: 6566
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: Some of the elements presented in 3.3.10 (e.g. EnumLiteralExp, children of ModelPropertyCallExp) cannot be constructed without using semantic information (e.g. the type of the expression determines if a name denotes an attribute, an association end, or an operation).
    Rationale: Usually a parser produces an AST. The semantic analyser augments the AST by computing for each node from AST the values of the attached attributes. The semantic analysis also checks if there are static semantics errors and reports them. Using other terms in the AST and hence other non-terminals in 4.5 (e.g. dot-selection-expression, arrow-selection-expression, call-expression etc.) will solve this problem.

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

    The exposition of the OCL grammar is poor, but it is possible to resolve context pursuing a left to right analysis of an expression. It is also possible to perform a syntactic parse and then resolve semantics in a tree walk.The 'problems' have not prevented OCL tool being built.
    Users would not be well-served by a major resyntaxing to introduce new operators that required the user to have greater understanding of the metamodels.
    Disposition: Closed, no change

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

Issue: Unspecified syntax and semantics for Integer, Real, and String

  • Key: OCL21-202
  • Legacy Issue Number: 6561
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: The specification does not describes the syntax of integer, real or string literals. Also, it does not contain the description of the allowed set of values.
    Rationale: Specifying the syntax and the semantics of basic types will increase the portability of OCL programs. In order to describe the semantics of basic types, the specification should describe the set of values, the allowed operations, and the standard used to perform the allowed operations. I think that it will be also useful to allow different types of integers and reals, like Integer(16), Integer(32), Integer(64), Real(32), and Real(64), in order to optimize the computational process.

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

    OCL 2.3 introduced concrete syntax specifications for integer, real or string literals.
    In regard to specific sets of values, the issue seems to indicate a misunderstanding of OCL; OCL is a specification language that may be evaluated. Integers and Reals are unlimited. If a particular implementation chooses to use a restricted value set, then it is for that implementation to prove that its reduced range is appropriate.
    Users can of course define their own DataTypes with whatever characteristics they find suitable.
    Disposition: Closed, no change

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

Issue: Virtual machine

  • Key: OCL21-201
  • Legacy Issue Number: 6559
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: The OCL 2.0 specification should be behaviour-oriented and not implementation-oriented (see section 4.3).
    Rationale: The idea of using OCL to describe itself is interesting from the research point of view, but unfortunately OCL is not a suitable metalanguage to define the meaning of other textual languages. I think that the best thing to do is to define a virtual machine and to describe the behaviour of the virtual machine using natural language. This technique was successfully used for languages like C, C+, Java, C#, and Prolog. I see no reasons why such a technique would fail for OCL. After all, OCL is less complex than modern programming language like C+, Java, or C#.
    A proper description and implementation of the OCL virtual machine will create all the conditions to have a language that is platform/tool independent.

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

    The specification can no doubt be improved. Most criticisms concern inconsistency and lack of formaility. Moving to "natural language" seems a retrograde approach. Work in progress attempts to remove inconsistency from auto-generation from models, and to improve formality by using an exposition of the semantics that can be checked by Isabelle.
    Disposition: Closed, no change

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

Clarify the UML semantics of IfExpEval

  • Key: OCL21-200
  • Legacy Issue Number: 6554
  • 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 the UML semantics of IfExpEval
    Rationale:
    The specification on page 5-21 of the evaluation of if_then_else omits the case when the condition evaluates to undefined. Thus the sentence should read:
    "The result value of an if expression is the result of the thenExpression if the condition is true, it is the result of the elseExpression if the condition is false, else it is undefined."

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

    The resolution for this becomes more complex with null/invalid rather than undefined. The resolution is in 17531.
    Disposition: See issue 17531 for disposition

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

Clarify the semantics of forAll

  • Key: OCL21-199
  • Legacy Issue Number: 6553
  • 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 the semantics of forAll
    Rationale:
    According to the informal explanation (page 6-16) the following Expression Set

    { 1 }

    ->forAll(x | x/0 < 0) would evaluate to false. However, according to the OCL definition it evaluates to undefined. Thus we propose to omit "otherwise, result is false" in the informal explanation.

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

    The resolution for this becomes more complex with null/invalid rather than undefined. The resolution is in 17531.
    Disposition: See issue 17531 for disposition

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

Add select/reject/collectNested to Collection

  • Key: OCL21-198
  • Legacy Issue Number: 6551
  • 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: Add select/reject/collectNested to Collection
    Rationale:
    The definition of any on Collection (page 6-16f.) uses select on Collection. However, select is not defined for Collection. Similarly, the definition of collect on Collection (page 6-17) uses collectNested on Collection, which is not defined on Collection. We therefore propose to add select and collectNested (and possibly reject) to Collection.

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

    No Data Available

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

Exception of strict evaluation (queries)

  • Key: OCL21-197
  • Legacy Issue Number: 6540
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Thomas Baar (thomas.baar@epfl.ch)
    Description: Strict evaluation for queries yields to contradictions in specifications
    Rationale: Queries can be specified in two ways, as invariants and in form of pre/post conditions. Suppose we specify query q(arg) as
    post: if (arg.oclIsUndefined()) then result = true else result = false endfi
    Having this, the following invariant should evaluate always to true:
    self.q(arg) = true or self.q(arg) = false.
    However, the invariant evaluates to undef once arg evaluates to undef thanks to strict evaluation.
    There is a misconception of strict evaluation when it comes to queries. The idea of queries is to have user-defined functions on classes. Why should the user be restricted only to such function which return undef once one of its arguments is undef? Using OCL, the user can even specify queries which can handle undefined arguments (e.g. see post specification of q(arg) ). Obviously, the post specification for q(arg) makes sense.
    The rule of strict evaluations for queries should be weakened to the case where the owner of the query (the object upon the query was called) is undefined.

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

    This issue was raised before undefined was clarified as null and invalid. It is now permissible to pass null values to queries. Only invalid values cannot be passed.
    Disposition: Closed, no change

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

Exception of strict evaluation (forAll, exists)

  • Key: OCL21-196
  • Legacy Issue Number: 6539
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Thomas Baar (thomas.baar@epfl.ch)
    Description: Exception of strict evaluation should be extended to forAll, exists
    Rationale: Suppose r(o1) = undef, r(o2) = false What is value of Exp =

    {o1, o2}

    ->forAll(x| r) ? One could argue, because of strict evaluation, the value of Exp is undef. However, this would contradict the semantics of forAll als 'iterated and' given on page A.28. Similarily, for exists.
    A note should be added on page 2-10 on evalution of expressions based on iterate.

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

    The resolution for this becomes more complex with null/invalid rather than undefined. The resolution is in 17531.
    Disposition: See issue 17531 for disposition

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

Exception of strict evaluation (implies)

  • Key: OCL21-195
  • Legacy Issue Number: 6538
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Thomas Baar (thomas.baar@epfl.ch)
    Description: Exception from strict evaluation for IMPLIES is incomplete and contradicts set-theoretical semantics
    Rationale: On page 2-10 only one exception from strict evaluation for IMPLIES is given:
    False IMPLIES x == True
    However, based on the official semantics of IMPLIES given on page A-12
    also x IMPLIES True == True

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

    The requested change actually occurred in OCL 2.2. However the clarification of null and invalid for Issue 17531 conflicts with the resolution, so this issue is therefore merged.
    Disposition: See issue 17531 for disposition

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

context State::getStateMachine() : StateMachine

  • Key: OCL21-220
  • Legacy Issue Number: 7503
  • Status: closed