Issues for OCL 2.0 Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 3392: OCL needs an abstract syntax, just like the UML metamode
Issue 3800: postcondition for the operation round on the predefined OCL type
Issue 3855: context declaration for OCL invariants
Issue 4112: OCL: Created and Destroyed instances
Issue 4121: In 6.9 "Grammar for OCL" (Internationalization issues)
Issue 4451: Downcast OCL collection operators
Issue 4691: 1. 6.2.1 "legend" on page 6-3, Internationalization issue
Issue 4692: 6.8.1.9 String on page 6-34
Issue 4693: EBNF of the String on page6-48.
Issue 4694: inhibtedChar on page6-48,
Issue 5581: Section 6.6.2
Issue 5582: Section 6.6.7
Issue 5970: OCL 2: flatten
Issue 5972: OCL 2: Can collections contain void/undefined objects
Issue 5974: OCL 2: String operations
Issue 6012: OCL/MOF/UML alignment
Issue 6393: OCL 2.0/international character sets
Issue 6529: oclIsNew for a collection
Issue 6531: Omit predefined type OclModelElement.
Issue 6532: Consider OclType as a powertype
Issue 6537: domain for library operations /, div
Issue 6542: Flagging insecure cast from Set to Sequence
Issue 6543: Flagging recursive definitions
Issue 6544: Operator precedence
Issue 6545: Attributes and Association Ends versus Properties
Issue 6546: Undefined values, isEmpty() and Collections
Issue 6552: Clarify definition of collectNested for Set, Bag, and Sequence
Issue 6555: Missing equality and inequality operations on collection types
Issue 6556: Reintroduce allAttributes operator
Issue 6558: Issue: General section to define OCL concepts
Issue 6560: Issue: Set of characters
Issue 6562: Issue: Keywords
Issue 6564: Issue: Operator precedence
Issue 6567: Issue: Attributes and Association Ends versus Properties
Issue 6568: Issue: oclIUndefined() versus isEmpty()
Issue 6569: Issue: OclType
Issue 6570: Issue: OclModelElement
Issue 6610: Enumeration approach for reflection
Issue 6611: OclUndefined = OclUndefine ?
Issue 6612: Formal Semantics of OCL 2.0 in Appendix A
Issue 6615: Keywords "attr" and "oper"?
Issue 6633: What's a collection?
Issue 6888: Use the "null" keyword instead of verbose "OclUndefined".
Issue 7341: section 7.4.6 (Re-typing or casting) on p.13
Issue 7456: Remove the composition symbol at the end of PropertyCallExp
Issue 7458: result of applying the collect operation to a Sequence
Issue 7459: There should be an OclUndefinedLiteralExp metaclass
Issue 7460: There should be an OclTypeLiteralExp metaclass
Issue 7461: There should be an OclTypeLiteralExp metaclass
Issue 7462: flatten operation
Issue 7463: plus (infix) operator (’+’)
Issue 7464: tostring operation for Integer, Real and Boolean
Issue 7465: OclMessageArg metaclass that is currently defined, could be removed.
Issue 7467: change rollnames
Issue 7468: The classifier name TupleType is also a reserved word
Issue 7469: Errors in the abstract syntax chapter 1. -- [1] Integer conforms to real.
Issue 7470: The type of body expression must conform to declared type of result variabl
Issue 7471: If message is a send action, arguments must conform to attributes of signal
Issue 7472: context Operation
Issue 7473: In section 3.3.9
Issue 7474: context TupleType::make(atts : sequence(Attribute) ) : TupleType
Issue 7475: 7. context AttrubuteCallExp
Issue 7476: collection literal expression
Issue 7477: The type of the condition of an if expression must be Boolean.
Issue 7478: iterator
Issue 7479: result type
Issue 7480: 1] The type of the source expression must be a collection.
Issue 7481: type of each iterator var. must be type of the elements of source collectio
Issue 7482: parameters of the operation.
Issue 7483: attributes of the signal.
Issue 7484: ’sentMessage’ should be ’sentSignal’
Issue 7485: 5] The target of an OCL message cannot be a collection.
Issue 7486: forall’ should be ’forAll’
Issue 7487: the property ’refParams’ is not present in OperationCallExp
Issue 7488: ’parameter’ should be ’Parameter’
Issue 7489: message is a call action,
Issue 7490: message is a send action,
Issue 7491: type of a TupleLiteralExp
Issue 7492: tuple literal expression
Issue 7493: The type of the attribute is the type of the value expression.
Issue 7494: type of a TupleLiteralExp
Issue 7495: context TTupleType::make(atts : sequence(Attribute) ) : TTupleType
Issue 7496: "Bag"
Issue 7497: referredOperation
Issue 7498: context TTupleType::...
Issue 7499: context Classifier
Issue 7547: ’StringValue.iterators
Issue 8662: Section: 11.7.2
Issue 8663: Section: 11.9.1 exists
Issue 8664: Section: 11.9.2 reject
Issue 8790: OclAny cannot be an instance of Classifier
Issue 8791: Specific inheritance links at M1 level should be removed
Issue 8792: VariableDeclaration should be renamed Variable
Issue 8793: The container for self and return variables is missing
Issue 8794: make link explicit
Issue 8809: Should compare the value of the slots and not the objects itself
Issue 8810: Inherited or non navigable properties should not appear in class descriptio
Issue 8811: Use a uniform convention to name multivalued properties
Issue 8812: The set of possible values of CollectionKind is missing
Issue 8813: The naming of the parts properties in literals is not consistent
Issue 8814: Inconsistency in the way to represent Tuple literal part
Issue 8815: Should avoid using the OclHelper stereotype
Issue 8816: The Ocl prefix should be avoided as much as possible in metaclass names
Issue 8817: An UnlimitedNaturalExp should be added in the metamodel
Issue 8818: Reusing TypedElement for UnspecifiedValueExp
Issue 8819: The superclass of UnspecifiedValueExp is not ModelElement
Issue 8820: The composition associations in figure 9 are missing
Issue 8821: The property 'unspecified' can be removed from the metamodel
Issue 8822: The metaclass 'OclMessageArg' can be removed from the metamodel
Issue 8823: Instanciation of collection types

Issue 3392: OCL needs an abstract syntax, just like the UML metamode (ocl2-ftf)

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

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

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

This is incorrect and should be replaced by 

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

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

context c : Class inv: 

to 

context c1,..,cn : Class inv: 

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

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

could be written as 

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

Crossreference to issue #3139. 

Discussion:
This is an OCL 1 issue transferred to the OCL 2 FTF.
Asking for a language enhancement which does not fit well with object orientation style where an
invariant has a unique context object.
Disposition: Closed, no change

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

For example:

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

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

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

already a quick fix in 1.4, further defer to 2.0. Discussion:
This is an OCL 1 issue transferred to the OCL 2 FTF.

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

Discussion:
This is an OCL 1 issue transferred to the OCL 2 FTF.
Deferred for timing constrains.

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

Resolution:
This is an OCL 1 issue transferred to the OCL 2 FTF.
The first interpretation is the right one. Adding "In this document " solves the ambiguity.

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

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

Resolution:
This is an OCL 1 issue transferred to the OCL 2 FTF.
Already resolved in OCL2: In 11.4.3 it is written: "The standard type String represents strings,
which can be both ASCII or Unicode."

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

This is an OCL 1 issue transferred to the OCL 2 FTF.
Obsolete issue. Refers to the old version (UML 1.4), not relevant to the OCL2 submission.

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

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

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

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

This is an OCL 1 issue transferred to the OCL 2 FTF.
Obsolete issue. Refers to the old version (UML 1.4), not relevant to the OCL2 submission.

Section 6.6.2 

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

This is an OCL 1 issue transferred to the OCL 2 FTF.
Obsolete issue. Refers to the old version (UML 1.4), not relevant to the OCL2 submission.

Section 6.6.7 

In the second bullet point: 

- shouldn't the italics refer to "employee" throughout? (In one case it says "employer"). - "unambiguous" should be "ambiguous".

This is an OCL 1 issue transferred to the OCL 2 FTF.
Obsolete issue. Refers to the old version (UML 1.4), not relevant to the OCL2 submission.

quotes from ad/2003-01-07 (v1.6 of OCL 2 proposal):


Section 1.5.1 says, "the flatten operation is a deep flatten, it
completely flattens a nested collection of any depth". However the
formal definition is :


post: result = if self.type.elementType.oclIsKindOf(CollectionType) then
          self->iterate(c; acc : Set() = Set{} |
                        acc->union(c->asSet() ) )
      else
          self
      endif


From Section 6.5.1 (definition of Set.Flatten). The formal declaration does
not show that the flatten operation is deep. This discussion is extended in
Appendix A, which presents an analogous postcondition, but explains that this
is for a single level only.


It would seem that the post-condition(s) in section 6.5.1 are wrong?

Deferred for timing reasons

Is it possible for collections to contain void (= undefined objects)?


Conceptually, this would appear to be required so that you
can specify whether an item in a collection can be null in
an actual implementation. The use of void and undefined() is
advised in exactly the same situation in a non-collection
context.


However, this quote from Section 2.4.11: "In general, an expression
where one of the parts is undefined will itself be undefined", along
with the rest of the section, shows that you can't use void as
a parameter to the collection calls, and in the context of OCL as a
language, this makes sense.


So I thank that this constraint:


context Collection
  inv: self->forAll(not OclIsUndefined())


is required, and this should be stated to clear up uncertainties.


This leaves the problem of how to say whether an "item in a collection
can be null in an actual implementation" is inresolvable in OCL 2.

Resolution:
The notion of OclUndefined is splitted into two notions: LiteralNull and OclInvalid to
distinguish between the situations where we have an absence of value (LiteralNull) and
an invalid events (such as division of zero). Collection can contain null values but cannot
contain Oclinvalid values.
Apart from making more flexible the usage of OCL as a query language, this resolution
aligns OCL with UML2 in which the "absence of value" is already modeled by the notion
of null literal which is not considered being an invalid value.

the routines on String are too sparse to support real world usage.
In particular, most users would require:


* uppercase and lowercase routines
* the ability to ask if String1 is found in String2
* case insensitive compare would be useful but can
  be built using the uppercase or lowercase routines

Deferred for timing reasons

Document ad/2003-05-01 contains directions along which the OCL
metamodel and the UML Infrastructure metamodel can be integrated to form one
single language. The OCL has originally been conceived as part of the UML
language, and has never been intended to be used separately. A tight
connection between the two metamodels is nessesary for all modelers that
want to use either UML, OCL, MOF, or a combination of these. Within the OMG
the OCL is heavily used for specifyingconstraints on metamodels in the
varous OMG standards. OCL is also used extensively in many of the proposals
for the MOF 2.0 QVT RfP, as the solution for a query language, and as part
of a transformation definition language. In all these cases, the OCL is used
at the metamodel level, i.e. at the MOF level. Formally this is incorrect,
because OCL isn't part of the MOF. Within the UML/MOF/OCL 2.0 framework, the
UML and the MOF share a common core. The MOF 2.0 proposal reuses the UML 2.0
Infrastucture. By integrating the OCL into the reused part of the UML 2.0
infrastructure, the OCL metamodel is integrated with the MOF 2.0 as well.
The definition of OCL at the MOF level is then achieved. Some aspects of the
coupling of the OCL metamodel with the UML Superstructure metamodel are
addressed in document ad/2003-05-01 as well.

Resolution:
The approach taken to solve the alignment problem is as follows:
- Chapters 7 to chapters 12 define the OCL for the UML superstructure language. The
OCL metamodel specification, notation and semantics is updated when needed to reflect
the changes made in the last version of the UML2 superstructure specification.
- Chapters 13 define the OCL that is required for metamodelling. More precisely, chapter
13 defines firstly the BasicOCL package extending the UML Core::Basic package to
allow the integration of OCL in languages that are built on the basis of the Infrastructure
Library. The chapter also defines the EssentialOCL package extending EMOF for OCL
integration. Conceptually, EssentialOCL is build from from BasicOCL using the same
principles used to define the EMOF package from the Core::Basic library package.
Structurally there is no difference between BasicOCL and EssentialOCL. Also, because
no new concept is introduced by BasicOCL and EssentialOCL the class descriptions are
not repeated, only the diagrams are showed.

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

Resolution:
Already resolved in the OCL2 document. "Ascii or unicode" is used instead of "ascii" alone.

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

OCL already is sufficiently expressive for this corner case.  The example supplied by the submitter can be expressed as

    s->select(oclIsNew())->size() = self.person->size()

Querying whether a collection is new does not make sense:  collection values are always new, by definition of OCL as a functional (side-effect-free) language.  If the concern is to query whether a collection-valued attribute of an object has been created, that is determined by asserting that the old value isEmpty() and the new value is notEmpty().
An important characteristic of collection values is that they exist entirely in the OCL domain.  The collection types are not defined in the model as data types, so an implementation of collections in the run-time system has no correlation to OCL collections.

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

This issue has been merged with issue 6610 (Enumeration approach for reflection) which
suggest dropping the enumeration approach for reflection because of multiple
implementation problems it causes. Usage of enumeration for reflection is now avoided
thanks to the introduction of TypeExp and StateExp.
The metaclass TypeType is now used to represent the type accepted by the oclIsKindOf,
oclIsTypeOf and oclAsType operations. The TypeType has a unique instance named
'OclType' , but it is anymore a enumeration but a type compliant with any type defined in
the model (metalevel).
In a similar way, the OclModelElementType – renamed ElementType – to better match
UML2 terminology (since Element replaces ModelElement as the base element in the
class hierarchy) – is retained to allow encoding explicitly the type of the parameter in the
oclInState pre-defined operation. This ElementType type has a singleton instance in the
standard library called OclElement (which is not an enumeration).
Since a usage of oclIsKindOf (resp. oclInState) is encoded as an operations call, the
arguments need to be OclExpressions: that's why the meta types are passed using
TypeExp (resp. StateExp).

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

Usage of powertypes as an alternative way to represent generically Ocl types is an
interesting suggestion. However, for timing reasons we prefer defer this issue to the RTF.

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

Adding: Evaluates to OclUndefined if r(resp i) is equal to zero.

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

Discussion:
We believe it is up to an implementation to decide whether to send a warning or not.
Disposition: Closed, no change

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

We believe it is up to an implementation to decide whether to send a warning or not.
Revised Text:
Disposition: Closed, no change

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

'and'
'or'
'xor'

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

The “div” and “mod” Integer operations are not operators; they are subject to the precedence of the “.” operator.

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

 

 

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

Resolved. See issue 6012 (OCL/MOF alignment)

Author: Octavian Patrascoiu (O.Patrascoiu@kent.ac.uk)
Description: Most of the modern OO languages support null values, but OCL does not. In order to map null values into OCL concepts we used the undefined value. Unfortunately, OCL offers two choices to test if a value is undefined or not: isEmpty and oclIsUndefined. Using isEmpty for such a purpose is some how confusing:
the result of property->isEmpty() must be true if the value of the property null/undefined 
the result of  Set{1/0, 1/0}->isEmpty() must be false
These situations are a source of errors and confusion at the implementation level. I think that isEmpty() should be used only to test if a collection is empty or not; the undefined values should be tested using ocIslUndefined. This operation should be also valid on collections. This approach will also work nice and clear for nested collections. 

Deferred for timing reasons

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

Deferred for timing reasons

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

Redefinition of the Collection::<> operation is not required in the context of the specializing collection types, because it is defined in terms of the Collection::= operation.

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

The Classifier metaclass (from UML) in the OCL Abstract Syntax provides introspection of the attributes and operations that it defines.  OCL does not need to add to these capabilities.
Disposition:	Closed, no change

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

Resolution:
Ideally we agree that a complete introduction of the concepts used could be provided
within the document to improve understandability of the specification. However, since
OCL makes usage of concepts defined in normative references (UML and MOF), we
prefer let the reader look at the reference documents.
We treat also here two other points concerning the general section: update of the
acknowledgement list and missing reference to chapter 13.

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

Deferred for timing reasons

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

The first paragraph of Section 9.3 “Concrete Syntax” describes OCL’s syntax for escaping the names of model elements that clash with OCL reserved words.
Disposition:	Closed, no change

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

This is a request to improve language definition. Should better be solved I a RTF.

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

See issue 6012 (UML2/MOF2 alignment) for resolution.

Description: OCL offers two choices to test if a value is undefined or not: isEmpty and oclIsUndefined.
Rationale: Most of the modern programming languages contain null values. The best OCL mapping for null value is the undefined value. Using isEmpty to test if a value is null/undefined is some how confusing:
* the result of property->isEmpty() must be true if the value of the         property is null/undefined
* the result of  Set{1/0}->isEmpty() must be false
because the expression property->isEmpty() is converted according to the OCL specification to Set{property}->empty()
These situations are a source of errors and confusion at the implementation level. I think that isEmpty() should be used only to test if a collection is empty or not; the null/undefined values should be tested using ocIslUndefined. This operation should be also valid on collections. This approach will also work nice and clear for nested collections. On the other hand I don't think that () should not be optional if the called operation has no arguments. This is feature specific to old languages like TAL and Pascal, while in modern languages like C, C++ the meaning of f and f() is different.

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

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

- I think the enumeration approach to reflection leads to a dead end. Why not leave that out for now and add full access to the user model in OCL2.1, when the other UML parts have stabilized. I think it would be quite straightforward to simply copy the relevant properties and operations from Classifier/Class to OclType.

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

Deferred for timing reasons

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

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

Deferred for timing reasons

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


This needs further clarification

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

This suggestion has already been implemented in the final 2.0 version.
Disposition:	Closed, no change

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

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

Discussion:
The source expression does not exist independently of the PropertyCallExp. The containment
strategy used by OCL to encode navigation expressions is from right to left (left expressions are
contained by expressions in the right).
Disposition: Closed, no change

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

According to the definition of the collect and collectNested iterators in the standard
library, the type of the result depends on the type of the source collection. If the source is
ordered the result is ordered. However there is an error in the 7.6.2 where it is said that a
collect always returns a Bag. The proposed revised text solves the inconsistency.

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

Resolution:
Resolution of issue 5972 proposes splitting of the notion of OclUndefined in two notions
(NullLiteral and OclInvalid). Two metaclasses named NullLiteralExp and
InvalidLiteralExp are introduced to represent usages of these values within OCL
expressions.

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

Resolution: The StateExp metaclass is introduced. This is in line with the observation
that it is not possible to use enumerations to treat type reflection (see issues 6610 and
6531).

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

Resolution:
The TypeExp metaclass is introduced. This is in line with the observation that it is not
possible to use enumerations to treat type reflection (see issues 6610 and 6531).

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

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

This is a request to improve the language. Better solved in a RTF.

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

This is a request to improve the language. Better solved in a RTF.

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

Resolution:
OclMessageArg is removed. The link between the message and its arguments
(OclExxpressions) is now direct as it is between OperationCallExp and the arguments.
No explicit constraint to the metaclass UnspecifiedValueExp has been added in order not
to restrict potential usages of this class in OCL language extensions.

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

Resolution:
As a convention to the concrete syntax, conflicting property 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.

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

Discussion:
TupleType is the name of an OCL metaclass but not a OCL reserved word. In any case,
for reserved word the "_" prefix convention should apply (see proposed resolution for
issue 7467).
Disposition: Closed, no change

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

Resolution:
Typo error. The extra unmatched bracket should be removed.
Revised Text:
1) In page 37, replacing:
context Primitive
inv: (self.name = ’Integer’) implies
Primitive.allInstances()->forAll (p | (p.name = ’Real’) implies
(self.conformsTo(p))))
by
context Primitive
inv: (self.name = ’Integer’) implies
Primitive.allInstances()->forAll (p | (p.name = ’Real’) implies
(self.conformsTo(p)))

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

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

Resolution:
In UML2 one can use directly the ownedAttribute role to access the Property which are
typed elements. Thanks to this it is possible to rewrite the rule in such a way that the
downcating is not necessary.

context Operation
def: hasMatchingSignature(paramTypes: Sequence(Classifier)) : Boolean =
-- check that operation op has a signature that matches the given
parameter lists
= let sigParamTypes: Sequence(Classifier) = self.allAttributes.type in
(
( sigParamTypes->size() = paramTypes->size() ) and
( Set{1..paramTypes->size()}->forAll ( i |
paramTypes->at (i).conformsTo (sigParamTypes->at (i))
)
)
)
==> remove the ’=’ after Boolean
==> same error occurs in "context Signal def: hasMatchingSignature...."

Resolution:
This is a typo error.

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

Resolution:
Typo error.
Revised Text:
1) In section 8.3.9, within 'OclExpression' subsection, insert the prefix "context:" before
OclExpression::withAtPre()
2) In section 8.3.9, within 'OclExpression' subsection, insert the prefix "context:" before
OclExpression::withAsSet()

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

Resolution:
Ocl code is changed: OrderedSet used instead of Sequence. Reference to the OclHelper is
removed since not really needed.

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

This typo has already been corrected in the last OCL 2.0 release. Now the well-formed rule relates to a PropertyCallExp.

Disposition:	Close, no change

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

In this case the proposed solution of implying that a CollectionLiteralExp must be the correspondent Collection type of the StdLib is not correct. Set{1, 2, 3} is a CollectionLiteralExp whose kind is CollectionKind::Set and whose type is not Set, but it's Set(Integer). 
The original expression is correct. However, an invariant relating to the OrderedSet type is missing, which must be added.

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

This well-formed rule is correctly written in the last OCL 2.0 release.Now Primitive is called PrimitiveType in UML 2.1 and in the context of OCL which includes UML Infrastructure and OCL metamodels, doesn't need to be qualified. In other words, PrimitiveType is not a clashing name in the OCL context, hence doesn't need to be qualified.

Disposition:	Close, no change

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

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

In OCL context SequenceType, Sequence and Bag are not clashing names, therefore they don't need to qualified. However, the OCL expression of this well-formed rule needs to be revised:
Collecting on an OrderedSet type, should produce a Sequence (see 12945 -issue's resolution).
As the reporter suggested, “body” must be used instead of “expression”. We need to check that the type of the body is always the type of the collected elements.

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

This well-formed rule is correctly written in the last OCL 2.0 release. In the OCL context, CollectionType is no a clashing name, so it doesn't need to be qualified.

Disposition:	Close, no change

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

This well-formed rule is correctly written in the last OCL 2.0 release. In the OCL context, CollectionType is no a clashing name, so it doesn't need to be qualified.

Disposition:	Close, no change

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

As the reporter remarks, the forall collection operation is not well-written.

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

As the reporter remarks, the forall collection operation is not well-written.

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

Typo error.

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

As the reporter remarks, the forall collection operation is not well-written.
In the OCL context, CollectionType is no a clashing name, so it doesn't need to be qualified. However, there is a typo in the expression.

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

As the reporter remarks, the forall collection operation is not well-written.

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

This issue seems to be already been solved, because the property definition is present in the OCL 2.0 specification. However, I have detected a typo with the expression since “parameter” property should be “ownedParameter”

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

The change suggested by the reporter doesn't apply because the property “parameter” should be “ownedParameter” as it is written in the specification. 
Disposition:	Close, no change.

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

Discussion:
It seems that the reporter forgot to relate the problem. No more problems seem to do exist apart from the “forAll” typo resolved in issue 7482.
Disposition:	Close, no change.

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

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

Good remark:
oclAsType(TupleType) is not needed since the allAttributes (allProperties in the current specification) operation is defined on Classifier.
The property owned by the TupleType  and the property owned by the TupleLiteralPart can't be the same property. Therefore to check the correct type of the TupleLiteralExpressions, the name and type of both properties must be the same (note that the prorperty of the TupleType cann't have init expression)

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

Discussion:
This issue is controversial, because they both seem to be correct: The name of the tuple part can be taken from the TupleLiteralPart itself (it's a TypedElement which has name) or it can be taken from the referred property. However, looking at the Concrete Syntax definition, it doesn't seem that the name of the TupleLiteralPart is initialized from the referred property, so the current well-formed rule is the best one.

Disposition:	Close, no change.

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

This issue has already been resolved.

Disposition:	See Issue 8814 for disposition

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

Discussion:
It seems that this issue is the same issue than the previously resolved issue 7491.

Disposition:	See Issue 7491 for disposition

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

This operation has been changed in the last OCL 2.0 specification (see issue for 7474 details). Moreover, the suggested qualification is not needed in the OCL context.

Disposition:	Close, no change

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

In the next OCL (2.1) specification, the operator + will be allowed to concat strings (see issue 7463 disposition), therefore, the well-formed rule will be correct.

Disposition:	Close, no change

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

The problem with the missing asOrderedSet casting is resolved thanks to UML2 since
the Classifier properties are now ordered.

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

This operation has been changed in the last OCL 2.0 specification (see issue for 7474 details). Moreover, the suggested qualification is not needed in the OCL context.

Disposition:	Close, no change

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

Some  related problems by the reporter have been already corrected. However the return type of the lookupSignal operation is still incorrect. It should be Signal type.

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

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

The submitter is misunderstanding.  For Set union, both sets may have elements in common; the result simply does not have duplicates.  The union is not defined as producing a bag, but another set.

On the other point, conversion of a set to a sequence or a bag cannot arbitrarily replicate elements, so it does not make sense that the result of asSequence() or asBag() on a set should contain multiple occurrences of any element.

Disposition:	Closed, no change

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

The submitter appears to have misread the initialization of the iterate accumulator variable to false as implying that the result of the iterate expression is false.

Disposition:	Closed, no change

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

The formulation of the constraint is correct.  The reject iterator is conveniently defined in terms of select with a negated body.
Disposition:	Closed, no change

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

Suggestion: Define a AnyType metatype

The AnyType metaclass is already defined in the final OCL 2.0 specification.
Disposition:	Closed, no change

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

Resolution:
Figure 28 is removed in order not to explicitly enforce implementations to realize specific
the compliance rules of OclAny, OclVoid and so on using inheritance mechanism. This
removal does not affect the compliance rules given for the types defined in the standard
library.

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

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

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

The ExpressionInOcl – defined separately in chapter 12 - is used for the containment of
these variables. Explicit links for the containment of the 'self', 'result' and the variables
representing the input parameters of an operation are added to this ExpressionInOcl. This
provides a default way to contain these variables (an extension of the OCL language may
choose another containment strategy for these variables). ExpressionInOCl inherits from
OpaqueExpression which is a class taken from UML. The property contextualClassifier is
removed since it can now be accessed using the type of the 'self' variable.

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

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

Resolution:
An 0..1 'representedParameter' property linking a Variable to a Parameter is added.
Within an OCL expression, a Parameter of an operation is manipulated through the usage
of a variable that is bound to the parameter.

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

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

A new definition is provided for both rules which uses an additional operation
Property::cmpSlots.

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

The description of the OclExpression class is updated by removing the text referring to
these inherited or non navigable properties.

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

Usage of 'qualifiers' and 'arguments' are replaced by 'qualifier' and 'argument'.

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

A sentence is added in the description to remind on the possible values.

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

The tuplePart is renamed 'part' and 'parts' (for collections) is renamed 'part'.

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

The ambiguity is solved by choosing the specific TupleLiteralExpPart metaclass
(renamed TupleLiteralPart to use the same naming convention as for
CollectionLiteralPart). In addition, since TupleLiteralPart and CollectionLiteralPart are
typed, both classes inherit from TypedElement (instead of having a direct 'type' property).
This is aligned with the conventions used within the UML metamodel.

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

There are a few list of additional operations references that make unnecessary testing of
of the presence of OclHelper like the TupleType::make() operation. Unnecessary
conditions regarding the OclHelper stereotype are removed.

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

Classes OclMessageType, OclMessageExp are renamed MessageType and MessageExp

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

The metaclass is added.

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

The OCL 2.0 final specification already has UnspecifiedValueExp specializing OclExpression.
Disposition:	Closed, no change

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

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

This resolution is for the current 8820 issue and for the merged issues 8818, 8819 and
8821.
UnspecifiedValueExp has now OclExpression as base class (issue 8819), and indirectly
TypedElement, which avoids defining a specific 'type' property (issue 8818). Also this
avoids defining the specific 'undefined' property (issue 8821). The missing composition
associations are added.

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

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

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

Remove the sentence.