Object Constraint Language Avatar
  1. OMG Specification

Object Constraint Language — Closed Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
OCL231-38 Lack of features commonly used in OCL UML 1.1 OCL 2.3.1 Resolved closed
OCL231-37 Issue nnnn: Japan PAS Ballot Comment 13 (ocl2-rtf) - Section 8.3.1 OclExpression (l16, p44) OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-36 The t should be subscripted next to the equal sign OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-35 Comparison operators don't exist for Boolean OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-14 Issue nnnn: Japan PAS Ballot Comment 9 (ocl2-rtf) Section 7.4.8 OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-13 Issue nnnn: Japan PAS Ballot Comment 8 (ocl2-rtf) Section 10.3.2 OperationCallExpEval P127 OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-22 Japan PAS Ballot Comment 24 (ocl2-rtf) 10.1 Introduction OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-21 Japan PAS Ballot Comment 23 (ocl2-rtf) 10 Semantics Described Using UML OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-19 Japan PAS Ballot Comment 18 (ocl2-rtf) OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-18 Japan PAS Ballot Comment 17 (ocl2-rtf) Section 9.3.4 simpleNameCS OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-12 Issue nnnn: Japan PAS Ballot Comment 7 (ocl2-rtf) Section 7.4.5 table 7.3 OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-11 Issue nnnn: Japan PAS Ballot Comment 6 (ocl2-rtf) OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-20 Issue from PAS Ballot comment for ISO/IEC DIS 19507 Section 9.3.29 OperationCallExpCS OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-15 Issue nnnn: Japan PAS Ballot Comment 10 (ocl2-rtf) Section 7.4.9 list of keywords OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-17 Japan PAS Ballot Comment 16 (ocl2-rtf) - Section 9.3.3 VariableExpCS OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-16 Issue nnnn: Japan PAS Ballot Comment 11 (ocl2-rtf) p 35 line 1 OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-33 Prime symbol lacking in the explanation preceding the formula OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-32 Confusing usage of the "precedes" symbol for generalization hierarchy OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-29 Japan PAS Ballot Comment 34 (ocl2-rtf) 13.3 Diagrams figure 13.8 OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-28 Japan PAS Ballot Comment 33 (ocl2-rtf) 13.3.3 String page 144 OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-25 Japan PAS Ballot Comment 28 (ocl2-rtf) 10.2.3 Additional Operations for the Values Package OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-24 Japan PAS Ballot Comment 27 (ocl2-rtf) Section 10.2.1 Definitions of Concepts for the Values Package OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-30 Use of the word meta OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-26 Japan PAS Ballot Comment 30 (ocl2-rtf) 10.3 The Evaluations Package, 2nd paragraph OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-31 on page 153 oclIsInState is used instead of oclInState OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-23 Japan PAS Ballot Comment 25 (ocl2-rtf) 10.1 Introduction, 3rd and 4th paragraphs OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-27 Japan PAS Ballot Comment 31 (ocl2-rtf): 10.3.1 Definitions of Concepts for the Evaluations Package OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-34 Unbalanced parenthesis in the formula OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-7 US PAS Ballot Comment 3 (ocl2-rtf) paragraph 1 OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-6 US PAS Ballot Comment 2 (ocl2-rtf) References OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-2 Issue on Alignment of next OCL version and references UML 2.4/ MOF 2.4 OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-5 US PAS Ballot Comment 1 OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-4 oclIsInState() OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-1 OCL 2.3 Incomplete CollectionRange well-formedness rules OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-10 Issue nnnn: Japan PAS Ballot Comment 5 (ocl2-rtf) OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-9 Issue nnnn: Japan PAS Ballot Comment 2 (ocl2-rtf) OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-3 typo in ptc/2010-11-42 and pas/2010-08-02 OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-8 Japan PAS Ballot Comment 1 (ocl2-rtf) OCL 2.3 OCL 2.3.1 Resolved closed

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

The t should be subscripted next to the equal sign

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

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

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

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

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

Comparison operators don't exist for Boolean

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

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

    {<, >, <, >}

    are defined as applicable to

    {UnlimitedNatural, Integer, Real, String, Boolean}

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

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

    No Data Available

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

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

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

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

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

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

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

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

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

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

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

    Initial Comment: Make clear which “latter” implies.

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

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

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

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

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

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

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

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

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

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

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

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

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

Japan PAS Ballot Comment 18 (ocl2-rtf)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    No Data Available

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

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

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

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

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

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

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

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

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

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

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

    Closed as Fixed by OCL 2.3
    Disposition: Closed

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

Prime symbol lacking in the explanation preceding the formula

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

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

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

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

    The overline operator got lost when the Latex was FrameMakered

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

Confusing usage of the "precedes" symbol for generalization hierarchy

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Initial Comment/Suggestion: Use the same UML description
    Comment : Resolved by using uml infrastructure 13.2.4 definition for string type:

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

Japan PAS Ballot Comment 28 (ocl2-rtf) 10.2.3 Additional Operations for the Values Package

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

    ObjectValue [1] The text refers to name parameter of snapshot, but LocalSnapshot in Figure 10.2 does not have “name: String” Add name parameter to LocalSnapshot in Figure 10.2.

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

    “The value that is bound to the name parameter in the latest snapshot” implies the use of
    the LocalSnapshot's bindings (NameValueBinding). Perhaps, including the word
    “bindings” may avoid confusions

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

Japan PAS Ballot Comment 27 (ocl2-rtf) Section 10.2.1 Definitions of Concepts for the Values Package

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

    Figure 10.3 Explanation of TupleValue (page 107) describes its association with element, but this association is not included in Figure 10.3. Add this association to Figure 10.3

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

    IIn section 10.2.1, the TupleValue description states the following:
    “In the metamodel, this is shown as an association from TupleValue to NameValueBinding.”
    Therefore the text, diagram and association description are consistent.
    Disposition: Closed

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

Use of the word meta

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

    I want to signal that the use of the word "meta" is confusing. Here is an example on page 47.

    TypeExp
    A TypeExp is an expression used to refer to an existing meta type within an expression.

    According to Merriam-Webster, "meta" is usually a prefix that could be added at the beginning of a word. This particle should be merged to the main word (like in metabasis) or attached using an hyphen (like meta-analysis).

    In consequence, we should read "metatype" which seems to hold the correct meaning. It is coherent with metaclass, for example. By the way, "metatype" is used at many places in the document.

    In some contexts and in the familiar language, you can use "meta" as a diminutive for something when its meaning is obvious. For example, "the meta is broken" when you mean the metacarpus. In a specification document and in a context where we have to differentiate many metaconcepts, it doesn't have its place.

    It is seen at many places in this document and may be other. In this one, we see "meta model" and "meta-model", while the word "metamodel" should be and is effectively used.

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

    yes

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

Japan PAS Ballot Comment 30 (ocl2-rtf) 10.3 The Evaluations Package, 2nd paragraph

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

    This paragraph is confusing. It starts with Figure 10.6 but talks about elements not included in Figure 10.6. In addition it talks about “OclEvaluation” twice, which do not appear in any of the following diagrams.Split the paragraph into two. Fist one should be just about summary of Figure 10.6, and the second one should introduce Figure 10.7with associated elements

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

    Initial suggestion:
    Split the paragraph into two. Fist one should be just about summary of Figure 10.6, and the second one
    should introduce Figure 10.7with associated elements.

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

on page 153 oclIsInState is used instead of oclInState

  • Key: OCL231-31
  • Legacy Issue Number: 16260
  • Status: closed  
  • Source: Vienna University of Economics and Business ( Bernhard Hoisl)
  • Summary:

    On page 153 oclIsInState(statespec : OclState) is used to check if an object is in a specified state. But in Section 7.5.9 on page 22 oclInState(statespec : OclState) is used for this purpose and examples are given.

    There is one more occurrence of oclIsInState on page 47 of Section 8.3.1, but this is talking about the abstract syntax, therefore it could be valid. But I think definitely not for the concrete syntax of the OCL.

    Strangely enough the Eclipse Interactive OCL Console implements oclIsInState() and not oclInState().

    I would appreciate a clarification which statement to use very much!

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

    If it was a popularity contest, oclInState would win because there are many occurences in Clause 7, but Clause 7 is not normative.
    Excluding clause 7, oclIsInState has two occurences to oclInState's one. More importantly, the definition in 11.3.1 is oclIsInState.
    Stylistically, all other ocl-prefixed methods returning boolean are oclIs...
    Let's go for oclIsInState

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

Japan PAS Ballot Comment 25 (ocl2-rtf) 10.1 Introduction, 3rd and 4th paragraphs

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

    The term “OMG 4-layered architecture” may need to be explained or used with proper references. Modify the text as appropriate.

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

    Not much of a title.
    Anyone familiar with modeling should really know who the OMG is and what a 4-layered architecture is.
    However it is surprisingly difficult to find any primary OMG references. MOF for instance refers to "a ‘Four layered metamodel architecture’ which is referred to in various OMG specifications" so maybe MOF will get some adverse comments from PAS too.

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

Japan PAS Ballot Comment 31 (ocl2-rtf): 10.3.1 Definitions of Concepts for the Evaluations Package

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

    OperationCallExp. This heading should read “OperationCallExpEval.”. Modify the heading as appropriate.

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

    Suggested action: Modify the heading as appropriate.

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

Unbalanced parenthesis in the formula

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

    The last formula in the definition A.12 has unbalanced parenthesis.
    The first parenthesis after the = sign seems in excess.

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

    No Data Available

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

US PAS Ballot Comment 3 (ocl2-rtf) paragraph 1

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

    The nature of the relationship between this specification and the OCL in UML 1.4 should be clarified in an informative manner.
    UML 1.4.1 needs to remain in force, because many UML models in many standards throughout the world are specified using UML 1.x notation, which is not backwards compatible with the notation in UML 2.x.
    Replace:

    This specification replaces the specification of OCL given in UML 1.4.1 and UML 1.5.

    With:

    This specification replaces the specification of OCL given in OCL 2.0.
    The version of OCL specified in ISO/IEC 19501:2005 is intended for use in models based on UML 1.4.1 and UML 1.5. However, use of the OCL specified by ISO/IEC 19501:2005 is not prescribed by this specification.
    The version of OCL specified in this International Standard is not directly applicable to models based on ISO/IEC 19501:2005. ”

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

    No Data Available

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

US PAS Ballot Comment 2 (ocl2-rtf) References

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

    The references need to include links to the formal OMG published specifications.

    The Scope clause refers to UML 2.2, however the reference is UML 2.0

    Informal references to UML 1.4.1 and UML 1.5 are included as part of explanatory text in the OCL 2.2 spec which refers to UML 1.x to explain differences of this new version of OCL.. The ISO/IEC 10151 (UML 1.4.1) needs to be added as an informative reference, for use in these explanations.
    Change:

    3 Normative References
    The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
    • UML 2.0 Superstructure Specification
    • UML 2.0 Infrastructure Specification
    • MOF 2.0 Core Specification
    • UNICODE 5.1 Standard: http://www.unicode.org/versions/Unicode5.1.0/
    «
    To :
    «
    3 References
    3.1 Normative References
    The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
    • UML 2.2 Superstructure Specification <omg spec Ref URL>
    • UML 2.2 Infrastructure Specification <omg spec Ref URL>
    • MOF 2.0 Core Specification <omg spec Ref URL>
    • UNICODE 5.1 Standard: http://www.unicode.org/versions/Unicode5.1.0/
    3.2 Informative References
    The following specifications are referenced in informative text:
    • ISO/IEC 19501:2005 Information technology – Open Distributed Processing – Unified Modeling Language (UML) Version 1.4.2 , also <omg Spec Ref URL>

    Change all uses of the informal UML 1.x references in the text From:

    UML 1.x” or “UML 1.4.x”

    To:

    ISO/IEC 19501:2005

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

    No Data Available

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

Issue on Alignment of next OCL version and references UML 2.4/ MOF 2.4

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

    Nature of problem:

    Informal references to UML 1.4.1 and UML 1.5 are included
    as part ofexplanatory text in the OCL 2.2 spec which refers
    to UML 1.x to explain differences of this new version of
    OCL.. The ISO/IEC 10151 (UML 1.4.1) needs to be added as
    an informative reference, for use in these explanations.

    UML 1.4.1 needs to remain in force, because so many UML
    models in may standards throughout the world are specified
    using UML 1.x notation, which is not backwards compatible
    with the new notation in UML 2.x.

    Given the normative content of OCL 2.3 (after RTF
    completes) is aligned technically with UML 2.4 and MOF 2.4,
    its normative references should be updated before
    publication of the RTF output, so that the OMG spec cross
    references will remain appropriate..

    The references, and their uses in the OCL 2.3spec, need to
    be updated to reflect these latest UML/MOF versions.

    In addition, the Output of the OCL 2.3 RTF should be
    labeled as OCL 2.4, to avoid clarify the technical
    alignment of OMG’s latest versions of UML and MOF.

    Proposed Changes:

    Change version in title to OCL 2.4.

    Change all self references in the text from “OCL version
    2.2” to “this OMG Specification”.

    Change all references from UML 2.0 and MOF 2.0 to UML 2.4
    and MOF 2.4.

    In Section 1 ­ Scope Clause:

    Change:

    This specification defines the Object Constraint Language
    (OCL), version 2.3. OCL version 2.3 is the version of OCL
    that is aligned with UML 2.3 and MOF 2.0.

    to

    This specification defines the Object Constraint Language
    (OCL), version 2.4. OCL version 2.4 is the version of OCL
    that is aligned with UML 2.4 and MOF 2.4.

    Section 3 ­ Normative References

    Change:

    3 Normative References
    The following normative documents contain provisions which,
    through reference in this text, constitute provisions of
    this specification. For dated references, subsequent
    amendments to, or revisions of, any of these publications
    do not apply.
    • UML 2.0 Superstructure Specification
    • UML 2.0 Infrastructure Specification
    • MOF 2.0 Core Specification
    • UNICODE 5.1 Standard:
    http://www.unicode.org/versions/Unicode5.1.0/
    «
    To :
    «
    3 References
    3.1 Normative References
    The following normative documents contain provisions which,
    through reference in this text, constitute provisions of
    this specification. For dated references, subsequent
    amendments to, or revisions of, any of these publications
    do not apply.
    • UML 2.4 Superstructure Specification <omg spec Ref URL>
    • UML 2.4 Infrastructure Specification <omg spec Ref URL>
    • MOF 2.4 Core Specification <omg spec Ref URL>
    • UNICODE 5.1 Standard:
    http://www.unicode.org/versions/Unicode5.1.0/
    3.2 Informative References
    The following specification is reference in explanatory
    text, which describes differences between this
    specification and the version of OCL included in the
    existing standard. Its provisions do not constitute
    provisions of this specification.
    • ISO/IEC 19501:2005 Information technology – Open
    Distributed Processing – Unified Modeling Language (UML)
    Version 1.4.2 , also <omg Spec Ref URL>

    Change all uses of the reference in the text
    From

    UML 1.x” or “UML 1.4.x”

    To:

    ISO/IEC 19501:2005

    In Section 6.1 “Changes to Adopted OMG Specifications”

    Replace:

    This specification replaces the specification of OCL given
    in UML 1.4.1 and UML 1.5.

    With:

    This specification replaces the specification of OCL given
    in OCL 2.2.

    The version of OCL specified in ISO/IEC 19505:2005 is
    intended for use in models based on UML 1.4.1 and UML 1.5.
    However, use of the OCL specified by ISO/IEC 19505:2005 is
    not prescribed by this specification.

  • Reported: OCL 2.3 — Tue, 7 Dec 2010 05:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Although this issue was raised in conjunction with the First OCL 2.4 RTF that led to OCL 2.3.1, it seems appropriate to use this issue resolve all the 'boilerplate' changes for OCL 2.4.
    Some of the changes outlined above occurred in OCL 2.3.1 and so need only a refresh for OCL 2.4.
    The change of all OCL 2.2 references to this specification is not applicable since all references to OCL 2.2 and 2.3 intentionally refer to transitions in specified functionality.
    MOF 2.0 references occur only in the boilerplate and so have been enumerated.
    There are many UML 2.0 references associated with the TBD alignment with the UML 2.0 metamodel. These are very unfortunate but deserve to stay as the TBDs that they remain.

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

US PAS Ballot Comment 1

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

    The OMG OCL 2 Revision Task force has resolved a set of defect and clarification issues against the text in DIS 19507. (Preliminary Report http://doc.omg.org/ptc/10-12-01.pdf , Change Barred Spec http://doc.omg.org/ptc/10-11-41.pdf) It is important that the corrections resolving these defects be reflected in the published ISO/IEC Standard for OCL. The editing group for OCL 2 (DIS 19607) should consider all changes against the text of OCL 2.2, resulting from RTF defect resolutions in the latest minor revision to OCL 2, approved by the OMG PTC by the time of the ballot resolution.

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

    This is a philosophical statement without any identifiable issues. Many related issues were raised so presumably no action is necessary here.
    Disposition: Closed, no change

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

oclIsInState()

  • Key: OCL231-4
  • Legacy Issue Number: 16048
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Since you are working on the StateMachines chapter, it may be worth considering after the first submission adding an explanation about oclIsInState().
    This query operation is unfortunately mispelled as oclInState(), see: http://www.omg.org/issues/ocl2-rtf.open.html#Issue15257
    This query operation is confusingly listed as a predefined property and explained as an operation in OCL2.2, clause 7.5.9:

    7.5.9 Predefined properties on All Objects
    There are several properties that apply to all objects, and are predefined in OCL. These are:
    oclIsTypeOf (t : Classifier) : Boolean
    oclIsKindOf (t : Classifier) : Boolean
    oclInState (s : OclState) : Boolean
    oclIsNew () : Boolean
    oclAsType (t : Classifier) : instance of OclType

    ....
    The operation oclInState(s) results in true if the object is in the state s. Possible states for the operation oclInState(s) are all states of the statemachine that defines the classifier's behavior. For nested states the statenames can be combined using the double colon “::”.

  • Reported: OCL 2.3 — Mon, 7 Mar 2011 05:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    I'm not sure that this correspondence on the UML RTF was really intended to be an OCL issue.
    The specific oclIsInState typo is resolved by Issue 16260.
    The more general discussion is appropriate for UML.
    Disposition: See issue 16260 for disposition

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

OCL 2.3 Incomplete CollectionRange well-formedness rules

  • Key: OCL231-1
  • Legacy Issue Number: 15836
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The descriptions of CollectionRange are generally vague leaving the end inclusivities unclear.

    It is only the CollectionRangeEval::getRange that provides a solid definition of well-formedness
    for e.g. Sequence

    {1..1}

    as equal to Sequence

    {1}

    .

    Unfortunately the specification is undecided about Sequence

    {2..1} since the CollectionRangeEval::getRange
    recursion never terminates.


    Rather than impose a well-formedness constraint that Sequence{2..1}

    is invalid, perhaps it should be
    made useful instead, by defining .. as operating in the direction of the last wrt the first so
    Sequence

    {2..1} = Sequence{2,1} and Set{1..2} = Set{2..1}

    = Set

    {1,2}

    .

  • Reported: OCL 2.3 — Thu, 18 Nov 2010 05:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    The generalization to allow down-counts can lead to nasty surprises for e.g. Sequence

    {1..x->size()}

    when x is empty. So just make it clear that Sequence

    {2..1}

    is invalid

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

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

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

    Click here for this issue's archive.
    Nature: Issue from PAS Ballot comment for ISO/IEC DIS 19507
    Severity:
    Summary:

    See comment JP 5 in “…_JISC.doc” file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip
    Resolution:

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

    Not much of a title.
    Not much of a summary.
    The referenced document jumps straight from JP4 to JP6, so no action possible.
    Even if JP6 was meant rather than JP5 then we can dismiss as a duplicate of Issue 16129.
    Disposition: Closed, no change

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

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

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

    The format of normative references doesn't meet ISO format.ISO/IEC 19505-1:2011 Information technology — OMG Unified Modeling Language (OMG UML) Version 2.1.2 Part 1: Infrastructure
    ISO/IEC 19505-2:2011 Information technology — OMG Unified Modeling Language (OMG UML) Version 2.1.2 Part 2: Superstructure
    ISO/IEC 19502:2005 Information technology – Meta Object Facility (MOF)
    ISO/IEC 10646:2003 Information technology – Universal Multiple-Octet Coded Character Set (UCS)
    If you want to refer OMG’s documents, see directive.

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

    Resolved as Issue 16122. See US 1, Added 10646 as ref for Unicode. Will Fix at BRM to
    most appropriate formal references, either ISO or OMG spec refs
    Disposition: See issue 16122 for disposition

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

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

  • Key: OCL231-3
  • Legacy Issue Number: 15922
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    Regarding ptc/10-11-42 and pas/10-08-02,
    It seems to be typo.

    In ptc/10-11-42, 11.6.5, and
    in pas/10-08-02, 11.5.5

    Threre is
    "A Sentence is not a subtype of Bag. The common supertype of Sentence and Bags is Collection."
    ^^^^^^^ ^^^^^^^^

    These two "Sentence"s seem to be typo.

    Substitute "Sequence" for "Sentence".

  • Reported: OCL 2.3 — Mon, 10 Jan 2011 05:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Yes. Bags is also a typo and the English can be improved

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

Japan PAS Ballot Comment 1 (ocl2-rtf)

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

    Because the content of table 2.1 is empty, this table is meaningless. Fill the table.

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

    As the text above the table 2.1 explains, said template table is intended to be filled by OCL Tool
    implementors.
    Disposition: Closed

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