Object Constraint Language Avatar
  1. OMG Specification

Object Constraint Language — Closed Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
OCL23-39 Role 'collectionTypes' should be 'collectionType' OCL 2.1 OCL 2.2 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-23 wrong variable name OCL 2.1 OCL 2.3 Resolved closed
OCL23-22 Undefined operation tail() on p 130 OCL 2.1 OCL 2.3 Resolved closed
OCL23-17 OCL 2.1 12.2.5 named-self classifierContextDeclCS OCL 2.1 OCL 2.3 Resolved closed
OCL23-21 Undefined operation tail() OCL 2.1 OCL 2.3 Resolved closed
OCL23-20 Undefined operation tail() OCL 2.1 OCL 2.3 Resolved closed
OCL23-5 OCL 2.0, 2.1 Loop iterators are not ordered and other inconsistencies OCL 2.1 OCL 2.3 Resolved closed
OCL23-4 OCL 2.0, 2.1 inconsistent definition of null and invalid OCL 2.1 OCL 2.3 Resolved closed
OCL23-13 OCL 2.1 7.4.7 Inconsistent Operator Associativity and Precedence OCL 2.1 OCL 2.3 Resolved closed
OCL23-12 OCL 2.1 Resolution of missing Concrete Syntaxes and Reserved Words OCL 2.1 OCL 2.3 Resolved closed
OCL23-3 Missing specification of UnlimitedNatural OCL 2.1 OCL 2.3 Resolved closed
OCL23-2 Erroneous operation names 'isOclType' and 'asOclType' OCL 2.1 OCL 2.3 Resolved closed
OCL23-1 [OCL-2.1 RTF] Transitive closure operator OCL 2.1 OCL 2.3 Resolved closed
OCL23-14 OCL 2.1 7.4.9 true, self, Bag and String are not reserved words OCL 2.1 OCL 2.3 Resolved closed
OCL23-9 Inconsistent lookup for underscored symbols OCL 2.1 OCL 2.3 Resolved closed
OCL23-8 OCL 2.1 Inconsistent implementation of Issue 6532 and contradictory resolution of Issues 7341 and 10437 OCL 2.1 OCL 2.3 Resolved closed
OCL23-16 OCL 2.1 9.3 Missing TypeLiteralExpCS OCL 2.1 OCL 2.3 Resolved closed
OCL23-15 OCL 2.1 9.3 Inferred TupleLiteralExp part type OCL 2.1 OCL 2.3 Resolved closed
OCL23-11 OCL 2.0 and 2.1 Section 9.3 CollectionRangeCS incorrect operator spelling OCL 2.1 OCL 2.3 Resolved closed
OCL23-10 OCL 2.1 Incomplete resolution 9913 InvalidLiteralExpCS and NullLiteralExpCS OCL 2.1 OCL 2.3 Resolved closed
OCL23-7 OCL 2.0 Inadequate Headings and PDF index OCL 2.1 OCL 2.3 Resolved closed
OCL23-6 OCL 2.0, 2.1 Inaccurate well-formedness constraints for IteratorExp OCL 2.1 OCL 2.3 Resolved closed

Issues Descriptions

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

OCL 2.1 12 Typos

  • Key: OCL23-19
  • Legacy Issue Number: 14597
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward 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 ( Dr. Edward 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

wrong variable name

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

    subclause [10])

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

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

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

    simple typo

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

Undefined operation tail() on p 130

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

    Related to Issue 7539)

    It reads: isOclKind

    It should read: oclIsKindOf

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

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

    This typo is addressed by Issue 14882
    Disposition: Merged

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

OCL 2.1 12.2.5 named-self classifierContextDeclCS

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

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

    context c : Company inv:
    c.numberOfEmployees > 50

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

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

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

Undefined operation tail()

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

    (Related to Issue 7539)

    It reads: isOclKind

    It should read: oclIsKindOf

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

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

    No Data Available

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

Undefined operation tail()

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

    subclause [4]

    It reads: names->tail()

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

    Rationale: tail() is not an operation of Sequence

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

    No Data Available

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

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 ( Dr. Edward 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 ( Dr. Edward Willink)
  • Summary:

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

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

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

    No Data Available

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

OCL 2.1 7.4.7 Inconsistent Operator Associativity and Precedence

  • Key: OCL23-13
  • Legacy Issue Number: 14582
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward 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 ( Dr. Edward Willink)
  • Summary:

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

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

    Define the concrete syntax of RealLiteralExpCS and IntegerLiteralExpCS.

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

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

    No Data Available

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

Missing specification of UnlimitedNatural

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

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

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

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

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

Erroneous operation names 'isOclType' and 'asOclType'

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

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

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

    No Data Available

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

[OCL-2.1 RTF] Transitive closure operator


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

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

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

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

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

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

    No Data Available

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

Inconsistent lookup for underscored symbols

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

    Description:

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

    Should be

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

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

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

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

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

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

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

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

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

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

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

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

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

OCL 2.1 9.3 Missing TypeLiteralExpCS

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

    The expression

    'a'.oclAsType(String)

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

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

    Syntactically:

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

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

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

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

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

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

OCL 2.1 9.3 Inferred TupleLiteralExp part type

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

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

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

    However neither 8.3.7 nor 9.3 specifies this inference.

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

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

    The synthesized attributes for VariableDeclarationCS should infer when possible.

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

OCL 2.0 and 2.1 Section 9.3 CollectionRangeCS incorrect operator spelling

  • Key: OCL23-11
  • Legacy Issue Number: 14237
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward 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 ( Dr. Edward Willink)
  • Summary:

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

    Suggest:

    Add to PrimitiveLiteralExpCS

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

    and

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

    (not forgetting UnlimitedNaturalLiteralExpCS

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

    Yes; resolution 9913 is incomplete

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

OCL 2.0 Inadequate Headings and PDF index

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

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

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

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

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

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

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

    It would be helpful to

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

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

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

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

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

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

OCL 2.0, 2.1 Inaccurate well-formedness constraints for IteratorExp

  • Key: OCL23-6
  • Legacy Issue Number: 14199
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward 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