Issues for OCL 2.4 Revision Task Force mailing list

To comment on any of these issues, send email to ocl2-rtf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

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

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

Issue 1790: Lack of features commonly used in OCL (ocl2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
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.

Resolution:
Revised Text: This issue needs to be resolved by the OCL 2.0 Finalization Task Force
Actions taken:
August 10, 1998: received issue
July 22, 1999: Deferred to UML 1.4/2.0.
December 2, 2004: Transferred to OCL 2.0 FTF

Discussion:

This issue needs to be resolved by the OCL 2.0 Finalization Task Force. This is an UML 1.x issue transferred to the OCL 2 FTF.
Not all the extra facilities suggested by the text of this issue have been incorporated to the
OCL2 specification. Specific facilities for specifying constraints on class interfaces could
be considered within the context of an RTF.
Disposition: Deferred

Issue 3513: OCL: Usage of qualifiers (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

Qualifiers, written in brackets after the path name of a feature call,
can express two different things.

- qualifying use: A qualifier is used to give the qualifing value of 
      a qualified association (chapter 7.5.7).
- navigational use: A qualifier is used to refine the navigation to 
      association classes. While this navigational use is necessary 
      only with recursive associations, it is legal for every navigation
      to an association class (chapter 7.5.5).

There is no way to distinguish these two sorts of qualifiers. There are
even expressions where both uses of the qualifiers would be necessary at
once, but this problem is restricted to such models that contain a
recursive, qualified association that has an association class.

Example where navigational and qualifing use cannot be distinguished:

There are two classes "Bank" and "Person", with a association between
them qualified by the account number (an Integer). The association end
at the class Person is named "customers".
An additional class "Company" has an attribute "customers" of type
Integer.

Now consider the subexpression "bank.person[customers]" in the context
of Company. "bank" clearly is a navigational expression. But "customers"
could either mean the attribute of Company, since Company is the context
of the expression (that is qualifying use as defined in 7.5.7); or
"customer" could mean the name of the association end (navigational use
as defined in 7.5.5). In the first case, the result type would be
Person, in the second case Set(Person).

Resolution:
Revised Text:
Actions taken:
March 29, 2000: received issue
December 2, 2004: Transferred to OCL 2.0 FTF

Discussion:

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

Issue 5971: OCL 2: OrderedSet (ocl2-rtf)

Click here for this issue's archive.
Source: HL7 (Mr. Grahame Grieve, grahame(at)healthintersections.com.au)
Nature: Uncategorized Issue
Severity:
Summary:

OrderedSet isn't discussed in the section on semantics

Resolution:
Revised Text:
Actions taken:
April 22, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 5973: OCL 2: what is a collection? (ocl2-rtf)

Click here for this issue's archive.
Source: HL7 (Mr. Grahame Grieve, grahame(at)healthintersections.com.au)
Nature: Uncategorized Issue
Severity:
Summary:

OCL 2 doesn't really define what a collection is. In essence,
a particular UML construct is arbitrarily designated as
the OCL collection, and a series of properties are assigned
to it


This question arises in 2 different ways:
- can you sub-class one of the concrete descendents in
  a UML diagram - by referring to the OCL package - and thereby
  add functionality to your own collection types


- are all parameterised classifiers collections? if you
  define a parameterised class, how does an OCL user or
  environment know whether it's a collection or not?


perhaps a stereotype should be intrroduced to allow for
unambiguous resolution of these issues

Resolution:
Revised Text:
Actions taken:
April 22, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 6528: Provide access to the sender of a message (ocl2-rtf)

Click here for this issue's archive.
Source: Ecole Polytechnique Federale de Lausanne (Mr. Alfred Strohmeier, )
Nature: Uncategorized Issue
Severity:
Summary:

Consider the operation:
Account::withdraw (amount: Money)
Suppose a Person object sends the operation, and we want to state that the person has to be the owner of the account. Access to the sender of the message is needed. One might for instance imagine that the concrete syntax defines a keyword sender, and we could then write:
context: Account::withdraw (amount: Money)
pre: sender = self.owner

Resolution:
Revised Text:
Actions taken:
November 10, 2003: received issue

Discussion:

Discussion:
Asking for an improvement of the language. Better solved in a RTF

Issue 6530: status of objects and tuples (ocl2-rtf)

Click here for this issue's archive.
Source: Ecole Polytechnique Federale de Lausanne (Mr. Alfred Strohmeier, )
Nature: Uncategorized Issue
Severity:
Summary:

Description: Provide a notation for the status of an object
Rationale:
It would be convenient to have a notation for denoting the status of an object. The type of such a status is a tuple. With such a notation it would be possible to compare the status of two objects or to compare the status of an object with a tuple. If not available, comparisons have to be performed on an attribute by attribute basis. Consider e.g.
  p, p1 and p2 are Person(s)
  p1.all = p2.all  -- the 2 persons have same status, i.e.
  is nicer and less error-prone than comparing all attributes:
  p1.firstName = p2.firstName and p1.name = p2.name and ...
It would also be possible to compare with a tuple:
  p.all = Tuple = Tuple {firstName = 'Alfred', name = 'Strohmeier', ...}

Resolution:
Revised Text:
Actions taken:
November 10, 2003: received issue

Discussion:

Discussion:
Asking for an improvement of the language. Better solved in a RTF

Issue 6533: Template return types in operation signatures (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Description: At some places, template parameter T appears in operation signatures, e.g., oclAsType(typename:OclType) : T (e.g., Sect. 6.2.1). At other places, this is denoted by "instance of OclType" or <<the return type of the invoked operation>>.  It would be more meaningful when these informal return type descriptions are replaced by "OclAny". An additional constraint about the actual return type should be given when necessary.

Resolution:
Revised Text:
Actions taken:
November 10, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 6534: Up- and Down-casts with oclAsType(). (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Description: This is not treated consistently throughout the document. As the formal semantics already allows both up- and downcasts, this should also be allowed in Sect. 2.4.6.

Resolution:
Revised Text:
Actions taken:
November 10, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 6535: Lack of operation specifications (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Author: Stephan Flake (flake@c-lab.de)
Description: Some operation specifications are still missing (they are marked by --TBD), e.g., oclAsType(). For this operation, a proposed specification is as follows (provided that OclType is a powertype):

1: context OclAny::oclAsType(typename:OclType) : OclAny
2: post: if OclType.allInstances()
3:               ->select(t:OclType | self.oclIsTypeOf(t)) 
4:               ->exists(t:OclType | typename.conformsTo(t)  or t.conformsTo(typename)) then
5:         result = self and result.oclIsTypeOf(typename)
6:       else
7:         result = OclUndefined and result.oclIsTypeOf(OclVoid)
8:       endif

For a comparison, a complex OCL specification for ENUMERATION TYPE OclType can be found in the paper "OclType - A Type or Metatype?".

Resolution:
Revised Text:
Actions taken:
November 10, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 6536: Additional annotations in the OCL Standard Library (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Author: Stephan Flake (flake@c-lab.de)
Description: The OCL Standard Library type system should make use of the notation offered by the official UML specification. In particular, abstract types (like OclAny, Collection(T)), datatypes (Integer, Set(T)), and enumeration types (OclState) can be denoted in italics and stereotyped, respectively.
An ellipsis can be used to indicate that further types are imported from a referred UML user model.
Moreover, OrderedSet(T) is missing in the OCL Standard Library Type type system.

Resolution:
Revised Text:
Actions taken:
November 10, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 6538: Exception of strict evaluation (implies) (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 10, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 6539: Exception of strict evaluation (forAll, exists) (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Author: Thomas Baar (thomas.baar@epfl.ch)
Description: Exception of strict evaluation should be extended to forAll, exists 
Rationale: Suppose r(o1) = undef, r(o2) = false What is value of Exp =  {o1, o2}->forAll(x| r(x)) ?  One could argue, because of strict evaluation, the value of Exp is undef.  However, this would contradict the semantics of forAll als 'iterated and' given on page A.28.   Similarily, for exists. 
A note should be added on page 2-10 on evalution of expressions based on iterate.

Resolution:
Revised Text:
Actions taken:
November 10, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 6540: Exception of strict evaluation (queries) (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 10, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 6541: Exception of strict evaluation (=) (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Author: Thomas Baar (thomas.baar@epfl.ch)
Description: contradiction for evaluation of navigation expression
Rationale: Suppose to have two classes A, B and an association with multiplicity 
0..1 on B
between them.
The invariant context 
A inv: self.b = self.b
is evaluated for an instance of A not having an associated instance of B to
i)	true, when the expression self.b has the type Set(B), because self.b is evaluated to emptyset and emptyset = emptyset is evaluated to true
ii)	undef, when the expression self.b has the type B, because self.b is evaluated to undef and undef = undef is evaluated to undef thanks to strict evaluation of '='
This is a contradiction since the expression self.b can be both of type set(B) and B!
The examples also shows, that x = x is not a tautology unlike in almost all other logics including classical predicates logic. This is especially confusing because OCL claims to be based on classical predical logic!

Resolution:
Revised Text:
Actions taken:
November 10, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 6547: Incomplete and missing well-formedness rules (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Author: Sten Loecher (Sten.Loecher@inf.tu-dresden.de)
Description: OCL specification contains incomplete/ missing well-formedness rules
Rationale:
The following list contains the concerned classes of the OCL metamodel and provides information about the required changes to the OCL specification.
AssociationClassCallExp: missing rule to describe the type
AssociationEndCallExp: missing rule to describe the type
AttributeCallExp: multiplicity, order, and unambiguousness must be
considered
CollectionLiteralExp: OrderedSetType must be added
IteratorExp: well-formedness rules needed for iterator operations one, any,
collectNested, and sortedBy
OclMessageExp: missing rule to describe the type
OclExpressionWithTypeArgExp: missing rule to describe the type
OperationCallExp: missing rule to describe the type

Resolution:
Revised Text:
Actions taken:
November 11, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 6548: Satisfaction of Operation Specifications (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Author: Hubert Baumeister (baumeist@informatik.uni-muenchen.de),
Rolf Hennicker (hennicke@informatik.uni-muenchen.de),
Alexander Knapp (knapp@informatik.uni-muenchen.de)
Description: Change Definition A.34 to allow the precondition to be weakened
Rationale:
It is commonly accepted that a program S satisfying an operation specification may weaken the precondition. This corresponds to Bertrand Meyer's view of software specifications as contracts between clients of a program and program provider. This is in accordance with the explanation following Def. A.34: "In other words, the program S accepts each environment satisfying the precondition as input and produces an environment that satisfies the postcondition." This sentence admits the possibility that S may be defined for environments not satisfying the precondition.
However Def. A.34 requires S to be defined exactly on the environments for which the precondition holds. Therefore, we propose to replace Def. A.34 by:
DEFINITION A.34 (SATISFACTION OF OPERATION SPECIFICATIONS)
An operation specification with pre- and postconditions is satisfied by a program S in the sense of total correctness if the computation of S is a function fS such that the restriction of fS to the domain of R is a total function fS|_dom(R): dom(R) -> im(R) and graph(fS|_dom(R)) \subseteq R.
Comment by Daniel Jackson (dnj@mit.edu)
i'd be very wary of linking any particular notion of refinement to a modelling language. different circumstances might need different notions, and there's no reason that the language should be tied to one. 
i wonder, for example, if you've considered the difference between preconditions as disclaimers and preconditions as firing conditions.
even for the standard notion of preconditions as disclaimers, your particular definition seems too narrow to me. requiring the program to be a function will rule out many reasonable implementations that are non-deterministic -- hash tables, for example.

Resolution:
Revised Text:
Actions taken:
November 11, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 6549: Satisfaction of Operation Specifications (2) (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Author: Achim D. Brucker (brucker@inf.ethz.ch),
Burkhart Wolff (wolff@informatik.uni-freiburg.de)
Description: Change Definition A.34 to allow the precondition to be weakened
Rationale:
It is commonly accepted that a program S satisfying an operation specification may weaken the precondition. This corresponds to Bertrand Meyer's view of software specifications as contracts between clients of a program and program provider. This is in accordance with the explanation following Def. A.34: "In other words, the program S accepts each environment satisfying the precondition as input and produces an environment that satisfies the postcondition." This sentence admits the possibility that S may be defined for environments not satisfying the precondition.
However Def. A.34 requires S to be defined exactly on the environments for which the precondition holds. Therefore, we propose to replace Def. A.34 by:
DEFINITION A.34 (SATISFACTION OF OPERATION SPECIFICATIONS)
An operation specification with pre- and postconditions is satisfied by a specification S if the restriction of S to the domain of R (denoted S|_dom(R)) is included in R, i.e. S|_dom(R) \subseteq R.
This is equivalent to: \forall x, y. x:dom(R) & (x,y):S --> (x,y):R.
In particular, S may be a program, i.e. a computation function in the sense of total correctness.

Resolution:
Revised Text:
Actions taken:
November 11, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 6550: Satisfaction of Operation Specifications (3) (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Author: Hubert Baumeister (baumeist@informatik.uni-muenchen.de),
Rolf Hennicker (hennicke@informatik.uni-muenchen.de),
Alexander Knapp (knapp@informatik.uni-muenchen.de)
Description: Change Definition A.34 to allow the precondition to be weakened
Rationale:
It is commonly accepted that a program S satisfying an operation specification may weaken the precondition. This corresponds to Bertrand Meyer's view of software specifications as contracts between clients of a program and program provider. This is in accordance with the explanation following Def. A.34: "In other words, the program S accepts each environment satisfying the precondition as input and produces an environment that satisfies the postcondition." This sentence admits the possibility that S may be defined for environments not satisfying the precondition.
However Def. A.34 requires S to be defined exactly on the environments for which the precondition holds. Therefore, we propose to replace Def. A.34 by:
DEFINITION A.34 (SATISFACTION OF OPERATION SPECIFICATIONS)
An operation specification with pre- and postconditions is satisfied by a program S in the sense of total correctness if the computation of S is a function fS such that the restriction of fS to the domain of R is a total function fS|_dom(R): dom(R) -> im(R) and graph(fS|_dom(R)) \subseteq R.

Resolution:
Revised Text:
Actions taken:
November 11, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 6551: Add select/reject/collectNested to Collection (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Author: Hubert Baumeister (baumeist@informatik.uni-muenchen.de),
Rolf Hennicker (hennicke@informatik.uni-muenchen.de),
Alexander Knapp (knapp@informatik.uni-muenchen.de)
Description: Add select/reject/collectNested to Collection
Rationale:
The definition of any on Collection (page 6-16f.) uses select on Collection. However, select is not defined for Collection. Similarly, the definition of collect on Collection (page 6-17) uses collectNested on Collection, which is not defined on Collection. We therefore propose to add select and collectNested (and possibly reject) to Collection.

Resolution:
Revised Text:
Actions taken:
November 11, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 6553: Clarify the semantics of forAll (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Author: Hubert Baumeister (baumeist@informatik.uni-muenchen.de),
Rolf Hennicker (hennicke@informatik.uni-muenchen.de),
Alexander Knapp (knapp@informatik.uni-muenchen.de)
Description: Clarify the semantics of forAll
Rationale:
According to the informal explanation (page 6-16) the following Expression Set { 1 }->forAll(x | x/0 < 0) would evaluate to false. However, according to the OCL definition it evaluates to undefined. Thus we propose to omit "otherwise, result is false" in the informal explanation.

Resolution:
Revised Text:
Actions taken:
November 11, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 6554: Clarify the UML semantics of IfExpEval (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Author: Hubert Baumeister (baumeist@informatik.uni-muenchen.de),
Rolf Hennicker (hennicke@informatik.uni-muenchen.de),
Alexander Knapp (knapp@informatik.uni-muenchen.de)
Description: Clarify the UML semantics of IfExpEval
Rationale:
The specification on page 5-21 of the evaluation of if_then_else omits the case when the condition evaluates to undefined. Thus the sentence should read:
"The result value of an if expression is the result of the thenExpression if the condition is true, it is the result of the elseExpression if the condition is false, else it is undefined."

Resolution:
Revised Text:
Actions taken:
November 11, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 6557: Introduce a "tuplejoin" operator (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Author: Herman Balsters (h.balsters@bdk.rug.nl)
Description: OCL 2.0 is not as expressive as SQL (as opposed to common belief) and needs to be extended to this end
Rationale:
In my paper  "Modeling Database Views with Derived Classes in the UML/OCL-framework" of this years UML conference (see proc. pp. 295-309) I investigated the issue of expressibility of OCL 2.0 w.r.t. to the query langauge SQL.  I have demonstrated in that paper that OCL 2.0 is not as expressive as SQL (as opposed to common belief), and that OCL needs an additional "tuplejoin" operator to achieve the desired result.
If this issue cannot be dealt with in this phase, I propose it be retained and examined at the next stage.

Resolution:
Revised Text:
Actions taken:
November 11, 2003: received issue

Discussion:

This is a request to improve the language. Should better be solved in a RTF.

Issue 6559: Issue: Virtual machine (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 11, 2003: received issue

Discussion:

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

Issue 6561: Issue: Unspecified syntax and semantics for Integer, Real, and String (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 11, 2003: received issue

Discussion:

This is a request to improve language definition and extend its expresiveness. Should better be
solved in a RTF.

Issue 6563: Issue: Comments (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Description: OCL 2.0 comments start with --
Rationale: This means that an expression like --4 cannot be interpreted as an arithmetic expression without inserting at least one space between the first - and the second -. I think that this problem can be resolved if the OCL comments start with // instead of --.

Resolution:
Revised Text:
Actions taken:
November 11, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 6565: Issue: Grammar of OCL (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Description: The grammar presented in 4.3, which is in my opinion a semantic grammar, is not suitable to describe the syntax of OCL.
Rationale: Introducing non-terminals like primary-expression, selection-expression, and operation-call-expression will solve all the problems and will reduce the number of ambiguities. Hence, the grammar contained in the specification will suffer less changes in order to be used to design and implement a deterministic parser. This is the case of the specifications for C, C++, Java, C#, and Prolog.

Resolution:
Revised Text:
Actions taken:
November 11, 2003: received issue

Discussion:

Decision deferred to an RTF. It would imply a lot of changes.

Issue 6566: Issue: Abstract syntax tree (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 11, 2003: received issue

Discussion:

Decision deferred to an RTF. It would imply a lot of changes.

Issue 6571: Issue: Syntax of Operation Call, Iterator, and Iterate Expressions (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Description: Syntax for the above constructions is extremely ambiguous and it might involve backtracking. 
Rationale: According to OCL specification
 * self.f(x, y)
 * Set{1,2,3}->select(x, y| x+y = 3)
 * Set{1,2,3,4,5,6}->iterate(x; acc:Integer=0 | acc + x) 
describe an operation call, an iterator, and an iterate expression.
In order to make the distinction between an iterator call and an operation call we need in this case a three token lookahead, starting from x. The problem gets even more complicated if we consider that an argument for an operation call can be an expression.
In order to solve this problem, which is a potential source of problems for the implementation (error-prone, inefficiency aso), we think that these OCL constructs should contain some extra syntax markers. There are several choices:
* change the comma marker from iterator calls to something else, maybe a semicolon
* add a syntax marker to an iterator name
* do not allow the default types 
The above choices will allow to a deterministic parser to deal with the enumerated problems more efficiently. I do not agree with textual language in which variables are given a default type according to the context in which they are used, especially if these languages are design for industrial use. The same problems were in previous versions of C standard, which allowed implicit type int for variables in constructions like
      x;
Now, the latest C standard states that variables with default type are not allowed.

Resolution:
Revised Text:
Actions taken:
November 11, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 6572: Issue: Parsing Tuple Types and Collection Types as Arguments (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Description: One issue we have discovered is about expressions of the form: expr.oclAsTypeOf( Type ) The OCL standard does not support Type as a collection or tuple type.
Rationale: We think that the syntax should be extended to support collection and tuple types. This will make the language more symmetric and increase the expressiveness of the language.

Resolution:
Revised Text:
Actions taken:
November 11, 2003: received issue

Discussion:

This issue asks for an improvement of the language. Should better be solved in a RTF.

Issue 6573: Issue: OclAny operations of tuples and collections (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Description: The OCL specification does not allow operations like = or <> to be performed tuple values. It also forbids operations like oclIsKindOf and oclIsTypeOf on collections.
Rationale: Add such operations to tuple and collection types signatures directly or by inheritance, will make the language more powerfull (e.g. a set of dogs can be casted to a set of animals).

Resolution:
Revised Text:
Actions taken:
November 11, 2003: received issue

Discussion:

This issue asks for an improvement of the language. Should better be solved in a RTF.

Issue 6574: Issue: Signature of Environment (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Description: The specification (in the standard) of the Environment class is missing a few things that are used or referred to elsewhere in the standard; some are missing altogether and some are missing from the class diagram:
The association from an environment to its parent.
The operations lookupImplicitSourceForOperation, lookupPathName, addEnvironment
Rationale: We show a more complete specification below. We also add a convenience method addVariableDeclaration; although not necessary as addElement can be used to add a VariableDeclaration, this operation avoids the need to construct the VariableDeclaration before adding it to the environment.
The specification of the Environment operations uses various methods on the bridge classes; we have added these operations to the classes, as shown in the previous section about the bridge classes.

Resolution:
Revised Text:
Actions taken:
November 11, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 6600: The index seems incomplete (ocl2-rtf)

Click here for this issue's archive.
Source: Modeling Value Group (Mr. Wim Bast, wim.bast(at)modelingvalue.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 12, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 6601: compliance points strategies (ocl2-rtf)

Click here for this issue's archive.
Source: Modeling Value Group (Mr. Wim Bast, wim.bast(at)modelingvalue.nl)
Nature: Uncategorized Issue
Severity:
Summary:

The compliance points strategies mentioned in the OCL 2.0 spec are different from the UML 2.0 infra, super and MOF 2.0 specs. We need to align the OCL spec on this

Resolution:
Revised Text:
Actions taken:
November 12, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 6609: OclUndefined / allInstances() clarification. (ocl2-rtf)

Click here for this issue's archive.
Source: Modeling Value Group (Mr. Wim Bast, wim.bast(at)modelingvalue.nl)
Nature: Uncategorized Issue
Severity:
Summary:

 think the operation allInstances() is under-specified in the current version of the OCL 2.0 specification. 

It does not seem to be clear whether OclUndefined is included in the returned set or not: 

According to the 1.5 specification of allInstances(), the instances of all subtypes are included. OclVoid is a subtype of all other types, thus OclUndefined would be a part of the set. 

I assume this is not the intended behaviour. For example, the "all names must be different" expression example would always yield OclUndefined or false, but never true.

Resolution:
Revised Text:
Actions taken:
November 13, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 6614: Example with TupleType (ocl2-rtf)

Click here for this issue's archive.
Source: Modeling Value Group (Mr. Wim Bast, wim.bast(at)modelingvalue.nl)
Nature: Enhancement
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 13, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 6879: The notation for testing the type of a metaclass is too verbose (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

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

Issue 6880: The notation for selecting elements should be more intuitive (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

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

Issue 6881: notation for selecting unique element within a list should be more concise (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Suggestion: Use brackets with a "!" prefixing mark 
    Example: 
        self.ownedElement[! #Class and name="MyClass"] 
        means 
        self.ownedElement->select(oclIsKindOf(Class) and name="MyClass")->first()

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

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

Issue 6882: There is no simple way to invoke an "if then else" on a collection (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Suggestion: Define an "alt" collection function, with a specific notation, as in: 
     mylist->alt(iterator | condition? thenExp, elseExp) 
     The expression elseExp is not evaluated if condition returns true

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

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

Issue 6883: The notation when nesting "if then else" is too verbose (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Suggestion: Define a "switch" collection function, with a sepecific notation, as in: 
         mylist->switch( iterator | cond1 ? exp1, cond2 ? exp2, …, else ? expN) 
     The expressions cond2 is not evaluated if cond1 returns true and so on.

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

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

Issue 6884: The notation when nesting "if then else" is too verbose (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Suggestion: Define a "switch" collection function, with a sepecific notation, as in: 
         mylist->switch( iterator | cond1 ? exp1, cond2 ? exp2, …, else ? expN) 
     The expressions cond2 is not evaluated if cond1 returns true and so on.

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

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

Issue 6885: Improve the notation when defining local variables (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

This is to avoid using the unreadable and unfriendly "let … in …" notation. 
      Suggestion: Use the result of a variable initialization as in: 
      if (let c = self.address)="" then "UNKNOWN" 
      else if c.includes(Set{"Irak","Afganifsthan"})   then "DANGEROUS" 
      else "OK" endif endif endif …

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

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

Issue 6886: Allow applying iteration operations on single objects (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Use a DOT instead of an ARROW is this situation. 
      myinstance.anycollectionfunction() equivalent to 
      Set{myinstance}->anycollectionfunction(…)->first()

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

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

Issue 6887: Allow implicit type casting to boolean when a boolean is expected (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Example1:   if list.select(...) then … equivalent to 
                        if list.select(...)->notEmpty() then … 
     Example2:  if item then … equivalent to 
                      if item<>OCLUndefined then ...

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

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

Issue 6889: Automatic casting between strings and enumeration values (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Make optional the qualification of enumeration values. 
  Example: Be able to write 'self.aggregationKind="Composite" ' as an alternative 
  to  'self.aggregationKind=AggregationKind::Composite'.

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

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

Issue 6890: Suppress the usage of an Ocl prefix in standard library operations (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

When a name conflicts happen, it should be possible to resolve by qualifying the 
    names.

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

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

Issue 6891: Allow defining standard library functions (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Allow defining standard library functions (including iteration operators) that 
   have a variable number of parameters.

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

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

Issue 6892: Allow defining default values for parameters in operations (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Allow defining default values for parameters in operations

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

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

Issue 6893: Provide specific notational support when testing stereotypes (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Suggestion: Use the STAR character. Quotes could be used in case of blanks 
       characters in stereotype names. 
   Example: self.ownedElement.select(kindOf(Class) and *EJBEntity) 
       returns all the classes stereotyped by the EJBEntity stereotype or a derived 
           stereotype. 
   Example: self.ownedElement.select(kindOf(Class) and **EJBEntity) 
       returns all the classes stereotyped by the EJBEntity stereotype.

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

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

Issue 6894: Add a generic text formatter operator '% (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Example:  self.comment = "My name is %s" % self.firstname

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

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

Issue 6895: Make usage of tuples less complex and less verbose (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Suggestions: 
     - Make type spec of internal fields optional. 
     - Make field name in tuples optional (using positional access)

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

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

Issue 7455: Add an import statement to OCL files (with package - endpackage block) (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

1. Add an import statement to OCL files (with package - endpackage block). At the moment one can
only reference a type from another package using its complete path name. It would be more convenient
to be able to import a package or other model element in the OCL files and use the simple name
of a type in the OCL expressions.

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Discussion:

Deferred for timing reasons

Issue 7457: Add a concrete syntax to allow OCL users to add additional IteratorExp’s (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

Add a concrete syntax to allow OCL users to add additional IteratorExp’s. People using OCL have
the need to define their own iterators and should be able to do so in a standardized way.

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Discussion:

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

Issue 7466: rewrite well-formedness (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

We would like to be able to rewrite well-formedness rules like:
context IfExp
inv: self.condition.type.oclIsKindOf(Primitive) and
self.condition.type.name = ’Boolean’
as
context IfExp
inv: self.condition.type.oclIsKindOf(Primitive) and This is more clear that the first expression where the matching is done by name.
Because the metamodel resides on a level higher than the standard library, we need a way to get access
to the standard library elements. One solution is to define a package ’StandardLibrary’ that contains a
Classifier called ’StdLib’, that holds the following attributes:
• + Collection: CollectionType;
• + Set: SetType;
• + OrderedSet: OrderedSetType;
• + Sequence: SequenceType;
• + Bag: BagType;
• + String: Primitive;
• + OclMessage: OclMessageType;
• + OclVoid : VoidType;
Other solutions might be possible, but the above has been proven to work in the Octopus tool.

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Discussion:

Discussion:
This issue will be deferred. There is a question of representing formally the standard library as an ordinary UML package, which is not going to be solved for OCL 2.1 release. 
Disposition:	Deferred

Issue 7500: context Classifier (02) (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

def: allReceptions() : Set(Reception) =
self.allFeatures->select(f | f.oclIsKindOf(Reception))
==> should be:
context Classifier
def: allReceptions() : Set(UML14::CommonBehavior::Reception) =
self.feature->select(f |
f.oclIsKindOf(UML14::CommonBehavior::Reception))->collect(
f | f.asReception() )
where asReception() is defined as operation to Feature:
+ asReception() : Reception

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7501: context Operation (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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))
)
)
)
==> ’self.allAttributes.type’ should be ’self.Parameter.type->asSequence()’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: receeived issue

Issue 7502: context Parameter::asAttribute(): Attribute (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

34. context Parameter::asAttribute(): Attribute
pre: -- none
post: result.name = self.name
post: result.type = self.type
post: result.multiplicity = 1
post: result.targetscope = ScopeKind::instance
post: result.ownerscope = ScopeKind::instance
post: result.ordering = OrderingKind::unordered
post: result.visibility = VisibilityKind::private
post: result.stereotype.name = ’OclHelper’
==> ’result.multiplicity = 1’ should be ’result.multiplicity = Multiplicity::one’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7503: context State::getStateMachine() : StateMachine (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

post: result =
if statemachine->notEmpty() then
stateMachine
else
-- must be part of a composite state
state.container.getStateMachine()
endif
context Transition::getStateMachine() : StateMachine
post: result =
if statemachine->notEmpty() then
stateMachine
else
-- state is not empty
state.getStateMachine()
endif
==> in both expressions ’statemachine’ should be stateMachine

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7504: context VariableDeclaration::asAttribute() : Attribute (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

post: result.constraint.bodyExpression = self.initExpression
==> should be:
post:
result.constraint.bodyExpression.oclAsType(OCLContextualClassifier::Expre
ssionInOcl).bodyExpression
= self.initExpression

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7505: parameters of the referredOperation (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7506: parameters of the referredOperation (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:

Issue 7507: An additional attribute refParams lists all parameters of the referred (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

38. -- [3] An additional attribute refParams lists all parameters of the referred
-- operation except the return and out parameter(s).
context OperationCallExp
def: refParams: Sequence(Parameter) = referredOperation.parameters-
>select (p
|
p.kind <> ParameterDirectionKind::return or
p.kind <> ParameterDirectionKind::out)
==> ’parameters’ should be ’Parameter’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7508: 1] The type of the attribute is the type of the value expression. (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

context TupleLiteralExpPart
inv: attribute.type = value.type
==> should be removed, class does not exist

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7509: context LocalSnapshot (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

Errors found in UML-based-semantics
1. context LocalSnapshot
def: let allPredecessors() : Sequence(LocalSnapshot) =
if pred->notEmpty then
pred->union(pred.allPredecessors())
else
Sequence {}
endif
def: let allSuccessors() : Sequence(LocalSnapshot) =
if succ->notEmpty then
succ->union(succ.allSuccessors())
else
Sequence {}
==> remove ’let’ from both expressions, add ’endif’ after the second

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7510: outgoingMessages results in the sequence of OclMessageValues (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

-- that have been in the output queue of the object between the last
-- postcondition snapshot and its associated precondition snapshot.
context OclExpEval::outgoingMessages() : Sequence( OclMessageValue )
pre: -- none
post:
let end: LocalSnapshot =
history->last().allPredecessors()->select( isPost = true )->first() in
let start: LocalSnapshot = end.Pre in
let inBetween: Sequence( LocalSnapshot ) = start.allSuccessors()->excluding( end.allSuccessors())->including(
start ) in
result = inBetween.outputQ->iterate (
-- creating a sequence with all elements present once
m : oclMessageValue;
res: Sequence( OclMessageValue ) = Sequence{}
| if not res->includes( m )
then res->append( m )
else res
endif )
==> ’pre’ should be ’Pre’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7511: context IfExpEval inv: (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

resultValue = if condition then thenExpression.resultValue else
elseExpression.resultValue
==> missing ’endif’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7512: sub evaluations (in the sequence bodyEvals) (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

4. -- [2] All sub evaluations (in the sequence bodyEvals) have a different
-- environment. The first sub evaluation will start with an environment in which
-- all iterator variables are bound to the first element of the source. Note that
-- this is an arbitrary choice, one could easily well start with the last element
-- of the source, or any other combination.
context LoopExpEval
inv: let bindings: Sequence( NameValueBindings ) =
iterators->collect( i |
NameValueBinding( i.varName, source->asSequence()->first() )
in
bodyEvals->at(1).environment = self.environment->addAll( bindings )
==> missing closing bracket before ’in’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7513: sub evaluations (in sequence bodyEvals) have different environment. (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

5. -- [3] All sub evaluations (in the sequence bodyEvals) have a different
-- environment. The environment is the same environment as the one from the
-- previous bodyEval, where the iterator variable or variables are bound to the
-- subsequent elements of the source.
context LoopExpEval
inv:
let SS: Integer = source.value->size()
in if iterators->size() = 1 then
Sequence{2..SS}->forAll( i: Integer |
bodyEvals->at(i).environment = bodyEvals->at(i-1).environment
->replace( NameValueBinding( iterators->at(1).varName,
source.value->asSequence()->at(i) )))
else -- iterators->size() = 2
Sequence{2..SS*SS}->forAll( i: Integer |
bodyEvals->at(i).environment = bodyEvals->at(i-1).environment
->replace( NameValueBinding( iterators->at(1).varName,
source->asSequence()->at(i.div(SS) + 1) ))
->replace( NameValueBinding( iterators->at(2).varName,
source.value->asSequence()->at(i.mod(SS)) )) ) endif
==> two closing brackets before ’endif’ should be removed

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Discussion:

Issue 7514: ocl message expression (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

6. -- [2] The result value of an ocl message expression is the sequence of the
-- outgoing messages of the ‘self’ object that matches the expression. Note that
-- this may result in an empty sequence when the expression does not match to any
-- of the outgoing messages.
context OclMessageExpEval
inv: resultValue =
environment.getValueOf( ’self’ ).outgoingMessages->select( m |
m.target = target.resultValue and
m.name = self.name and
self.arguments->forAll( expArg: OclMessageArgEval |
not expArg.resultValue.oclIsUndefined() implies
m.arguments->exists( messArg | messArg.value = expArg.value ))
==> add one closing bracket after expression

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7515: isSent attribute (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

7. -- [4] The isSent attribute of the resulting ocl message value is true only if
-- the message value is in the outgoing messages of the ‘self’ object.
context OclMessageExpEval
inv:
if resultValue.oclIsUndefined()
resultValue.isSent = false
else
resultValue.isSent = true
endif
==> add ’then’ after ’oclIsUndefined()’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7516: add ’and’ between both expression parts (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

8. -- [1] An ocl message argument evaluation has either an ocl expression
-- evaluation, or an unspecified value expression evaluation, not both.
context OclMessageArgEval inv:
expression->size() = 1 implies unspecified->size() = 0
expression->size() = 0 implies unspecified->size() = 1
==> add ’and’ between both expression parts

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7517: result value of an association class call expression evaluation (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

9. -- [2] The result value of an association class call expression evaluation that
-- has qualifiers, is determined according to the following rule. The ‘normal’
-- determination of result value is already given in section 5.3.7
-- ("Well-formedness Rules of the Evaluations package").
==> missing ’context .... inv:’
==> missing brackets and comma; the whole expression should be:
let
-- the attributes that are the formal qualifiers. Because and
association
-- class has two or
-- more association ends, we must select the qualifiers from the other
end(s),
-- not from -- the source of this expression. We allow only 2-ary associations.
formalQualifiers : Sequence(Attribute) =
self.model.referredAssociationClass.connection->any( c |
c <> self.navigationSource).qualifier.asSequence() ,
-- the attributes of the class at the qualified end. Here we already
assume
-- that an
-- AssociationEnd will be owned by a Classifier, as will most likely be
the
-- case in the
-- UML 2.0 Infrastructure.
objectAttributes: Sequence(Attribute) =
self.model.referredAssociationClass.connection->any( c |
c <> self.navigationSource).owner.feature->select( f |
f.isOclType( Attribute ))->asSequence() ,
-- the rolename of the qualified association end
qualifiedEnd: String = self.model.referredAssociationClass.connection-
>any( c
|
c <> self.navigationSource).name ,
-- the values for the qualifiers given in the ocl expression
qualifierValues : Sequence( Value ) = self.qualifiers->asSequence() ,
-- the objects from which a subset must be selected through the
qualifiers
normalResult =
source.resultValue.getCurrentValueOf(referredAssociationClass.name)
in
-- if name of attribute of object at qualified end equals name of formal
-- qualifier then
-- if value of attribute of object at qualified end equals the value
given in
-- the exp
-- then select this object and put it in the resultValue of this
expression.
qualifiers->size <> 0 implies
normalResult->select( obj |
Sequence{1..formalQualifiers->size()}->forAll( i |
objectAttributes->at(i).name = formalQualifiers->at(i).name and
obj.qualifiedEnd.getCurrentValueOf( objectAttributes->at(i).name ) =
qualifiersValues->at(i) ))

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7518: value of an association end call expression evaluation (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

10. -- [2] The result value of an association end call expression evaluation that has
-- qualifiers, is determined according to the following rule. The ‘normal’
-- determination of result value is already given in section 5.3.7
-- ("Well-formedness Rules of the Evaluations package").
==> add ’inv’, remove ’implies’, add comma. It should be:
-- [2] The result value of an association end call expression evaluation that has
-- qualifiers, is determined according to the following rule. The ‘normal’
-- determination of result value is already given in section 5.3.7
-- ("Well-formedness Rules of the Evaluations package").
inv: let
-- the attributes that are the formal qualifiers
formalQualifiers : Sequence(Attribute) =
self.model.referredAssociationEnd.qualifier ,
-- the attributes of the class at the qualified end
objectAttributes: Sequence(Attribute) =
(if self.resultValue.model.isOclKind( Collection )
then self.resultValue.model.oclAsType( Collection ).elementType->
collect( feature->asOclType( Attribute ) )
else self.resultValue.model->collect( feature->asOclType( Attribute ) )
endif).asSequence() ,
-- the values for the qualifiers given in the ocl expression
qualifierValues : Sequence( Value ) = self.qualifiers.asSequence() ,
-- the objects from which a subset must be selected through the
qualifiers
normalResult =
source.resultValue.getCurrentValueOf(referredAssociationEnd.name)
in
-- if name of attribute of object at qualified end equals name of formal
-- qualifier then
-- if value of attribute of object at qualified end equals the value
given in
-- the exp
-- then select this object and put it in the resultValue of this
expression.
qualifiers->size <> 0 implies
normalResult->select( obj |
Sequence{1..formalQualifiers->size()}->forAll( i |
objectAttributes->at(i).name = formalQualifiers->at(i).name and
obj.getCurrentValueOf( objectAttributes->at(i).name ) =
qualifiersValues->at(i) ))

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7519: missing ’inv:’ twice (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

11. -- [1] The condition evaluation corresponds with the condition of the expression,
-- and likewise for the thenExpression and the else Expression.
context IfExpEval inv:
condition.model = model.condition
thenExpression.model = model.thenExpression
elseExpression.model = model.elseExpression
==> missing ’inv:’ twice

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7520: an iterate expression evaluation (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

12. -- [1] The model of the result of an iterate expression evaluation is equal to
-- the model of the result of the associated IterateExp.
context IterateExpEval
inv: result.model = model.result )
==> remove last bracket

Resolution:
Revised Text:
Actions taken:
June 14, 2004: received issue

Issue 7521: arguments (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

13. -- [4] The arguments of an ocl message expression evaluation must correspond to
-- the formal input parameters of the operation, or the attributes of the signal
-- indicated in the ocl message expression.
context OclMessageExpEval
inv: model.calledOperation->size() = 1 implies
Sequence{1.. arguments->size()} ->forAll( i | arguments->at(i).variable->size() = 1 implies
model.calledOperation.operation.parameter->
select( kind = ParameterDirectionKind::In )->at(i).name =
arguments->at(i).variable
and
arguments->at(i).expression->size() = 1 implies
model.calledOperation.operation.parameter->
select( kind = ParameterDirectionKind::In )at(i).type =
arguments->at(i).expression.model
==> missing ’->’ before ’at’, and missing final closing bracket

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7522: inv: model.sentSignal->size() = 1 implies (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7523: arguments of the return message of an ocl message expression (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7524: Only one of the attributes isPost and isPre may be true at the same time. (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7525: ’element’ should be ’elements’ (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7526: ’element’ should be ’elements’ (02) (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7527: ’Element’ should be ’NameValueBinding’ (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7528: history of an object is ordered. (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7529: The history of an object is ordered.(02) (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7530: The operation allPredecessors (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7531: elements in a tuple value (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7532: value of an association class call expression (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

24. -- [1] The result value of an association class call expression is the value
-- bound to the name of the association class to which it refers. Note that the
-- determination of the result value when qualifiers are present is specified in
-- section 5.4.3 ("Well-formedness rules for the AS-Domain-Mapping.exp-eval
-- Package"). The operation getCurrentValueOf is an operation defined on
-- ObjectValue in section 5.2.3 ("Additional operations for the Values Package").
context AssociationClassCallExpEval inv:
qualifiers->size = 0 implies
resultValue =
source.resultValue.getCurrentValueOf(referredAssociationClass.name)
==> ’size’ should be ’size()’
==> ’resultValue’ should be ’resultValue->oclAsType(OCLDomain::Values::ObjectValue)’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7533: result value of an association end call expression (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

25. -- [1] The result value of an association end call expression is the value bound
-- to the name of the association end to which it refers. Note that the
-- determination of the result value when qualifiers are present is specified in
-- section 5.4.3 ("Well-formedness rules for the AS-Domain-Mapping.exp-eval
-- Package").
context AssociationEndCallExpEval inv:
qualifiers->size = 0 implies
resultValue =
source.resultValue.getCurrentValueOf(referredAssociationEnd.name)
==> ’size’ should be ’size()’
==> ’resultValue’ should be ’resultValue->oclAsType(OCLDomain::Values::ObjectValue)’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7534: result value of an association class call expression (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

26. -- [1] The result value of an association class call expression is the value
-- bound to the name of the association class to which it refers. Note that the
-- determination of the result value when qualifiers are present is specified in
-- section 5.4.3 ("Well-formedness rules for the AS-Domain-Mapping.exp-eval
-- Package"). The operation getCurrentValueOf is an operation defined on
-- ObjectValue in section 5.2.3 ("Additional operations for the Values Package").
context AssociationClassCallExpEval inv:
qualifiers->size() = 0 implies
resultValue =
source.resultValue.getCurrentValueOf(referredAssociationClass.name)
==> ’name’ should be ’value’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7535: result value of an association end call expression (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

27. -- [1] The result value of an association end call expression is the value bound
-- to the name of the association end to which it refers. Note that the
-- determination of the result value when qualifiers are present is specified in -- section 5.4.3 ("Well-formedness rules for the AS-Domain-Mapping.exp-eval
-- Package").
context AssociationEndCallExpEval inv:
qualifiers->size() = 0 implies
resultValue =
source.resultValue.getCurrentValueOf(referredAssociationEnd.name)
==> ’name’ should be ’value’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7536: result value of an association end call expression (02) (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

28. -- [1] The result value of an association end call expression is the value bound
-- to the name of the association end to which it refers. Note that the
-- determination of the result value when qualifiers are present is specified in
-- section 5.4.3 ("Well-formedness rules for the AS-Domain-Mapping.exp-eval
-- Package").
context AssociationEndCallExpEval inv:
qualifiers->size() = 0 implies
resultValue =
source.resultValue.getCurrentValueOf(referredAssociationEnd.name)
==> ’name’ should be ’value’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7537: result value of an attribute call expression (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7538: value of a collection item (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

30. -- [1] The value of a collection item is the result value of its item expression.
-- The environment of this item expression is equal to the environment of the
-- collection item evaluation.
context CollectionItemEval
inv: element = item.resultValue
inv: item.environment = self.environment
==> an association should be added between CollectionLiteralPartEval and EvalEnvironment

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7539: result value of a collection literal expression evaluation (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7540: number of elements in the result value (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

32. -- [3] The number of elements in the result value is equal to the number of
-- elements in the collection literal parts, taking into account that a
-- collection range can result in many elements.
context CollectionLiteralExpEval inv:
resultValue.elements->size() = parts->collect( element )->size()->sum()
==> ’resultValue’ should be ’resultValue->oclAsType(OCLDomain::Values::CollectionValue)’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7541: value of a collection range (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7542: result value of an if expression (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

34. -- [1] The result value of an if expression is the result of the thenExpression
-- if the condition is true, else it is the result of the elseExpression.
context IfExpEval inv:
resultValue = if condition then thenExpression.resultValue else
elseExpression.resultValue
endif
==> ’condition’ should be ’condition.resultValue->oclAsType(Boolean) = true’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7543: elements in the result value (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

35. -- [4] The elements in the result value are the elements in the
-- literal parts, taking into account that a collection range can result
-- elements.
context CollectionLiteralExpEval inv:
let allElements : Bag(Value) = parts->collect(
Sequence{1..allElements->size()}->forAll( i:
resultValue.elements->at(i).name = ’’ and
resultValue.elements->at(i).value = allElements->
self.kind = CollectionKind::Sequence implies
resultValue.elements->at(i).indexNr = i )
==> should be
context CollectionLiteralExpEval inv:
let allElements : Sequence(Value) = parts->collect(
in
Sequence{1..allElements->size()}->forAll( i:
resultValue->oclAsType(OCLDomain::Values::CollectionValue).
>any(x | x.indexNr = i).value
= allElements->at(i) and
self.kind = CollectionKind::Sequence implies
resultValue.elements->at(i).indexNr = i )

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7544: value of a collection range (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7545: sub evaluations (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7546: sub evaluations (02) (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7722: Section: 6.5.4.3 Combining Properties (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 9, 2004: received issue

Issue 7972: OCL Constraints in many levels (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

I been using rational rose and bold for delphi in some projects. This have worked very well for me.
When adding constraints to my models i have some times whished that there whas a way to do this
on different levels. Eg. error-constraints (if persisted the object would be a dirty data) , 
 
warning-constraints these can be broken but there is high probability that the object is ill formed from the
system user perspective (example a new customer whith no billing adress) and finally a hint-contraint that
when broken indicates that the object containes strange data (example a new customer object with the 
same phone number as a existing customer)
 
My own solution to this have been to add contraints of the first type to the model. This have enabeld me
to create generic code dealing with if the user should be allowed to save a object or not. 
 
The other types of constraints have been added as coments as a way to make the model as complete as
possibel. The implementation of checking and dealing with these constraints later in the project have ben 
solved in a mutch less generic and cumbersom way.
 
I thin´k that if the standard included a way to specify different levels of ocl statements in the model this would 
benefit the model driven way to make software

Resolution:
Revised Text:
Actions taken:
December 10, 2004: received issue

Issue 8620: Section: 7.4 (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
March 23, 2005: received issue

Discussion:

Issue 8621: Section: 7.4.5 (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
March 23, 2005: received issue

Issue 8622: Section: 7.5.3 (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
March 23, 2005: received issue

Issue 8623: Section: 7.5.8 (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In last paragraph on page 20 change the word "dotted" to "dashed" and in Fig. 3 change the dashed line denoting Dependency as an AssociationClass to a dotted line. This will agree with Fig. 1 example of an association class as well as the Notation described for AssociationClass on pg 45 of UML Superstructure (ptc/04-10-02).

Resolution:
Revised Text:
Actions taken:
March 24, 2005: received issue

Issue 8624: Section: 7.5.9 (ocl2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
March 24, 2005: received issue

Issue 8625: Section: 7.5.11 (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

The example of Set {1,2,5,88} is more of an example of an ordered set as is Set {'apple','orange','strawberry'}. The example of a Sequence {1,3,45,2,3} does not exhibit any apparent order although a Sequence is defined as an ordered Bag. It might be wise to alter these examples to: Set {1,88,5,2}, Set ['strawberry','apple','orange'} and Sequence {1,2,3,3,45}

Resolution:
Revised Text:
Actions taken:
March 24, 2005: received issue

Issue 8626: Section: 7.5.13 (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
March 24, 2005: received issue

Issue 8627: Section: 7.6.2 (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
March 24, 2005: received issue

Issue 8628: Section: 8.2 (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Typos - 1st line, 3rd para under The Types Package, delete "and" between "CollectionType" and "its." - 2nd sent., 3rd para under The Types Package, change "taken in account" to "taken into account." - 2nd sent., under OclMessageType, change "Like to the collection" to "Like collection." - Last sent. under TupleType, delete the word "to." In sub-section CollectionType, there is no mention of the fourth concrete subclass which is shown in fig. 5 as OrderedSetType. Add this to the list of concrete subclasses or change fig. 5 to indicate that OrderedSetType is not a subclass of CollectionType (possibly a subclass of SetType?). Sub-section 7.5.11 also indicates only three different collection types. In addition, CollectionTypes [1] on pg 36 ("--all instances of SetType, SequenceType, BagType conform to a CollectionType if the elementTypes conform") makes no mention of OrderedSetType.

Resolution:
Revised Text:
Actions taken:
March 24, 2005: received issue

Issue 8634: Section: 8.3 (ocl2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

Fig. 6 does not agree with fig. 12 (pg 60) in the number of subclasses that inherit from OCLExpression. Fig. 6 nor the subsequene notation have any mention of LetExp. Please add this to Chapter 8.

Resolution:
Revised Text:
Actions taken:
March 25, 2005: received issue

Issue 8635: Section: 8.3.4 (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Association arguments under OclMessageExp uses "SignalArgs" as the classifier name but fig. 9 and later in this section the name is given as OclMessageArg. Change SignalArgs to OclMessageArgs. In the notation for OclMessageArg, it is stated that "OclMessageArg has either a specified or an unspecified value." Would these then be attributes to OclMessageArg? UnspecifiedValueExp shows an association of type:Classifier in fig. 9. Add this to the notation or delete the association from the fig.

Resolution:
Revised Text:
Actions taken:
March 25, 2005: received issue

Issue 8636: Section: 8.3.5 (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

CollectionItem shows an association - item:OclExpression - in the fig. 10. CollectionLiteralExp shows an association in fig. 10 - parts:CollectionLiteralPart. This is an ordered association. CollectionRange shows two associations in fig. 10 - first:OclExpression and last:OclExpression. UML 2.0 (ptc/04-10-02) doesn't recognize Real as a primitive type but does use UnlimitedNatural. Need to add UnlimitedNatural as a primitive type. The attribute symbol for PrimitiveLiteralExp is not shown in fig. 10. TuppleLiteralExp shows an association in fig. 10 - tuplePart:VariableDeclaration. The statement that TupleLiteralExp "contains a name and a value for each part of the tuple type" implies attributes but these are not shown in fig. 10 or listed as attributes in the notation. Add a notation for VariableDeclaration.

Resolution:
Revised Text:
Actions taken:
March 25, 2005: received issue

Issue 8637: Section: 8.3.1 (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The association parentOperation nor the class OperationCallExp of OCLExpression is not shown in either fig. 6 or 9 but in fig. 7. Change the reference to fig. 7 page 44 in the association definition for parentOperation under OclExpression. Two additional associations vor VariableDeclaration are shown in fig. 6--baseExp:IterateExp and loopExpr:LoopExp. Add these to the notation or delete these associations from fig. 6.

Resolution:
Revised Text:
Actions taken:
March 25, 2005: received issue

Issue 8638: Section: 8.3.8 (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The def:lookupAssociationClass(name: String) has the same phrase after the arrow as the def:;ppli[AssociationEnd(name: String). I'm not familiar with OCL but this doesn't seem right to me. The context Operation and the context Signal each contain two equal sign separated only by a comment. I don't think this is correct either.

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8639: Section: 9.1 (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In fig. 13, the operations lookupLocal() and Lookup() appear twice with the same name. Is this proper? Grammer - Delete the words "for" and "as" in the last line on page 62. Bulletted paragraph beginning "If neither of the above..." implies only two choices so remove third bullet at top of page 63 and move line out flush with margin of bullet beginning "If not, check self..."

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8640: Section: 9.3 CollectionLiteralPartsCS (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

There is inconsistency in the spelling of "CollectionLiteralPartsCS" sometimes using the "s" after "Part" and sometimes capitalizing the "S" after "Part". This becomes even more confusing when the next production is "CollectionLiteralPartCS" - notice no"s" following "Part".

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8641: Section: 10.1 (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Typo - Fig. 14, "Ocl-AbstractSyntax" should be "OCL-AbstractSyntax" to agree with naming format shown in other two packages

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8642: Section: 10.2 (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The last paragraph on pg 94 that describes fig. 15 does not agree in names with the value names shown in fig. 15. StaticValue equates to the daya values the paragraph mentions and OclVoidValue apparently equates to "UndefinedValue." Since "UndefinedValue" and "OclVoidValue" both have the format of a class name this could lead to confusion. OclVoidValue, as later defined, is an undefined value so please change "UndefinedValue" in the open paragraph of this section.

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8643: Section: 10.2.1 Element (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The statement "An element represents a single component of a tuple value" is not directly diagrammed in fig. 16. Should it be?

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8644: Section: 10.2.1 NameValueBinding (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

NameValueBinding show an attribute and an association in fig. 16 that are not mentioned in the description/definition as are other attributes and associations in other descriptions/definitions.

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8645: Section: 10.2.2 LocalSnapshot (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8646: Section: 10.2.3 ObjectValue (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

[1] still uses the term "UndefinedValue" when I think it should be "OclVoidValue" to agree with fig. 15 and name of term being defined previously. Typo - delete the lase "endif" that is flush with the margin.

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8647: Section: 10.3 (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Fig. 20 does not diagram the class OclEvaluation. Should it?

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8648: Section: 10.3.1 LoopExpEval (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

For the association bodyEvals the name of the associated class does not agree with the class name in fig. 20

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8649: Section: 10.3.1 VariableExpEval (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The name of the association in fig. 20 is "referredVariable." Please correct either the text or the figure

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8650: Section: 10.3.2 AssociationEndCallExpEval (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The association definition says that the referredAssociationEnd is the name of the AssociationEnd to which the corresponding NavigationCallExp is a reference. Shouldn't the be to which the corresponding AssociationEndCallExp is a reference?

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8651: Section: 10.3.2 OperationCallExp (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The subtype name on fig. 21 is OperationCallExpEval which I believe is correct. Please change the title of this sub-section

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8652: Section: 10.3.2 NavigationCallExpEval (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Add the association "qualifiers" to OclExpEval as is shown in fig. 21

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8653: Section: 10.3.4 OclMessageArgEval (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The association variable is not diagrammed in fig. 23. Please add it to the fig

Resolution:
Revised Text:
Actions taken:
March 29, 2005: received issue

Issue 8654: Section: 10.3.4 OclMessageArgEval (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Fig. 23 shows an additional association of unspecified as the UnspecifiedValueExpEval that represents the unspecified evaluation. If this is supposed to represent the association variable, the description and the figure do not agree in any way.

Resolution:
Revised Text:
Actions taken:
March 29, 2005: received issue

Issue 8655: Section: 10.3.4 OclMessageExpEval (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Fig. 23 shows an attribute for OclMessageExpEval and that the association arguments is ordered. Neither of these are mentioned in the text

Resolution:
Revised Text:
Actions taken:
March 29, 2005: received issue

Issue 8656: Section: 10.3.5 (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

None of the attributes or associations diagrammed are mentioned in the text. If there is no intention of mentioning them in their respective expression evaluations make a note of this in the opening description of the section. TupleliteralExpPartEval is not diagrammed in fig. 24 but VariableDeclEval is diagrammed and not mentioned in the text. Please correct.

Resolution:
Revised Text:
Actions taken:
March 29, 2005: received issue

Issue 8657: Section: 10.4 (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

There is no caption for the figure on pg. 122. Although fig. 27 appears on pg 121 with its caption and fig. 28 is on pg. 132, use of the word "figures" on pg. 120 indicates that the fig. on pg 122 is a separate figure. Please clarify with a caption for the fig. on pg 122.

Resolution:
Revised Text:
Actions taken:
March 29, 2005: received issue

Issue 8658: Section: 10.4.3 IntegerLiteralExpEval (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

To be consistent with other sub-sections, use [1] before the OCL well-formedness rule

Resolution:
Revised Text:
Actions taken:
March 29, 2005: received issue

Issue 8659: Section: 11.2.1 (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Last line on page is a sentence fragment

Resolution:
Revised Text:
Actions taken:
March 29, 2005: received issue

Issue 8660: Section: 11.5.1 (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

If /(r:Real):Real then shouldn't a constraint be added to the definition that the value of self divided by r as long as r<>0? A number divided by 0 is not a real number.

Resolution:
Revised Text:
Actions taken:
March 29, 2005: received issue

Issue 8661: Section: 11.5.4 (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
March 29, 2005: received issue

Issue 8665: Section: 11.9.2 sortedBy (ocl2-rtf)

Click here for this issue's archive.
Source: U. S. Geological Survey (Ms. Jane Messenger, jmessenger(at)usgs.gov)
Nature: Clarification
Severity: Minor
Summary:

The restriction to sort the OrderedSet with the lowest value coming first is very restrictive. Sometimes it is beneficial to sort in reverse order. Think about a statement that would allow a > sort order.

Resolution:
Revised Text:
Actions taken:
March 30, 2005: received issue

Issue 8666: Section: 11.9.3 & 11.9.4 (ocl2-rtf)

Click here for this issue's archive.
Source: U. S. Geological Survey (Ms. Jane Messenger, jmessenger(at)usgs.gov)
Nature: Clarification
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
March 30, 2005: received issue

Issue 8667: Section: 1 - 13 (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
March 30, 2005: received issue

Issue 8789: The spec does not describes the syntax of integer, real or string literals (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
May 18, 2005: received issue

Issue 8808: Container of additional operations (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

OCL allows defining additional operations which are conceptually treated as operations of the metaclasses. However, except for special cases where the "additional operation" is effectively defined in the original metamodel, these "additional operations" are extensions to the original metamodel. No indication in the specification is given on what extension mechanism is used. This makes the exchange of OCL specifications through XMI  incomplete and ill-formed.

Resolution:
Revised Text:
Actions taken:
May 25, 2005: received issue

Issue 8902: Section 8.3.9 of the final Adopted Version of the OCL 2.0 Spec (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 7, 2005: received issue

Discussion:

The 'asSet' operation is predefined for collections but the 'atPre' is not at all a predefined operation. However fixing this issue implies re-synchronizing chapter 9 (concrete syntax) with chapter 8 (abstract syntax) which requires extra time. Deferred

Issue 8917: allInstances (ocl2-rtf)

Click here for this issue's archive.
Source: David Frankel Consulting (Mr. David Frankel, david(at)dfrankelconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Recommendation:

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

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

Resolution:
Revised Text: Update the allInstances() definition in Section 11.2.5 Operations and Wel-formedness Rules: allInstances() : Set(T) Returns all instances of T, including subtypes, where T is self. May only be used for classifiers that have a finite number of instances. This is the case, for example, for user-defined classes because instances need to be created explicitly. This is not the case, for example, for data types such as the standard String, Integer, and Real types. pre: self.oclIsKindOf(Classifier) -- self must be a Classifier and not self.oclIsKindOf(DataType) -- self must have a finite number of instances NOTE: The revision cannot be applied since superseded by issue 6532 which moves the definition 'allInstances' from 11.2.5 to 8.3.8. The new text of allInstances as defined by issue 6532 is in line with the intended clarification of this issue since it says: "returns all instances of the classifier and the classifiers specializing it"
Actions taken:
July 12, 2005: received issue
October 16, 2009: closed issue

Discussion:

To obtain all instances of a class that are not instances of some specializing class, it is sufficient to be able to select them fron the allInstances set:  t.allInstances()->select(oclIsTypeOf(t)).

Issue 8918: Navigating across non navigable associations (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

 

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

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

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


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

Resolution:
Revised Text:
Actions taken:
July 8, 2005: received issue
October 16, 2009: closed issue

Discussion:

Non navigability of an association end has no impact in the property navigation notation, so we do not feel the need for introducing an explicit text. 


Disposition:	Closed, no change

Issue 8922: Section 8.3.9 of the final Adopted Version of the OCL 2.0 Spec (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 30, 2000: received issue
October 16, 2009: closed issue

Discussion:

A simple duplication of issue 8902


Disposition:	See Issue 8902 for disposition

Issue 8937: Notation for accessing class operations is inconsistent (ocl2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Dr. Tracy Gardner, tgardner(at)uk.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

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

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

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

Proposed solution: 

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

Resolution:
Revised Text: Update Section 7.5.10 “Features on Classes Themselves” to provide an example of a static operation on Employee and to clarify that allInstances() is not a static operation: All properties discussed until now in OCL are properties on instances of classes. The types are either predefined in OCL or defined in the class model. In OCL, it is also possible to use static features, applicable to the types/classes themselves rather than to their instances. For example, the Employee class may define a static operation “uniqueID” that computes a unique ID to use in the initialization of the employee ID attribute: context Employee::id : String init: Employee::uniqueID() Static features are invoked using the ‘::’ operator and are distinct from the features of the Classifier metaclass, which include the allInstances operation pre-defined by OCL. If we want to make sure that all instances of Person have unique names, we can write: context Person inv: Person.allInstances()->forAll(p1, p2 | p1 <> p2 implies p1.name <> p2.name) Invocation of allInstances uses the ‘.’ operator rather than ‘::’ because it is not a static operation. It is an operation applicable to instances of the Classifier metaclass, of which Person is an example.
Actions taken:
July 21, 2005: received issue
October 16, 2009: closed issue

Discussion:

Accessing static features using ‘::’ is unambiguously an invocation of a static property and not a property of the Classifier metaclass.  OCL’s TypeExp is, effectively, a Classifier literal expression, so that the ‘.’ operator should invoke features of the Classifier metaclass.  An example of this is allInstances(), which is inherited from OclAny (which Classifier implicitly specializes) or allFeatures() (from UML).

Issue 8982: Circular imports (ocl2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
August 27, 2005: received issue
October 16, 2009: closed issue

Discussion:

This is a UML issue that has is already solved. In principle an implementation can avoid infinite import loop even in presence of cycles.


Disposition: Close, no change

Issue 9171: Introduction and oclType() (ocl2-rtf)

Click here for this issue's archive.
Source: SAP AG (Mr. Murray Spork, murray.spork(at)sap.com)
Nature: Uncategorized Issue
Severity:
Summary:

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


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


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


I thought it would be best if we found out whether this removal was
intentional before officially raising it as an issue. The reason is that
we find a) this is a useful reflective feature to have and 2) it is
still used in some current OMG specifications (note that it is used
inconsistently).
e.g.:
- UML2 Infrastructure - (ptc/03-09-15) pg.89:
        Classifier::maySpecializeType(c : Classifier) : Boolean;
                maySpecializeType = self.oclIsKindOf(c.oclType)


- Meta Object Facility (MOF) 2.0 Core Specification (ptc/03-10-04) -
pg.68
        ExtentImpl::addObject(ObjectInstance o, String suppliedId
[0..1]): String
        pre: not(self.entry.identifier includes suppliedId)
        post: oclIsNew(e) and oclType(e) = IdentifierEntry and
        e.object = o and
        self.entry includes e
        self.entry->select(ex | ex.identifier = e.identifier)->size() =
1 -- the new id is unique and
        (suppliedId <> null implies e.identifier = suppliedId)

Resolution:
Revised Text: Add an operation definition to Section 11.2.5 Operations and Well-formedness rules, in the OclAny subsection: oclType() : Classifier Evaluates to the type of which self is an instance. post: self.oclIsTypeOf(result)
Actions taken:
November 13, 2005: received issue
October 16, 2009: closed issue

Discussion:

It appears that oclType was removed because MOF reflection provides the Element::getMetaClass() to obtain the metaclass of a model element.  However, this is insufficient for three reasons:

1.Element in MOF is defined at the metamodeling level.  OCL constraints in a model are defined at the modeling level and, therefore, constrain the run-time instances of the classes described by the model.  These Classes do not inherit Element.
2.The UML Infrastructure does not merge the Reflection capability from MOF.  Therefore, the UML metamodel cannot use Element::getMetaClass() in its own OCL constraints (to constrain UML models).
3.The result of Element::getMetaClass() is Class, which is the metatype for metaclasses, not Type.  Thus, it would not be applicable to the values of DataTypes.

For these reasons, OCL must define its own reflection capability for models (not metamodels).  This is consistent with the oclIsKindOf and oclAsType.  Also, it seems more natural to define it as an operation as MOF does with getMetaClass() than as an attribute

Issue 9404: inability to uniquely reference association ends (ocl2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 7.5.3 of ptc/05-06-06 starts with the following: "Starting from a specific object, we can navigate an association on the class diagram to refer to other objects and their properties. To do so, we navigate the association by using the opposite association-end:"
 
However, unlike in UML 1.x, in UML2 this may well be ambiguous (since names of ends owned by Associations only have to be unique within the Association and not within the context of the Class).
OCL should therefore explicitly allow qualification using the name of the Association itself as well as the end name (it is not clear whether this is currently allowed as part of the syntax for 'associationendname' so there should be an example to show this. This would make it consistent with the metamodel which allows reference to specific Properties.
 
For example we could have associations A1 and A2 both linking classes C1 and C2 and each with ends c1 and c2 owned by the respective associations.
OCL does not then address the fact that aC1.c2 is ambiguous - unlike the case with unnamed ends it does not even say that it may be ambiguous and is hence disallowed.
However rather than disallowing the navigation OCL should have a syntax to allow qualification by the association name
For example aC1.A1::c2
 
The same could be used for missing association end names: If A1 had unnamed ends then one could use aC1.A1::C2

Resolution:
Revised Text: (1) In section 7.5.3 add the following text after Missing Association End Names section: Qualifying association ends with association names In cases the association that is being navigated has a non empty name, it is possible to qualify the accessed role name with the name of the association. This notation can be used to solve ambiguities as in the example below: A1 and A2 are two associations both linking classes C1 and C2 and each with ends c1 and c2. If aC1 is a C1 access, aC1.c2 will not be valid since it is ambiguous, whereas aC1.A1::c2 or aC1.A2::c2 will be valid.
Actions taken:
February 28, 2006: received issue
October 16, 2009: closed issue

Discussion:

The proposed qualification by the association name solves the issue in a consistent way.
Notice however that in the case of missing association end names, OCL already have a convention which is to use the class name with the first letter lowerized.

Issue 9405: Wrong subtyping of PropertyCallExp and NavigationCallExp (ocl2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: Update text in Section 8.3.2: NavigationCallExp A NavigationCallExp is a reference to a Property or an AssociationClass defined in a UML model. It is used to determine objects linked to a target object by an association, whether explicitly modeled as an Association or implicit. If there is a qualifier attached to the source end of the association, then additional qualifier expressions may be used to specify the values of the qualifying attributes. Associations qualifier The values for the qualifier attributes, if applicable. navigationSource The source denotes the association end Property at the end of the object itself. This is used to resolve ambiguities when the same Classifier is at more than one end (plays more than one role) in the same association. In other cases it can be derived.
Actions taken:
February 28, 2006: received issue
October 16, 2009: closed issue

Discussion:

NavigationCallExp must be the supertype of PropertyCallExp for two reasons:

1.In the reverse case, AssociationClassCallExp would inherit the referredProperty attribute from PropertyCallExp.  However, this would not be applicable because association-class navigation is not a property invocation.
2.A Property can function like an association end even in the absence of an explicit Association, simply by having a Class as its type.  Also, in contradiction of the submitter’s assertion, association ends commonly are ownedAttributes of Classes
The text does reference the UML 1.x AssociationEnd metaclass, which is incorrect

Issue 9796: Section: 7.3.4 (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

We consider a Sequence of instances of a class called 'Example'. This class has an integer attribute called 'ex'. If we have a method specification written as follow: pre: datalist->isTypeOf(Sequence(Example)) post: Sequence{1..datalist->size()}->forAll(n | datalist->at(n).ex = datalist@pre->at(n).ex) I not sure if is correct writes the same specification with the next sentences: pre: datalist->isTypeOf(Sequence(Example)) post: datalist->forAll(n | n.ex = n@pre.ex) The generic questions is: What does the '@pre' operator mean when it is applied to iterators variables (as 'n' in the example)? Is correct the @pre use in this cases? I hope you understand my dude and sorry any gramatical error because my written english is very poor.

Resolution:
Revised Text: Rewrite Section 7.5.14 as follows, using “feature” instead of “property” to include operations and “behavior” instead of “method” to include more than just those behaviors that are the methods of operations: 7.5.14 Previous Values in Postconditions As stated in Section 7.3.4, “Pre- and Postconditions,” on page 8, OCL can be used to specify pre- and postconditions on operations and behaviors in UML. In a postcondition, the expression can refer to values of any feature of an object at two moments in time: the value of a feature at the start of the operation or behavior the value of a feature upon completion of the operation or behavior The value of an operation call or a property navigation in a postcondition is the value upon completion of the operation. To refer to the value of the feature at the start of the operation, one has to postfix the property name with the keyword ‘@pre’: context Person::birthdayHappens() post: age = age@pre + 1 The property age refers to the property of the instance of Person that executes the operation. The property age@pre refers to the value of the property age of the Person that executes the operation, at the start of the operation. In the case of an operation call, the ‘@pre’ is postfixed to the operation name, before the parameters. context Company::hireEmployee(p : Person) post: employees = employees@pre->including(p) and stockprice() = stockprice@pre() + 10 When the pre-value of a feature evaluates to an object, all further properties that are accessed of this object are the new values (upon completion of the operation) of this object. So: a.b@pre.c -- takes the old value of property b of a, say x -- and then the new value of c of x. a.b@pre.c@pre -- takes the old value of property b of a, say x -- and then the old value of c of x. The ‘@pre’ postfix is allowed only in OCL expressions that are part of a Postcondition, and only on invocations of the features of model classifiers. Asking for a current property of an object that has been destroyed during execution of the operation results in null. Also, referring to the previous value of an object that has been created during execution of the operation results in null. In Section 8.3.1 Expressions Core, add a property to the FeatureCallExp metaclass: FeatureCallExp A FeatureCallExp expression is an expression that refers to a feature that is defined for a Classifier in the UML model to which this expression is attached. Its result value is the evaluation of the corresponding feature. Attributes isPre Boolean indicating whether the expression accesses the precondition-time value of the referred feature. Figure 8.3 is updated to show an “isPre : Boolean” attribute in the FeatureCallExp metaclass. In Section 8.3.9 Additional Operations on OCL Metaclasses, subsection OclExpression, the definition of the withAtPre() operation is deleted. In Section 9.3 Concrete Syntax, the Synthesized Attributes of the OperationCallExpCS are updated to utilize the FeatureCallExp::isPre attribute: [E] -- indicate the precondition-time value OperationCallExpCS.ast.referredOperation = OclExpressionCS.ast.type.lookupOperation (simpleNameCS.ast, if argumentsCS->notEmpty() then arguments.ast->collect(type) else Sequence{} endif) OperationCallExpCS.ast.arguments = argumentsCS.ast OperationCallExpCS.ast.isPre = true [F] -- indicate the precondition-time value with the implicit source OperationCallExpCS.ast.arguments = argumentsCS.ast and OperationCallExpCS.ast.referredOperation = env.lookupImplicitOperation(simpleName.ast, if argumentsCS->notEmpty() then arguments.ast->collect(type) else Sequence{} endif) ) OperationCallExpCS.ast.isPre = true In Section 9.3 Concrete Syntax, the occurrences of PropertyCallExpCS are changed to CallExpCS as was the AbstractSyntax. In Section 9.3 Concrete Syntax, the occurrences of ModelPropertyCallExpCS are changed to FeatureCallExpCS as was the AbstractSyntax. In Section 9.3 Concrete Syntax, the occurrences of AttributeCallExpCS are changed to PropertyCallExpCS as was the AbstractSyntax. In Section 9.3 Concrete Syntax, the definition of AttributeCallExpCS is updated with Property terminology as was the Abstract Syntax. It also utilizes the FeatureCallExp::isPre attribute: PropertyCallExpCS This production rule results in a PropertyCallExp. In production [A] the source is explicit, while production [B] is used for an implicit source. Alternative [C] covers the use of a static attribute. [A] PropertyCallExpCS ::= OclExpressionCS ‘.’ simpleNameCS isMarkedPreCS? [B] PropertyCallExpCS ::= simpleNameCS isMarkedPreCS? [C] PropertyCallExpCS ::= pathNameCS Abstract syntax mapping PropertyCallExpCS.ast : PropertyCallExp Synthesized attributes [A] PropertyCallExpCS.ast.referredProperty = OclExpressionCS.ast.type.lookupAttribute(simpleNameCS.ast) [A] PropertyCallExpCS.ast.source = OclExpressionCS.ast [A] PropertyCallExpCS.ast.isPre = isMapkedPreCS->notEmpty() [B] PropertyCallExpCS.ast.referredProperty = env.lookupImplicitAttribute(simpleNameCS.ast) [B] PropertyCallExpCS.ast.source = env.findImplicitSourceForProperty(simpleNameCS.ast) [B] PropertyCallExpCS.ast.isPre = isMarkedPreCS->notEmpty() [C] PropertyCallExpCS.ast.referredProperty = env.lookupPathName(pathNameCS.ast).oclAsType(Property) Inherited attributes [A] OclExpressionCS.env = PropertyCallExpCS.env Disambiguating rules [1] [A, B] ‘simpleName’ is name of a Property of the type of source or if source is empty the name of an attribute of ‘self’ or any of the iterator variables in (nested) scope. In OCL: not PropertyCallExpCS.ast.referredProperty.oclIsUndefined() [2] [C] The pathName refers to a class attribute. env.lookupPathName(pathNameCS.ast).oclIsKindOf(Property) and PropertyCallExpCS.ast.referredProperty.ownerscope = ScopeKind::instance NavigationCallExpCS This production rule represents a navigation call expression. [A] NavigationCallExpCS ::= PropertyCallExpCS [B] NavigationCallExpCS ::= AssociationClassCallExpCS Abstract syntax mapping NavigationCallExpCS.ast : NavigationCallExp Synthesized attributes The value of this production is the value of its child production. [A] NavigationCallExpCS.ast = PropertyCallExpCS.ast [B] NavigationCallExpCS.ast = AssociationClassCallExpCS.ast Inherited attributes [A] PropertyCallExpCS.env = NavigationCallExpCS.env [B] AssociationCl assCallExpCS.env = NavigationCallExpCS.env Disambiguating rules These are defined in the children. In Section 9.3 Concrete Syntax, the AssociationEndCallExpCS subsection and its subsubsections are deleted, as UML 2.x merges the Attribute and AssociationEnd constructs in a single Property metaclass. In Section 9.3 Concrete Syntax, the Synthesized Attributes of the AssociationClassCallExp subsection are updated to utilize the FeatureCallExp::isPre attribute: [A] AssociationClassCallExpCS.ast.referredAssociationClass = OclExpressionCS.ast.type.lookupAssociationClass(simpleNameCS.ast) AssociationClassCallExpCS.ast.source = OclExpressionCS.ast AssociationClassCallExpCS.ast.isPre = isMarkedPreCS->notEmpty() [A] AssociationClassCallExpCS.ast.qualifiers = argumentsCS.ast [B] AssociationClassCallExpCS.ast.referredAssociationClass = env.lookupImplicitAssociationClass(simpleNameCS.ast) AssociationClassCallExpCS.ast.source = env.findImplicitSourceForAssociationClass(simpleNameCS.ast) AssociationClassCallExpCS.ast = isMarkedPreCS->notEmpty() [B] AssociationClassCallExpCS.ast.qualifiers = argumentsCS.ast
Actions taken:
May 27, 2006: received issue
October 16, 2009: closed issue

Discussion:

The usage of @pre is only applicable to the features of model classifiers, as indicated in Section 7.5.14 (Previous Values in Postconditions) which identifies both attributes and operations as “properties”, and in Definition A.31 (Syntax of Expressions in Postconditions) in which it is stated that @pre may be applied to operations that depend on system state, such as operation calls and attribute navigation on objects.

The Abstract Syntax Model is ambiguous in the model of expressions involving @pre.  It only defines an additional operation on the OclExpression metaclass that serves as a factory for OperationCallExps that represent invocations of an atPre() operation.  This atPre() operation in not defined, neither in the Standard Library nor as an additional operation, itself.  This proposed resolution is clearer, more concise, and simpler.  It also does not pre-suppose a mechanism by which evaluation of @pre expressions may be accomplished

Issue 9913: Section: 8.3.5 (ocl2-rtf)

Click here for this issue's archive.
Source: LIANTIS GmbH (Mr. Constantin Szallies, constantin.szallies(at)liantis.com)
Nature: Enhancement
Severity: Significant
Summary:

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

Resolution:
Revised Text: Add to section 9.3 Concrete Syntax the following definitions: NullLiteralExpCS This production rule results in a NullLiteralExp. [A] NullLiteralExpCS ::= ‘null’ Abstract syntax mapping NullLiteralExpCS.ast : NullLiteralExp Synthesized attributes -- none Inherited attributes -- none Disambiguating rules -- none InvalidLiteralExpCS This production rule results in an InvalidLiteralExp. [A] InvalidLiteralExpCS ::= ‘invalid’ Abstract syntax mapping InvalidLiteralExpCS.ast : InvalidLiteralExp Synthesized attributes -- none Inherited attributes -- none Disambiguating rules -- none
Actions taken:
July 11, 2006: received isuse
October 16, 2009: closed issue

Issue 9914: Section: 7.5.9 (ocl2-rtf)

Click here for this issue's archive.
Source: LIANTIS GmbH (Mr. Constantin Szallies, constantin.szallies(at)liantis.com)
Nature: Clarification
Severity: Minor
Summary:

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

Resolution:
Revised Text: In Section 7.5.9, replace " Values for s are the names of the states in the statemachine(s) attached to the Classifier of object." by "Possible states for the operation oclInState(s) are all states of the statemachine that defines the classifier's behaviour"
Actions taken:
July 11, 2006: received issue
October 16, 2009: closed issue

Discussion:

The clarification suggested by the author of the issue solves the problem.

Issue 9915: Using "def" (ocl2-rtf)

Click here for this issue's archive.
Source: LIANTIS GmbH (Mr. Constantin Szallies, constantin.szallies(at)liantis.com)
Nature: Enhancement
Severity: Significant
Summary:

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

Resolution:
Revised Text: (1) In section 7.4.4, just before "The names of the attributes …", add the following paragraph. Operations or attributes defined by "definitions expressions" may be static (classifier scoped). In that case the static keyword should be used before "def". context MyClass; static def : globalId() : Integer = …; (2) In section 7.4.9 add the "static" keyword after the "pre" keyword. (3) In section 12.12.6, replace production rule [B], [B] invOrDefCS[1] ::= ‘def’ (simpleNameCS)? ‘:’ defExpressionCS invOrDefCS[2] by the following: [B] invOrDefCS[1] ::= ('static')? ‘def’ (simpleNameCS)? ‘:’ defExpressionCS invOrDefCS[2]
Actions taken:
July 11, 2006: received issue
October 16, 2009: closed issue

Discussion:

Notation for calling static operations was available but there was no notation their definition (except when the operation is taken from a UML diagram). This is somehow inconsistent. 
The solution is to add the "static" prefix before the "def" keyword to define static helpers.

Issue 10344: Section: 7.4.9 (ocl2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

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

Resolution:
Revised Text: In Section 7.4.9 add the keywords 'body', 'derive' and 'init', inserting them respecting the alphabetical order.
Actions taken:
September 11, 2006: received issue
October 16, 2009: closed issue

Discussion:

'self' is the name of a pre-defined variable and is not a keyword. However body, derive and 'init' are keywords that are used in some parts of section 7 and explicitly defined in section 9 (concrete service). So menyioning of these three keywords is missing in 7.4.9.

Issue 10346: Section: 7.8 (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 12, 2006: received issue
October 16, 2009: closed issue

Discussion:

The difference given by the author of the two variants is good.
However we prefer not to extend section 7.8 with this detailed explanation since the focus here is on syntax subtilities and a reader can make himself the exercise of interpreting correctly the two invariants.


Disposition: Close, No Change.

Issue 10430: Section 7.6.3 (ocl2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Peter Denno, peter.denno(at)nist.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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


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

Resolution:
Revised Text: Update Section 7.6.3 to read as follows: The forAll operation has an extended variant in which two iterators are used. Both iterators will iterate over the complete collection. Effectively this is a forAll on the Cartesian product of the collection with itself.
Actions taken:
November 2, 2006: received issue
October 16, 2009: closed issue

Discussion:

Issue 10431: Section 9.2.2 (ocl2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Peter Denno, peter.denno(at)nist.gov)
Nature: Uncategorized Issue
Severity:
Summary:

"The OCL specification puts no restriction on visibility."


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

Resolution:
Revised Text: In Section 9.2.2, replace the sentence " The OCL specification puts no restriction on visibility." By "The OCL specification puts no restriction on the visibility declared for a property defined in the model (such as 'private', 'protected' or 'public').
Actions taken:
November 2, 2006: received issue
October 16, 2009: closed issue

Discussion:

In fact the text refers to the visibility concept related to UML properties (public, private, protected …). Visibility is not used here in its general meaning.
This can be clarified to avoid any confusion.

Issue 10432: Section "IteratorExpCS" (ocl2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Peter Denno, peter.denno(at)nist.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 2, 2006: received issue
October 16, 2009: closed issue

Discussion:

The parentheses in alternative [A] are balanced; they delineate the optional variable-declaration list (including the ‘|’ bar) and, as a nested optional construct, the second variable.

The [D] and [E] alternatives should be identical in form; this reflects the fundamental similarity of the structure of association-end navigation and assocation-class navigation, even down to the qualifiers list.
Disposition:	Closed, no change

Issue 10433: 11.2.3 (ocl2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Peter Denno, peter.denno(at)nist.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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


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

Resolution:
Revised Text: Update Section 11.2.3 to read: The type OclVoid is a type that conforms to all other types except OclInvalid. It has one single instance, identified as null, that corresponds with the UML LiteralNull value specification.
Actions taken:
November 2, 2006: received issue
October 16, 2009: closed issue

Discussion:

The statements in the discussion of both OclVoid to OclInvalid that they conform to all other types is problematic, because that implies that they conform to one another, resulting in a generalization cycle.  They should neither of them conform to the other, as both are intended as undefined values of ordinary expressions in degenerate situations.

Issue 10434: 11.2.4 (OclInvalid) - similar criticism as 11.2.3 (ocl2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Peter Denno, peter.denno(at)nist.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: Update Section 11.2.3 to read: The type OclInvalid is a type that conforms to all other types except OclVoid. It has one single instance, identified as invalid.
Actions taken:
November 2, 2006: received issue
October 16, 2009: closed issue

Discussion:

The statements in the discussion of both OclVoid to OclInvalid that they conform to all other types is problematic, because that implies that they conform to one another, resulting in a generalization cycle.  They should neither of them conform to the other, as both are intended as undefined values of ordinary expressions in degenerate situations.

Issue 10435: 11.8.1 (ocl2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Peter Denno, peter.denno(at)nist.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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


- What does that mean? It sounds like an admonition to spec writers.
- also "defined" not "defines"
- also "their" not "there"

Resolution:
Revised Text: (1) In Section 11.8 remove the sentence "Whenever a new iterator is added to the library, the mapping to the iterate expression must be defined. If this is not done, the semantics of the new iterator are undefined." (2) In Section 11.8.1, replace the sentence: When new iterator expressions are added to the standard library, their mapping to existing constructs should be fully defined. If this is done, the semantics of the new iterator expression will be defined. By: It is possible to add new iterator expressions in the standard library. If this is done the semantics of a new iterator should be defined by mapping it to existing constructs, in the same way the semantics of pre-defined iterators is done (see Section 11.9).
Actions taken:
November 2, 2006: received issue
October 16, 2009: closed issue

Discussion:

It means that someone defining a new iterator should provide the semantics using the technique used in Section 11.9 for the pre-defined iterators. This could be made clearer by explicitly referring to this Section 11.9. BTW Section 11.8.1 duplicates somehow the sentence that is above in the preamble of 11.8 "Whenever a new iterator is added to the library, the mapping to the iterate expression must be defined. If this is not done, the semantics of the new iterator are undefined."  This duplication leaves the impression of a copy/paste problem. To avoid this we remove the sentence in the preamble and adjust the sentence in 11.8.1.

Issue 10436: 11.2.5 (ocl2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Peter Denno, peter.denno(at)nist.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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


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


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

Resolution:
Revised Text: Update the text in Section 11.2.5 Operations and Well-formedness Rules to read: oclIsTypeOf(t : Classifier) : Boolean Evaluates to true if self is of the type t but not a subtype of t. oclIsKindOf(t : Classifier) : Boolean Evaluates to true if the type of self conforms to t. That is, self is of type t or a subtype of t.
Actions taken:
November 2, 2006: received issue
October 16, 2009: closed issue

Discussion:

Note that this resolution depends on the proposal for resolution of Issue 6532 that discards the OclType metatype in favour of Classifier.

Issue 10437: 11.2.5 (02) (ocl2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Peter Denno, peter.denno(at)nist.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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


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


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

Resolution:
Revised Text: Update the text in section 11.2.5 to read: oclAsType(t : Classifier) : T Evaluates to self, where self is of the type identified by t. The type t may be any classifier defined in the UML model; if the actual type of self at evaluation time does not conform to t, then the oclAsType operation evaluates to null. In the case of feature redefinition, casting an object to a supertype of its actual type does not access the supertype’s definition of the feature; according to the semantics of redefinition, the redefined feature simply does not exist for the object. However, when casting to a supertype, any features additionally defined by the subtype are suppressed. post: (result = self) and result.oclIsTypeOf( t )
Actions taken:
November 2, 2006: received issue
October 16, 2009: closed issue

Discussion:

Note that this resolution depends on the proposal for resolution of Issue 6532 that discards the OclType metatype in favour of Classifier.

Issue 10438: 11.7.1 (ocl2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Peter Denno, peter.denno(at)nist.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: (1) In Section 11.2.3, replace sentence of OclVoid by: "Any property call applied on null results in OclInvalid, except for the operation oclIsUndefined(). OclVoid is itself an instance of the metatype VoidType." By Any property call applied on null results in OclInvalid, except for the operation oclIsUndefined() and oclIsInvalid(). However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as 'isEmpty'). If the source is the null literal, it is implicitly converted to Bag{}. The OclVoid type is an instance of the metatype VoidType. (2) In Section 11.7.1, after isEmpty() definifion add the following note: Note: null->isEmpty() returns 'true', in virtue of the implicit casting from null to Bag{}. (3) In Section 11.7.1, after notEmpty() definifion add the following note: Note: null->notEmpty() returns 'false', in virtue of the implicit casting from null to Bag{}.
Actions taken:
November 2, 2006: received issue
October 16, 2009: closed issue

Discussion:

Similarly as when we write self.manager->isEmpty() this is a short writing of self.manager.asSet()->isEmpty(), the meaning of null->isEmpty() could be Set{}->isEmpty(), except that the decision on what kind of literal collection it is (set, bag, ordered set, sequence). By convention for null we decide the implicit casting  is Bag{}.
Apart this syntax convention, null 
We add a note to clarify this point.

Issue 10439: Recommendations re ptc/2005-06-06 (ocl2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Peter Denno, peter.denno(at)nist.gov)
Nature: Uncategorized Issue
Severity:
Summary:

Recommendation: The specification would be better were it to additionally 
describe a practical grammar useful to tool implementors and persons trying 
to understand what constitutes legal OCL syntax. Of course, we all know that 
even practical OCL grammars are permissive of strings that aren't meaningful 
(for example, 7->isEmpty() is typically legal) but more can be done than is 
expressed by the current description. I am not suggesting that you replace 
the current method of description, but that you add (perhaps only as an 
informative, non-normative appendix) a conventional grammar. The spec, after 
all, is supposed to serve the purposes of implementors. 


There are published papers describing practical grammars for OCL, or I can 
supply you with one, if you'd like. 


PS By "practical grammar" I mean one that limits the look-ahead to a finite 
number wherever possible. It is, of course, the use of OclExpression in the 
RHS of so many productions that runs up against the infinite look-ahead 
problem, and makes the published grammar unusable by implementors.

Resolution: (AS INITIALLY VOTED, DO NOT APPLY SINCE DEFERRED) At the end of 9.2.1 A practical grammar that can be realised by an LALR(1) parser is provided in Section 9.7. Add Sections 9.7 9.7 OCL Grammars The grammars presented in this Section are suitable for implementation by an LALR(1) parser generator such as yacc, bison or LPG after minor spelling adjustments to accommodate toolspecific characteristics. This grammar does not uniquely determine a Concrete Syntax; in many cases a number of alternative Concrete Syntaxes are identified that require disambiguation in accordance with the rules for each candidate Concrete Syntax presented in Section 9.3. The definitions of the IDENTIFIER, INTEGER_LITERAL, REAL_LITERAL, and STRING_LITERAL terminals may be found in Section 9.3 under simpleNameCS, IntegerLiteralExpCS, RealLiteralExpCS and StringLiteralExpCS. 9.7.1 Essential OCL Grammar The Essential OCL grammar defines only those concepts necessary for Essential OCL. The additional concepts for Complete OCL are added by the grammar in Section 9.7.2. Reserved keywords cannot be used as names in any context, unless enclosed by underscoreprefixed single quotes. Restricted keywords can only be used as names following a package or classifier qualification, unless enclosed by underscore-prefixed single quotes. -- Reserved keywords and implies not or xor if then else endif let in false true null invalid self -- Restricted keywords Bag Collection OrderedSet Sequence Set Tuple Boolean Integer Real String UnlimitedNatural OclAny OclInvalid OclVoid -- Terminals INTEGER_LITERAL REAL_LITERAL STRING_LITERAL ----------------------------------------------------------------------- -- Names ----------------------------------------------------------------------- reservedKeyword ::= and reservedKeyword ::= else reservedKeyword ::= endif reservedKeyword ::= if reservedKeyword ::= implies reservedKeyword ::= in reservedKeyword ::= let reservedKeyword ::= not reservedKeyword ::= or reservedKeyword ::= then reservedKeyword ::= xor tupleKeywordCS ::= Tuple reservedKeywordCS ::= reservedKeyword restrictedKeywordCS ::= CollectionTypeIdentifierCS restrictedKeywordCS ::= primitiveTypeCS restrictedKeywordCS ::= oclCS restrictedKeywordCS ::= tupleKeywordCS selfKeywordCS ::= self simpleNameCS ::= IDENTIFIER unreservedSimpleNameCS ::= simpleNameCS unreservedSimpleNameCS ::= restrictedKeywordCS pathNameCS ::= simpleNameCS pathNameCS ::= pathNameCS '::' unreservedSimpleNameCS ----------------------------------------------------------------------- -- Types ----------------------------------------------------------------------- primitiveTypeCS ::= Boolean primitiveTypeCS ::= Integer primitiveTypeCS ::= Real primitiveTypeCS ::= String primitiveTypeCS ::= UnlimitedNatural oclTypeCS ::= OclAny oclTypeCS ::= OclInvalid oclTypeCS ::= OclVoid CollectionTypeIdentifierCS ::= Set CollectionTypeIdentifierCS ::= Bag CollectionTypeIdentifierCS ::= Sequence CollectionTypeIdentifierCS ::= Collection CollectionTypeIdentifierCS ::= OrderedSet typeCS ::= primitiveTypeCS typeCS ::= oclTypeCS typeCS ::= pathNameCS typeCS ::= collectionTypeCS typeCS ::= tupleTypeCS collectionTypeCS ::= CollectionTypeIdentifierCS '(' typeCS ')' tupleTypeCS ::= Tuple '(' tupleTypePartsCSopt ')' tupleTypePartsCSopt ::= $empty tupleTypePartsCSopt ::= tupleTypePartsCS tupleTypePartsCS ::= typedUninitializedVariableCS tupleTypePartsCS ::= tupleTypePartsCS ',' typedUninitializedVariableCS ----------------------------------------------------------------------- -- Declarations ----------------------------------------------------------------------- untypedUninitializedVariableCS ::= simpleNameCS typedUninitializedVariableCS ::= untypedUninitializedVariableCS ':' typeCS untypedInitializedVariableCS ::= untypedUninitializedVariableCS '=' OclExpressionCS typedInitializedVariableCS ::= typedUninitializedVariableCS '=' OclExpressionCS initializedVariableCS ::= untypedInitializedVariableCS initializedVariableCS ::= typedInitializedVariableCS uninitializedVariableCS ::= untypedUninitializedVariableCS uninitializedVariableCS ::= typedUninitializedVariableCS VariableDeclarationCS ::= untypedUninitializedVariableCS VariableDeclarationCS ::= untypedInitializedVariableCS VariableDeclarationCS ::= typedUninitializedVariableCS VariableDeclarationCS ::= typedInitializedVariableCS ----------------------------------------------------------------------- -- Literals ----------------------------------------------------------------------- -- EnumLiteralExpCS is parsed as a PropertyCallExpCS[C] -- LiteralExpCS ::= EnumLiteralExpCS LiteralExpCS ::= CollectionLiteralExpCS LiteralExpCS ::= TupleLiteralExpCS LiteralExpCS ::= PrimitiveLiteralExpCS LiteralExpCS ::= TypeLiteralExpCS CollectionLiteralExpCS ::= CollectionTypeIdentifierCS '{' CollectionLiteralPartsCSopt '}' CollectionLiteralExpCS ::= collectionTypeCS '{' CollectionLiteralPartsCSopt '}' CollectionLiteralPartsCSopt ::= $empty CollectionLiteralPartsCSopt ::= CollectionLiteralPartsCS CollectionLiteralPartsCS ::= CollectionLiteralPartCS CollectionLiteralPartsCS ::= CollectionLiteralPartsCS ',' CollectionLiteralPartCS CollectionLiteralPartCS ::= CollectionRangeCS CollectionLiteralPartCS ::= OclExpressionCS CollectionRangeCS ::= OclExpressionCS '..' OclExpressionCS PrimitiveLiteralExpCS ::= IntegerLiteralExpCS PrimitiveLiteralExpCS ::= RealLiteralExpCS PrimitiveLiteralExpCS ::= StringLiteralExpCS PrimitiveLiteralExpCS ::= BooleanLiteralExpCS PrimitiveLiteralExpCS ::= UnlimitedNaturalLiteralExpCS PrimitiveLiteralExpCS ::= InvalidLiteralExpCS PrimitiveLiteralExpCS ::= NullLiteralExpCS TupleLiteralExpCS ::= Tuple '{' TupleLiteralPartsCS '}' TupleLiteralPartsCS ::= initializedVariableCS TupleLiteralPartsCS ::= TupleLiteralPartsCS ',' initializedVariableCS IntegerLiteralExpCS ::= INTEGER_LITERAL RealLiteralExpCS ::= REAL_LITERAL StringLiteralExpCS ::= STRING_LITERAL StringLiteralExpCS ::= StringLiteralExpCS STRING_LITERAL BooleanLiteralExpCS ::= true BooleanLiteralExpCS ::= false UnlimitedNaturalLiteralExpCS ::= '*' InvalidLiteralExpCS ::= invalid NullLiteralExpCS ::= null -- unqualified pathNameCS is parsed as SimpleNameExpCS -- qualified pathNameCS is parsed as PropertyCallExpCS[C] TypeLiteralExpCS ::= primitiveTypeCS TypeLiteralExpCS ::= oclTypeCS TypeLiteralExpCS ::= collectionTypeCS TypeLiteralExpCS ::= tupleTypeCS ----------------------------------------------------------------------- -- Calls ----------------------------------------------------------------------- CallExpCS ::= FeatureCallExpCS CallExpCS ::= LoopExpCS LoopExpCS ::= IteratorExpCS LoopExpCS ::= IterateExpCS -- IteratorExpCS[A.1] is parsed as OperationCallExpCS[B] IteratorExpCS ::= -- [A.2] primaryExpCS '->' simpleNameCS '(' uninitializedVariableCS '|' OclExpressionCS ')' IteratorExpCS ::= -- [A.3.1] primaryExpCS '->' simpleNameCS '(' simpleNameCS ',' uninitializedVariableCS '|' OclExpressionCS ')' IteratorExpCS ::= -- [A.3.2] primaryExpCS '->' simpleNameCS '(' typedUninitializedVariableCS ',' uninitializedVariableCS '|' OclExpressionCS ')' -- IteratorExpCS[B] is parsed as OperationCallExpCS[C] -- IteratorExpCS[C] is parsed as AssociationClassCallExpCS[A.1] -- IteratorExpCS[D] is parsed as AssociationClassCallExpCS[A] -- IteratorExpCS[E] is parsed as AssociationClassCallExpCS[A] IterateExpCS ::= primaryExpCS '->' simpleNameCS '(' typedInitializedVariableCS '|' OclExpressionCS ')' IterateExpCS ::= primaryExpCS '->' simpleNameCS '(' uninitializedVariableCS ';' typedInitializedVariableCS '|' OclExpressionCS ')' FeatureCallExpCS ::= OperationCallExpCS FeatureCallExpCS ::= PropertyCallExpCS FeatureCallExpCS ::= NavigationCallExpCS -- OperationCallExpCS[A] is realized by the infix OclExpressionCS productions OperationCallExpCS ::= -- [B.1] primaryExpCS '->' simpleNameCS '(' ')' OperationCallExpCS ::= -- [B.2],IteratorExpCS[A.1] primaryExpCS '->' simpleNameCS '(' OclExpressionCS ')' OperationCallExpCS ::= -- [B.3.1] primaryExpCS '->' simpleNameCS '(' notNameExpressionCS ',' argumentsCS ')' OperationCallExpCS ::= -- [B.3.2] primaryExpCS '->' simpleNameCS '(' simpleNameCS ',' argumentsCS ')' OperationCallExpCS ::= -- [C],[E],IteratorExpCS[B] primaryExpCS '.' simpleNameCS isMarkedPreCSopt '(' argumentsCSopt ')' OperationCallExpCS ::= -- [D],[F],[G.1] simpleNameCS isMarkedPreCSopt '(' argumentsCSopt ')' OperationCallExpCS ::= -- [G.2] pathNameCS '::' unreservedSimpleNameCS '(' argumentsCSopt ')' -- OperationCallExpCS[H] is realized by the prefix OclExpressionCS productions OperationCallExpCS ::= -- [I],[J] primaryExpCS '.' pathNameCS '::' unreservedSimpleNameCS isMarkedPreCSopt '(' argumentsCSopt ')' -- NavigationCallExpCS ::= PropertyCallExpCS -- parsed as FeatureCallExpCS NavigationCallExpCS ::= AssociationClassCallExpCS -- PropertyCallExpCS[A] is parsed as AssociationClassCallExpCS[A.1] -- PropertyCallExpCS[B.1] is parsed as a SimpleNameExpCS -- PropertyCallExpCS[B.2] is parsed as a AssociationClassCallExpCS[B.1] PropertyCallExpCS ::= -- [C] excluding [B] pathNameCS '::' unreservedSimpleNameCS isMarkedPreCSopt PropertyCallExpCS ::= -- [D] primaryExpCS '.' pathNameCS '::' unreservedSimpleNameCS isMarkedPreCSopt AssociationClassCallExpCS ::= -- [A.1],PropertyCallExpCS[A],IteratorExpCS[C,D,E] primaryExpCS '.' simpleNameCS isMarkedPreCSopt AssociationClassCallExpCS ::= -- [A.2],IteratorExpCS[D,E] primaryExpCS '.' simpleNameCS '[' argumentsCS ']' isMarkedPreCSopt -- AssociationClassCallExpCS[B.1.1] parsed as SimpleNameExpCS -- AssociationClassCallExpCS[B.1.2] is added by Complete OCL AssociationClassCallExpCS ::= -- [B.2] simpleNameCS '[' argumentsCS ']' isMarkedPreCSopt isMarkedPreCSopt ::= $empty argumentsCSopt ::= $empty argumentsCSopt ::= argumentsCS argumentsCS ::= OclExpressionCS argumentsCS ::= argumentsCS ',' OclExpressionCS ----------------------------------------------------------------------- -- Expressions ----------------------------------------------------------------------- -- An OclExpressionCS comprising just a SimpleNameCS is kept separate as -- SimpleNameExpCS to avoid ambiguity when parsing "a->b(c,d" until the next -- letter resolves the usage as a two iterator or as a two or more argument -- OperationCallExpCS. -- An OclExpressionCS comprising one or more LetExpCS is kept separate to ensure -- that let is right associative, whereas infix operators are left associative. -- a = 64 / 16 / let b : Integer in 8 / let c : Integer in 4 -- is -- a = (64 / 16) / (let b : Integer in 8 / (let c : Integer in 4 )) OclExpressionCS ::= notNameExpressionCS OclExpressionCS ::= SimpleNameExpCS -- VariableExpCS[.1] simpleNameCS parsed as SimpleNameExpCS VariableExpCS ::= -- [.2] selfKeywordCS SimpleNameExpCS ::= -- AssociationClassCallExpCS[B.1.1], -- PropertyCallExpCS[B],VariableExpCS[.1] simpleNameCS notNameExpressionCS ::= impliesNotNameNotLetCS notNameExpressionCS ::= impliesWithLetCS impliesNotLetCS ::= impliesNotNameNotLetCS impliesNotLetCS ::= SimpleNameExpCS impliesNotNameNotLetCS ::= xorNotNameNotLetCS impliesNotNameNotLetCS ::= impliesNotLetCS implies xorNotLetCS impliesWithLetCS ::= xorWithLetCS impliesWithLetCS ::= impliesNotLetCS implies xorWithLetCS xorNotLetCS ::= xorNotNameNotLetCS xorNotLetCS ::= SimpleNameExpCS xorNotNameNotLetCS ::= orNotNameNotLetCS xorNotNameNotLetCS ::= xorNotLetCS xor orNotLetCS xorWithLetCS ::= orWithLetCS xorWithLetCS ::= xorNotLetCS xor orWithLetCS orNotLetCS ::= orNotNameNotLetCS orNotLetCS ::= SimpleNameExpCS orNotNameNotLetCS ::= andNotNameNotLetCS orNotNameNotLetCS ::= orNotLetCS or andNotLetCS orWithLetCS ::= andWithLetCS orWithLetCS ::= orNotLetCS or andWithLetCS andNotLetCS ::= andNotNameNotLetCS andNotLetCS ::= SimpleNameExpCS andNotNameNotLetCS ::= equalityNotNameNotLetCS andNotNameNotLetCS ::= andNotLetCS and equalityNotLetCS andWithLetCS ::= equalityWithLetCS andWithLetCS ::= andNotLetCS and equalityWithLetCS equalityNotLetCS ::= equalityNotNameNotLetCS equalityNotLetCS ::= SimpleNameExpCS equalityNotNameNotLetCS ::= relationalNotNameNotLetCS equalityNotNameNotLetCS ::= equalityNotLetCS '=' relationalNotLetCS equalityNotNameNotLetCS ::= equalityNotLetCS '<>' relationalNotLetCS equalityWithLetCS ::= relationalWithLetCS equalityWithLetCS ::= equalityNotLetCS '=' relationalWithLetCS equalityWithLetCS ::= equalityNotLetCS '<>' relationalWithLetCS relationalNotLetCS ::= relationalNotNameNotLetCS relationalNotLetCS ::= SimpleNameExpCS relationalNotNameNotLetCS ::= additiveNotNameNotLetCS relationalNotNameNotLetCS ::= relationalNotLetCS '>' additiveNotLetCS relationalNotNameNotLetCS ::= relationalNotLetCS '<' additiveNotLetCS relationalNotNameNotLetCS ::= relationalNotLetCS '>=' additiveNotLetCS relationalNotNameNotLetCS ::= relationalNotLetCS '<=' additiveNotLetCS relationalWithLetCS ::= additiveWithLetCS relationalWithLetCS ::= relationalNotLetCS '>' additiveWithLetCS relationalWithLetCS ::= relationalNotLetCS '<' additiveWithLetCS relationalWithLetCS ::= relationalNotLetCS '>=' additiveWithLetCS relationalWithLetCS ::= relationalNotLetCS '<=' additiveWithLetCS additiveNotLetCS ::= additiveNotNameNotLetCS additiveNotLetCS ::= SimpleNameExpCS additiveNotNameNotLetCS ::= multiplicativeNotNameNotLetCS additiveNotNameNotLetCS ::= additiveNotLetCS '+' multiplicativeNotLetCS additiveNotNameNotLetCS ::= additiveNotLetCS '-' multiplicativeNotLetCS additiveWithLetCS ::= multiplicativeWithLetCS additiveWithLetCS ::= additiveNotLetCS '+' multiplicativeWithLetCS additiveWithLetCS ::= additiveNotLetCS '-' multiplicativeWithLetCS multiplicativeNotLetCS ::= multiplicativeNotNameNotLetCS multiplicativeNotLetCS ::= SimpleNameExpCS multiplicativeNotNameNotLetCS ::= unaryNotNameNotLetCS multiplicativeNotNameNotLetCS ::= multiplicativeNotLetCS '*' unaryNotLetCS multiplicativeNotNameNotLetCS ::= multiplicativeNotLetCS '/' unaryNotLetCS multiplicativeWithLetCS ::= unaryWithLetCS multiplicativeWithLetCS ::= multiplicativeNotLetCS '*' unaryWithLetCS multiplicativeWithLetCS ::= multiplicativeNotLetCS '/' unaryWithLetCS unaryNotLetCS ::= unaryNotNameNotLetCS unaryNotLetCS ::= SimpleNameExpCS unaryNotNameNotLetCS ::= primaryNotNameCS unaryNotNameNotLetCS ::= '-' unaryNotLetCS unaryNotNameNotLetCS ::= not unaryNotLetCS unaryWithLetCS ::= LetExpCS -- OclExpressionCS[D] unaryWithLetCS ::= '-' unaryWithLetCS unaryWithLetCS ::= not unaryWithLetCS primaryExpCS ::= primaryNotNameCS primaryExpCS ::= SimpleNameExpCS primaryNotNameCS ::= CallExpCS -- OclExpressionCS[A] primaryNotNameCS ::= VariableExpCS -- OclExpressionCS[B] primaryNotNameCS ::= LiteralExpCS -- OclExpressionCS[C] -- primaryNotNameCS ::= OclMessageExpCS -- OclExpressionCS[E] is added by Complete OCL primaryNotNameCS ::= IfExpCS -- OclExpressionCS[F] primaryNotNameCS ::= '(' OclExpressionCS ')' IfExpCS ::= if OclExpressionCS then OclExpressionCS else OclExpressionCS endif LetExpCS ::= let letVariablesCS in OclExpressionCS letVariablesCS ::= typedInitializedVariableCS letVariablesCS ::= letVariablesCS ',' typedInitializedVariableCS 9.7.2 Complete OCL Grammar The Complete OCL grammar is an addition to the Essential OCL grammar. -- Reserved keywords body context def derive endpackage init inv package post pre static -- Restricted keywords OclMessage ----------------------------------------------------------------------- -- Names ----------------------------------------------------------------------- reservedKeyword ::= body reservedKeyword ::= context reservedKeyword ::= def reservedKeyword ::= derive reservedKeyword ::= endpackage reservedKeyword ::= init reservedKeyword ::= inv reservedKeyword ::= package reservedKeyword ::= post reservedKeyword ::= pre reservedKeyword ::= static unreservedSimpleNameCSopt ::= $empty unreservedSimpleNameCSopt ::= unreservedSimpleNameCS ----------------------------------------------------------------------- -- Types ----------------------------------------------------------------------- oclTypeCS ::= OclMessage typeCSopt ::= $empty typeCSopt ::= typeCS ----------------------------------------------------------------------- -- Calls ----------------------------------------------------------------------- OperationCallExpCS ::= -- [B] primaryExpCS '->' simpleNameCS isMarkedPreCS '(' argumentsCSopt ')' AssociationClassCallExpCS ::= -- [B.1],PropertyCallExpCS[B] simpleNameCS isMarkedPreCS isMarkedPreCS ::= '@' pre isMarkedPreCSopt ::= isMarkedPreCS OclMessageExpCS ::= primaryExpCS '^^' simpleNameCS '(' OclMessageArgumentsCSopt ')' OclMessageExpCS ::= primaryExpCS '^' simpleNameCS '(' OclMessageArgumentsCSopt ')' OclMessageArgumentsCSopt ::= $empty OclMessageArgumentsCSopt ::= OclMessageArgumentsCS OclMessageArgumentsCS ::= OclMessageArgCS OclMessageArgumentsCS ::= OclMessageArgumentsCS ',' OclMessageArgCS OclMessageArgCS ::= '?' OclMessageArgCS ::= '?' ':' typeCS OclMessageArgCS ::= OclExpressionCS ----------------------------------------------------------------------- -- Expressions ----------------------------------------------------------------------- primaryNotNameCS ::= OclMessageExpCS ----------------------------------------------------------------------- -- Contexts ----------------------------------------------------------------------- packageDeclarationsCS ::= packageDeclarationCS packageDeclarationsCS ::= packageDeclarationsCS packageDeclarationCS_A packageDeclarationCS ::= packageDeclarationCS_A packageDeclarationCS ::= packageDeclarationCS_B packageDeclarationCS_A ::= package pathNameCS contextDeclsCSopt endpackage packageDeclarationCS_B ::= contextDeclsCS contextDeclsCSopt ::= $empty contextDeclsCSopt ::= contextDeclsCS contextDeclsCS ::= contextDeclCS contextDeclsCS ::= contextDeclsCS contextDeclCS contextDeclCS ::= propertyContextDeclCS contextDeclCS ::= classifierContextDeclCS contextDeclCS ::= operationContextDeclCS propertyContextDeclCS ::= context pathNameCS '::' unreservedSimpleNameCS ':' typeCS initOrDerValuesCS initOrDerValuesCS ::= initOrDerValueCS initOrDerValuesCS ::= initOrDerValuesCS initOrDerValueCS initOrDerValueCS ::= init ':' OclExpressionCS initOrDerValueCS ::= derive ':' OclExpressionCS classifierContextDeclCS ::= context pathNameCS invOrDefsCS classifierContextDeclCS ::= context simpleNameCS ':' pathNameCS invOrDefsCS invOrDefsCS ::= invOrDefCS invOrDefsCS ::= invOrDefsCS invOrDefCS invOrDefCS ::= inv unreservedSimpleNameCSopt ':' OclExpressionCS invOrDefCS ::= def unreservedSimpleNameCSopt ':' defExpressionCS invOrDefCS ::= static def unreservedSimpleNameCSopt ':' defExpressionCS defExpressionCS ::= typedUninitializedVariableCS '=' OclExpressionCS defExpressionCS ::= operationCS1 '=' OclExpressionCS operationContextDeclCS ::= context operationCS2 prePostOrBodyDeclsCS prePostOrBodyDeclsCS ::= prePostOrBodyDeclCS prePostOrBodyDeclsCS ::= prePostOrBodyDeclsCS prePostOrBodyDeclCS prePostOrBodyDeclCS ::= pre unreservedSimpleNameCSopt ':' OclExpressionCS prePostOrBodyDeclCS ::= post unreservedSimpleNameCSopt ':' OclExpressionCS prePostOrBodyDeclCS ::= body unreservedSimpleNameCSopt ':' OclExpressionCS operationCS1 ::= simpleNameCS '(' parametersCSopt ')' ':' typeCSopt operationCS2 ::= pathNameCS '::' unreservedSimpleNameCS '(' parametersCSopt ')' ':' typeCSopt parametersCSopt ::= $empty parametersCSopt ::= parametersCS parametersCS ::= VariableDeclarationCS parametersCS ::= parametersCS ',' VariableDeclarationCS Disposition: Deferred NOTE: RESOLVED in Ballot 1 but DEFERRED by disposition of issue 15761
Revised Text:
Actions taken:
November 2, 2006: received issue

Discussion:

Good suggestion. Deferred since such grammar need to be defined carefully. The OCL 2.1 specification provides only a partial and ambiguous grammar some
of whose problems may be resolved by application of the disambiguating rules.
Provision of a complete unambiguous grammar requires the clear semantics for
reserved words that may be found in Issue 14583. Resolution of reserved word
semantics highlights a number of other problems.
The Essential OCL and Complete OCL grammars presented here therefore
assume adoption of the following resolutions:
Issue 12953: Collection Literals with explicit element types
Issue 14196: Integration of UnlimitedNaturalLiteralExpCS Issue 14236: Integration of InvalidLiteralExpCS and NullLiteralExpCS
Issue 14237: CollectionRangeCS separator is DotDot.
Issue 14357: Token Concrete Syntaxes: String Literals may be concatenated.
Issue 14582: Precedence and Associativity.
Issue 14583: Reserved Words.
false, invalid, null, self, true are reserved words.
Boolean, Integer, Real, String, UnlimitedNatural, OclAny, OclInvalid, OclVoid,
Bag, Collection, OrderedSet, Sequence, Set, Tuple are restricted words.
body, context, def, derive, endpackage, init, inv, package, post, pre, static are
reserved words in Complete OCL only.
OclMessage is a restricted word in Complete OCL only.
Issue 14584: TupleLiteralExp part type inference.
Issue 14585: TypeLiteralExpCS is introduced.
Issue 14586: named-self classifierContextDeclCS is supported.
Issue 14587: attrOrAssocContextCS is renamed.
Practical Grammar
The LALR(1) grammar in the revised text replaces the unrealisable
OperationCallExpCS[A] and OperationCallExpCS[H] by a clear grammar in which
precedence and associativity are explicit. Atomic terms such as () and if...endif
are primaryExpCS. The awkward let..in.. is both high and low precedence. All
infix operators are left associative.
The OCL 2.1 grammar is difficult to parse because the presentation in Section
9.3 contains
• obvious conflicts (PropertyCallExpCS is directly a FeatureCallExpCS and
indirectly a FeatureCallExpCS as a NavigationCallExpCS)
• subtle conflicts (EnumLiteralExpCS is a PropertyCallExpCS[C])
• no precedence or associativity grammar
• no identifier or string grammar • unclear reserved word policy
Once these problems are resolved the grammar remains difficult to parse without
semantic information because
• LetExpCS is both high and low precedence
• OperationCallExpCS[B] and IteratorExpCS[A] require a lookahead to the
"ß" token to resolve "c" as a VariableDeclarationCS or a VariableExpCS in
"a->b(c,dß".
These problems are resolved by expressing the infix and prefix grammar to
define precedence and associativity, while allowing use of a simpleNameCS in
the awkward overlap between OperationCallExpCS[B] and IteratorExpCS[A].

Issue 10561: inclusion of Regular Expression support (ocl2-rtf)

Click here for this issue's archive.
Source: SAIC (Mr. Jim Bonang, james.j.bonang(at)saic.com)
Nature: Enhancement
Severity: Significant
Summary:

The Object Constraint Language (OCL) is an integral part of the Unified Modeling Language (UML) and is often used separately as a general constraint specification language in software development tools. For example, OCL is incorporated in the Generic Modeling Environment (GME) developed by the Institute of Software Integrated Systems (ISIS) of Vanderbilt University (http://www.isis.vanderbilt.edu/default.asp The GME implementation extends the OCL standard to include Regular Expressions. A Regular Expression is a pattern that describes (or matches) a set of strings where the pattern is itself a string and conforms to a specific syntax. Regular Expressions are ideal for expressing format constraints on OCL String values. Moreover, Regular Expressions are widely used, familiar to many software developers and complement the OCL’s already powerful constraint specification syntax. Unfortunately, Regular Expressions are not currently supported in OCL Version 2.0. Augmenting the OCL standard with Regular Expressions will improve OCL’s constraint specification capabilities for String values with a powerful, familiar notation and would also codify existing practice as manifested in tools such as GME. Please consider the inclusion of Regular Expression support in future releases of the Object Constraint Language (OCL) specification.

Resolution:
Revised Text:
Actions taken:
January 3, 2007: received issue

Discussion:

Good suggestion. It can be done by augmenting the standard library.
Deferred for timing reasons.


Disposition:	Deferred

Issue 10782: Naming of Constraints in OCL (ocl2-rtf)

Click here for this issue's archive.
Source: EMC (Mr. George Ericson, ericson_george(at)emc.com)
Nature: Uncategorized Issue
Severity:
Summary:

I find in the OCL document section "7.3.3. Invariants" that I can name an invariant  as in:
 
"context" <contextdeclaration> "inv" <constraintname> ":" ...
 
I haven't figured out how to parse the document well enough to be clear if this is formally defined.
 
And the real question is whether this applies to pre, post, body, init, and derived constraints.
 
Does it?  
 
If not it would be useful to add.

Resolution:
Revised Text:
Actions taken:
February 8, 2007: received issue
October 16, 2009: closed issue

Discussion:

The syntax is in fact already formally defined in Section 12.12.6 InvOrDefCS.

Disposition:	Closed, no change

Issue 10786: Naming of Constraints in OCL (02) (ocl2-rtf)

Click here for this issue's archive.
Source: EMC (Mr. George Ericson, ericson_george(at)emc.com)
Nature: Uncategorized Issue
Severity:
Summary:

OCL Specification, v2.0

Section "7.3.3. Invariants" provides a means to name an invariant  as in:

"context" <contextdeclaration> "inv" <constraintname> ":" ...
 
The document does not seem to define this capability formally and I would like to see it also applied to pre, post, body, init, and derived constraints.

Resolution:
Revised Text:
Actions taken:
February 23, 2007: received issue

Issue 10787: OCL Collections applied to Properties (ocl2-rtf)

Click here for this issue's archive.
Source: EMC (Mr. George Ericson, ericson_george(at)emc.com)
Nature: Uncategorized Issue
Severity:
Summary:

OCL Specification, v2.0
 
The specification does not make it clear how to apply collection operations to properties.
 
For instance, assume
 
class A {
    int x[];
}
 
It appears that an invariant constraint that asserts that one of the entries in A.x must be 5 might be
 
context A
inv self.x->exists( p | p=5 )
 
However, this is a guess and does not appear to be entirely justified by the text.

Resolution:
Revised Text:
Actions taken:
February 23, 2007: received issue

Issue 10825: ownership of association ends does not matter for traversal in OCL (ocl2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Andreas Maier, maiera(at)de.ibm.com)
Nature: Clarification
Severity: Minor
Summary:

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



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


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


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


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

Resolution:
Revised Text: In Section 7.5.3 AssociationEnds and Navigation, add a subsection following the “Missing AssocationEnd Names” as follows: Ends Owned by Associations In a UML association, an end may be owned by the Classifier at that end, or by the association, itself. The ownership of the end is not significant to OCL. In either case, the association end is considered as a property of the Classifier and can be navigated from that end to the other. Note that navigation of association-owned ends is an optional compliance point for OCL implementations, as per Table 2.1.
Actions taken:
March 17, 2007: received issue
October 16, 2009: closed issue

Discussion:

The intent for OCL to support navigation of association-owned ends is retained, with clarification of the implication on implementations.

Issue 10921: TypeType (ocl2-rtf)

Click here for this issue's archive.
Source: Hendryx & Associates (Mr. Stan Hendryx, stan(at)hendryxassoc.com)
Nature: Uncategorized Issue
Severity:
Summary:

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


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

Resolution:
Revised Text: Delete the TypeType and ElementType metaclasses from the Figures 8.1 and 13.1. Delete the description of ElementType from Section 8.2 The Types Package. Delete Section 11.3 Special Types. The OclElement and OclType types that it defines are instances of the deleted ElementType and TypeType metatypes.
Actions taken:
April 16, 2007: received issue
October 16, 2009: closed issue

Discussion:

Not only is the TypeType metatype not defined, it is not used by the Expressions package (at least, not as indicated by the abstract-syntax mappings in Section 9.3 Concrete Syntax).  Moreover, the usage of the UML Classifier metaclass in OCL obviates the need for an OclType enumeration in OCL 2.x.

A similar argument can be made for the obsoletion of the ElementType metatype and its instance the OclElement enumeration.  The expressive power of the UML infrastructure makes it possible for the OCL StateExp to define an association with the UML State metaclass without the need for an artificial enumeration type.

Issue 10946: Collection element type serialization (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

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


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


Suggest: 


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

Resolution:
Revised Text: Update Section 12.2 “The ExpressionInOcl Type” to add a new composite aggregation of Classifier, to provide for ownership of the generated types required by the body expression. Specifically, Update Figure 12.1 “Metaclass ExpressionInOcl” to show a composite aggregation between ExpressionInOcl (role name “owningExpression”, non-navigable) and Classifier (role name “generatedType”, composite, navigable) Update Section 12.2.1 “ExpressionInOcl”, subsection “Associations”, to add a description of the generatedType association end: Types, such as collection types, that are created on demand by OCL to serve as the types of OclExpressions in the bodyExpression. Update Section 8.2.2 “Well-formedness Rules for the Types Package” to remove the subsection “Classifier” with its one constraint stipulating the unique definition of collection types for a given element type.
Actions taken:
March 26, 2007: received issue
October 16, 2009: closed issue

Discussion:

The submitter’s proposal does not address the problem of referencing nested collection types (collections of collections).  Nor does it address other implicitly-generated types such as MessageTypes and TupleTypes. A more general solution is to provide, in the top-level constraint context, ownership of these types so that they can be serialized together with the constraint that depends on them.  The assumption is that a namespace is not required for these types as they are artificial, anyway, and that replication of equivalent types in multiple constraints can be resolved by the OCL tool.

Currently, OCL defines well-formedness rules for the Classifier metaclass stipulating that for every classifier, there is at most one instance of each of the four concrete collection types.  It is not at all clear how this should relate to the Environment construct, or what the scope of allInstances() is, in practice.  Moreover, it is not necessary to require this uniqueness of collection types because the conformance rules completely define the equivalence of collection types of the same kind and element type.  An OCL tool may be given the freedom to replicate collection types for its own purposes, for example to ensure consistent serialization of expressions without compromising the OCL semantics.  It is worth noting that no such uniqueness restriction is currently defined for the other dynamically-generated types, the TupleTypes and MessageTypes.

Issue 10969: Usage of initialization and derivation constraints on the same property (ocl2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Andreas Maier, maiera(at)de.ibm.com)
Nature: Clarification
Severity: Minor
Summary:

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


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


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

Resolution:
Revised Text: At the end of Section 7.3.7, add the following paragraph: "The derivation constraint must be satisfied at any time, hence the derivation includes the initialization. Both are allowed on the same property but they must not be contradictory. For each property there should be at most one initialization constraint and at most one derivation constraint.
Actions taken:
April 25, 2007: received issue
October 16, 2009: closed issue

Discussion:

The suggested clarifications make sense. Added in section 7.3.7.
Revised Text:

Issue 11085: 8.2.2 Well-formedness Rules for the Types Package (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

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

Resolution:
Revised Text: n Section 8.2.1 TupleType, replace: context TupleType inv: TupleType.allInstances()->forAll (t | ( t.allProperties()->forAll (tp | -- make sure at least one tuplepart has the same name -- (uniqueness of tuplepart names will ensure that not two -- tupleparts have the same name within one tuple) self.allProperties()->exists(stp|stp.name = tp.name) and -- make sure that all tupleparts with the same name conforms. self.allProperties()->forAll(stp | (stp.name = tp.name) and stp.type.conformsTo(tp.type)) ) implies self.conformsTo(t) ) By context TupleType inv: TupleType.allInstances()->forAll (t | ( t.allProperties()->forAll (tp | -- make sure at least one tuplepart has the same name -- (uniqueness of tuplepart names will ensure that not two -- tupleparts have the same name within one tuple) self.allProperties()->exists(stp|stp.name = tp.name) and -- make sure that all tupleparts with the same name conforms. self.allProperties()->forAll(stp | (stp.name = tp.name) implies stp.type.conformsTo(tp.type)) ) implies self.conformsTo(t) )
Actions taken:
May 31, 2007: received issue
October 16, 2009: closed issue

Discussion:

Fixing needed "(stp.name = tp.name) and …" 
becomes "(stp.name = tp.name) implies …"

Issue 11086: missing closing parethesis inthese two expressions (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

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

Resolution:
Revised Text: (1) In Section 8.2.2 Well-formedness Rules for the Types Package, add a cmose parenthesis at the end of OCL constraint [2] of MessageType. (2) In Section 8.2.2 Well-formedness Rules for the Types Package, add a cmose parenthesis at the end of OCL constraint [3] of MessageType.
Actions taken:
May 31, 2007: received issue
October 16, 2009: closed issue

Discussion:

Correct, two parenthesis are missing.

Issue 11097: Dynamic typing with allInstances() (ocl2-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Tomas Juknevicius, tomasjkn(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

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


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


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


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


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


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



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


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


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


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


context whatever inv:
let s:Set(Classifier) = Set{classFoo, classBar} in
s->allInstances()->any(true)->any(true).someField = someValue


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


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



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



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

Resolution:
Revised Text:
Actions taken:
June 11, 2007: received issue
October 16, 2009: closed issue

Discussion:

The description of allInstances() is already clear that it may only be applied to classifiers of finite extent, such as user-defined Classes.  In particular, it does not apply to DataTypes, which by definition have unbounded extents, and this includes collection types such as Set(Classifier).  Thus, much of the submitter’s argument is faulty.

Disposition:	Closed, no change

Issue 11098: Section: 7.4.7, 7.4.9, 9.3.2 (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

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

Resolution:
Revised Text: Update sections 7.4.7 and 9.3.2 to insert the let-in expression at the bottom of the precedence scale: 1. ... 2.“implies” 3.“let-in”
Actions taken:
June 5, 2007: received issue
October 16, 2009: closed issue

Discussion:

Most of the keywords listed by the submitter are not used in the syntax of expressions, but of constraint context declarations.  Only the ‘let’ and ‘in’ keywords need to be addressed.

Issue 12378: Section 8.2 InvalidType (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text: Update the description in Section 8.2 The Types Package InvalidType represents a type that conforms to all types except the VoidType type. The only instance of InvalidType is OclInvalid, which is further defined in the standard library. Furthermore OclInvalid has exactly one runtime instance identified as invalid.
Actions taken:
April 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

The statements in the discussion of both OclVoid to OclInvalid that they conform to all other types is problematic, because that implies that they conform to one another, resulting in a generalization cycle.  They should neither of them conform to the other, as both are intended as undefined values of ordinary expressions in degenerate situations

Issue 12419: CollectionType and CollectionKind (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The abstractness of CollectionType and corresponding existence of the Collection CollectionKind is inconsistent:
--
9.3 collectionTypeCS synthesized attributes, page 79, contains:


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


using CollectionKind::Collection.
--
8.3.5 CollectionKind, page 48, Collection is not one of the enumeration values.
--
11.6.1, page 144, specifies that Collection is an instance of CollectionType
requiring Collection to not be abstract.
--
8.2 CollectionType, page 34, CollectionType is identified as an abstract class.
--
An expression like the following is valid:


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


and demonstrates the need for a concrete CollectionType.
--
Recommendation:


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

Resolution:
Revised Text: Update Figures 8.1 and 13.1 to remove the italic style from CollectionType. Update Section 8.2 description of the CollectionType metaclass to read thus: CollectionType describes a list of elements of a particular given type. CollectionType is a concrete metaclass whose instances are the family of abstract Collection(T) data types. Its subclasses are SetType, OrderedSetType, SequenceType, and BagType, whose instances are the concrete Set(T), OrderedSet(T), Sequence(T), and Bag(T), data types, respectively. Part of every collection type is the declaration of the type of its elements (i.e., a collection type is parameterized with an element type). In the metamodel, this is shown as an association from CollectionType to Classifier. Note that there is no restriction on the element type of a collection type. This means in particular that a collection type may be parameterized with other collection types allowing collections to be nested arbitrarily deep. Update Figures 8.7 and 13.8 to add Collection to the CollectionKind enumeration. Update section 8.3.5 Literal Expressions: CollectionKind The CollectionKind enumeration lists the kinds of collections. Its literals are Collection, Set, OrderedSet, Bag, and Sequence.
Actions taken:
April 19, 2008: received issue
October 16, 2009: closed issue

Discussion:

There is no inconsistency in CollectionType being concrete while Collection(T) is abstract; they are defined on different metalevels.  Indeed, the Collection(T) type would not exist if CollectionType were abstract, as it would then not be permitted to have instances

Issue 12438: last line on page 28 (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text: n Section 7.6.5, at the en of page 28, replace: acc = <expression-with-elem-and-acc> by acc.add(<expression-with-elem-and-acc>
Actions taken:
May 13, 2008: received issue
October 16, 2009: closed issue

Issue 12439: Section: A/1.1.1 Types (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text: Replace " All type domains include an undefined value that allows to operate with unknown or “null” values" by 'All type domains include an invalid and a null value that allows one to operate respectively with unknown and “null” values.
Actions taken:
May 13, 2008: received issue
October 16, 2009: closed issue

Discussion:

The rresolution needs to take into account the fact that Null and Invalid are introduced in OCL2 replacing undefined.

Issue 12440: Section: A/1.1.5 Associations (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text: In Section A/1.1.5 Associations replace " that associates (sa) = <oc, c>." by " that associates (sa) = <c, c>."
Actions taken:
May 13, 2008: received issue
October 16, 2009: closed issue

Issue 12441: Section: A/1.1.5 Associations -- missing word (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text: .In Section A/1.1.5 Associations, replace "The following function navends give ...." by "The following function navends gives ...."
Actions taken:
May 13, 2008: received issue
October 16, 2009: closed issue

Issue 12442: Section: A/1.1.5 Associations (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text: In Section A/1.1.5, replace the uppercase lambda in the example "participating" by "and" .
Actions taken:
May 13, 2008: received issue
October 16, 2009: closed issue

Issue 12443: Section: A/1.1.6 Generalization (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text: see page 166 of ptc/2009-05-04
Actions taken:
May 13, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex to Framemaker conversion. Mathematical symbols were often badly converted. The correct text is in the original from annex A of ptc/03-10-14.

Issue 12444: Section: A/1.1.6 Generalization - editorial issues (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text: In Section A/1.1.6 Generalization, replace the actual enumeration starting with "1. Attributes …" by: SEE page 168 of ptc/2009-05-04
Actions taken:
May 13, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex to Framemaker conversion. Mathematical symbols were often badly converted. The correct text is in the original from annex A of ptc/03-10-14.

Issue 12445: Section: A/1.2.1 Objects (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

In Definition A.10 Object Identifiers, part ii, you have the domain of a class c defined as: ICLASS(c') = U{oid(c) | c' ? CLASS ^ c' "gr<" c}. where I've used "gr<" for the generalization relation. I see 4 things that ought to be changed: 1. The initial c' should obviously be a c. 2. The oid(c) should be oid(c') 3. We have still another symbol for "and" 4. There's an extraneous newline before the final c.

Resolution:
Revised Text: see page 169 of ptc/2009-05-04
Actions taken:
May 13, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex to Framemaker conversion. Mathematical symbols were often badly converted. The correct text is in the original from annex A of ptc/03-10-14.

Issue 12446: Section: A/1.2.4 System State (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text: see page 170 of ptc/2009-05-04
Actions taken:
May 13, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex to Framemaker conversion. Mathematical symbols were often badly converted. The correct text is in the original from annex A of ptc/03-10-14.

Issue 12447: Section: A/2.2 Common Operations on All Types (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text: In Section A/2.2, replace "allows to check…" by "... allows one to check....".
Actions taken:
May 13, 2008: received issue
October 16, 2009: closed issue

Issue 12448: section 7.4.6 (p. 12) (ocl2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

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

Resolution: The problem is fixed by resolution of issue 7341. Casting and accessing properties from a supertype are two different things. Disposition: See Issue 7341 for disposition
Revised Text:
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

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


Disposition:	See Issue 7341 for disposition

Issue 12449: no explanations about how to manipulate optional and multivalued attributes (ocl2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

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

Resolution:
Revised Text:
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

Associations are attributes.  No further information is required.
Disposition:	Closed, no change

Issue 12450: The Tuple constructor is problematic (ocl2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

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

Resolution:
Revised Text:
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

The discussion of tuple literal expressions in Section 7.5.15 Tuples is quite thorough.  The description of the abstract syntax of the TupleLiteralExp in Section 8.3.5 is terse but complete, and the concrete syntax of tuple literals in Section 9.3 is also complete.
Disposition:	Closed, no change

Issue 12451: OrderedSet collection (ocl2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

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

Resolution:
Revised Text: In the table 7.3 add a row between Bag(T1) and Integer with the following content: OrderedSet(T1) | Collection(T2) | if T1 conforms to T2
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

Various issue resolution solve the problem mentioned by the reporter. The table 7.3 was not yet completed. This resolution solves that. 
Regarding the difference between OrderedSet and Sequence it is very clear in the types section.

Issue 12452: Recursivity is not explicitly addressed with examples (ocl2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

Recursivity is not explicitly addressed with examples, although it is mentioned in several places. For example, in p. 16 it is said "The right-hand-side of this definition may refer to the operation being defined (i.e., the definition may be recursive) as long as the recursion is not infinite." I my course I have put the following example (slide 19) A method that obtains the direct and indirect descendants of a person context Person::descendants(): Set body: result = self.children->union( self.children->collect(c | c.descendants()) ) But there is no way to verify whether the above definition, although conceptually correct, is OK with respect to OCL's syntax. Similarly, the same problem arises with recursive association classes, which is covered in Section 7.5.4. I have covered this in my course in slides 29-30 A person is currently married to at most one person context Person inv: self.marriage[wife]->select(m | m.ended = false)->size()=1 and self.marriage[husband]->select(m | m.ended = false)->size()=1 Operation that selects the current spouse of a person context Person::currentSpouse() : Person pre: self.isMarried = true body: if gender = Gender::male self.marriage[wife]->select(m | m.ended = false).wife else self.marriage[husband]->select(m | m.ended = false).husband end However, I suppose that the syntax for the operation currentSpouse is OK with respect to OCL's syntax, although it is not specified explicitly.

Resolution:
Revised Text:
Actions taken:
May 14, 2008: received issue

Discussion:

Deferred for timing reasons. In order to introduce the suggested examples in Section 7 some verification will be needed.

Disposition:	Deferred

Issue 12453: Mismatch between the definition of operators in, e.g., Section 11.7.1 and i (ocl2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

Mismatch between the definition of operators in, e.g., Section 11.7.1 and in Table A.3: product operation is missing in the latter. By the way, there are many printing problems in this table. Similar mismatch: flatten operation is specified for Sets (p. 147) for Bags (p. 151) and for Sequences (p. 152) but are not mentioned in the corresponding tables in Annex A. By the way, whey flatten is not specified for OrderedSets? Why several methods specified for Sets and Bags (union, intersection, etc.) but not for OrderedSets?

Resolution:
Revised Text:
Actions taken:
May 14, 2008: received issue

Discussion:

For timing issues all issues concerning Annex A are deferred.

Disposition:	Deferred

Issue 12454: The constraint [1] on the TupleLiteralPart metaclass is overconstrained (ocl2-rtf)

Click here for this issue's archive.
Source: Zeligsoft, Inc. (Mr. Christian W. Damus, nobody)
Nature: Revision
Severity: Significant
Summary:

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

Resolution:
Revised Text: In Page 55, Section 8.3.7 Replace [1]The type of the attribute is the type of the value expression. context TupleLiteralPart inv: attribute.type = value.type by: [1]The type of the attribute conforms to the type of the value expression. context TupleLiteralPart inv: attribute.type.conformsTo(value.type)
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Issue 12456: Errors in examples (ocl2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

The examples are based on the sample model (Companies and Employees). However, as pointed out in http://www.empowertec.de/products/analyze-spec-expressions.htm there are many errors in the examples. You will find at the address http://cs.ulb.ac.be/oclnotes.pdf the slides that I use in my course in which I slighty modified the example so that all example expressions are (supposed to be) correct.

Resolution:
Revised Text:
Actions taken:
May 14, 2008: received issue

Issue 12457: Section: A/2.3 Enumeration Types (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution: issue withdrawn by submitter
Revised Text:
Actions taken:
May 14, 2008: received issue
May 14, 2008: closed issue

Issue 12458: Section: A/2.3 Enumeration Types -- editorial (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text: In Section A.2.4.1 Operations, Replace "An object may be connected to other objects via association links. A navigation expression allows to follow these links and to retrieve connected objects." By " An object may be connected to other objects via association links. A navigation expression allows one to follow these links and to retrieve connected objects."
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

Issue 12459: Section: Definition A.23 (Semantics of Navigation Operations) (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Maybe I misunderstand, but it seems to me that L(as)(ci), as defined, has some problems: 1. "(c1, . . . , c i, . . . , c j , . . . , c n )" is undefined in that one doesn't know what it is, and 2. c is undefined in "sCLASS(c)". It seems to me that what you want is "L(as)(ci) = {cj | i ? j ? (c1, . . . , ci, . . . , cj , . . . , cn ) ? I-sub-ASSOC(as)}" - where the characters following the c's are subscripts and each such combination should be underlined to show that it is an object, - and where I-sub-ASSOC(as) is an italic I with a subscripted "ASSOC(as)".

Resolution:
Revised Text: see page 179 of ptc/2009-05-04
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex to Framemaker conversion. Mathematical symbols were often badly converted. The correct text is in the original from annex A of ptc/03-10-14..

Issue 12460: Section: A.2.5.2 Definition A.24 (Type Expressions) (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text: see page 180 of ptc/2009-05-04
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex to Framemaker conversion. Mathematical symbols were often badly converted. The correct text is in the original from annex A of ptc/03-10-14.

Issue 12461: Section: A.2.5.5 Collection Operations (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text: see pages 181-182 of ptc/2009-05-04
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex to Framemaker conversion. Mathematical symbols were often badly converted. The correct text is in the original from annex A of ptc/03-10-14.

Issue 12464: Section: A/2.5.5 Collection Operations - just before table A.3 (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

Disposition:	See Issue 12463 for disposition

Issue 12468: Section: A/2.5.5 Collection Operations - Table A.3 (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Table A.3 has several problems in the "Semantics" column: Row 2: Besides being hard to read, the expression seems to be wrong. There is no operator between the C and capital pi (which I assume to be a Cartesian product), and the "is not an element of" seems like it couldn't be right. Maybe I'm at fault, but I can't make any sense of it. Row 4: There's no entry here. How about " C 'intersect' {v} = Ø" Row 6: The operator should be intersection, not Cartesian product, that is the capital pi should is the wrong symbol here. Rows 8 & 9: First, there shouldn't be anything in row 9's semantics column since the other columns are all blank. Are the c's supposed to be the capital C's? I can't make any sense of the expression, which could be my problem, but I don't think so.

Resolution:
Revised Text:
Actions taken:
May 14, 2008: received issue

Issue 12469: A.2.5.5 Collection Operations (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution: Disposition: See Issue 12463 for disposition
Revised Text:
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Issue 12470: There are two instances of missing and misplaced parentheses (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution: Disposition: See Issue 12463 for disposition
Revised Text:
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Issue 12471: Section: A.2.5.6 Set Operations (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text: Replace: Operations on sets include the operations listed in Table A.3. These are inherited from Collection(t). Operations which are specific to sets are shown in Table A.4 where S, S1, S2 are values of type Set(t), B is a value of type t. By: Operations on sets include the operations listed in Table A.3. These are inherited from Collection(t). Operations which are specific to sets are shown in Table A.4 where S, S1, S2 are values of type Set(t), B is a value of type Bag(t) and v is a value of type t.
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

The original text of Annex A (ptc/03-10-14) was left unchanged by the FTF. However some editorial copy/paste errors were introduced when moving from latex to framemaker. In the case of this issue this concerns the description text (not only the math symbols).

Issue 12472: Section: A.2.5.6 Set Operations Table A.4 (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text: see page 187 of ptc/2009-05-04
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Issue 12473: Section: A.2.5.8 Sequence Operations (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text: In Table A.6, in the semantics column for the operation first, replace the index so that it is 1 instead of i.
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Issue 12474: Section: A.3.1.1 Syntax of Expressions (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text: see pages 189 - 191 of ptc/2009-05-04
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex  to Framemaker conversion. The correct text is in the original annex ptc/03-10-14. .

Issue 12475: Section: A.3.1.1 Syntax of Expressions (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution: Disposition: See issue 12474 for disposition
Revised Text:
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Issue 12476: Section: A.3.1.1 Syntax of Expressions (Definition A.29) (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex to Framemaker conversion. Mathematical symbols were often badly converted. The correct text is in the original from annex A of ptc/03-10-14. .


Disposition:	See issue 12474 for disposition

Issue 12477: Syntax of Expressions (second sentence after Definition A..29) (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex to Framemaker conversion. Mathematical symbols were often badly converted. The correct text is in the original from annex A of ptc/03-10-14. .


Disposition:	See issue 12474 for disposition

Issue 12478: Section: A.2.6 Special Types (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text: see pages195-196 of ptc/2009-05-04
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex to Framemaker conversion. Mathematical symbols were often badly converted. The correct text is in the original from annex A of ptc/03-10-14. .

Issue 12479: Section: A.2.6.1 Definition A.26 (Special Types) (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex to Framemaker conversion. Mathematical symbols were often badly converted. The correct text is in the original from annex A of ptc/03-10-14. .

Disposition:	See Issue 2478 for disposition

Issue 12484: Section 8.2.1 Type Conformance on page 37 (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:

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

Resolution:
Revised Text: Update Section 8.2.1 Type Conformance as follows: InvalidType [1] OclInvalid conforms to all other types except OclVoid. context InvalidType inv: Classifier.allInstances()->forAll (c | not c.oclIsTypeOf(OclVoid) implies self.conformsTo (c)) VoidType [1] OclVoid conforms to all other types except OclInvalid. context VoidType inv: Classifier.allInstances()->forAll (c | not c.oclIsTypeOf(OclInvalid) implies self.conformsTo (c))
Actions taken:
May 15, 2008: received issue
October 16, 2009: closed issue

Discussion:

As in the proposed resolutions of Issues 10433 and 10434, OclVoid and OclInvalid cannot both be the bottom of a lattice-structured type system.  It is better that OclVoid and OclInvalid be defined as conforming to all other types excepting one another.

Issue 12485: Section 8.2 page 35 InvalidType (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

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

Resolution: Disposition: See issue 12378 for disposition
Revised Text:
Actions taken:
May 15, 2008: received issue
October 16, 2009: closed issue

Discussion:

Disposition:	See issue 12378  for disposition

Issue 12486: Section: A.2.7 Type Hierarchy (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution: Replace the text of Section A.2.7 Type Hierarchy by the following text:
Revised Text: see pages 198 - 199 of ptc/2009-05-04
Actions taken:
May 15, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex to Framemaker conversion. Mathematical symbols were often badly converted. The correct text is in the original from annex A of ptc/03-10-14. .

Issue 12487: Section: A.3.1.1 Syntax of Expressions (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
May 15, 2008: received issue
October 16, 2009: closed issue

Discussion:

Disposition:	See issue 12474 for disposition

Issue 12488: Section: A.3.1.2 Semantics of Expressions (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text: see pages 201 - 204 of ptc/2009-05-04
Actions taken:
May 15, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex to Framemaker conversion. Mathematical symbols were often badly converted. The correct text is in the original from annex A of ptc/03-10-14. .

Issue 12489: Section: A.3.1.2 Semantics of Expressions, Definition A.30 part ii (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Definition A.30, part ii says "I[[let v = e1 in e2]](r) = I[[e2]](s, ß{v / I[[e1]](r)})." Maybe the problem is my ignorance of the meaning of the / in that expression as well as the meaning of the notation "ß{...}". I would have expected instead something like, "... = I[[e2]](s, ß U {v = I[[e1]](r)})."

Resolution: Disposition: See issue 12488 for disposition
Revised Text:
Actions taken:
May 15, 2008: received issue
October 16, 2009: closed issue

Issue 12490: Section: A.2.5.8 Sequence Operations (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution: The "fg" (in both occurrences) must be replaced by "{}" (a pair of curly braces).
Revised Text: In Section A.2.5.9 Flattening of Collections, after Table A-7 replace occurrences of "fg" by "{}" (a pair of curly braces).
Actions taken:
May 15, 2008: received issue
October 16, 2009: closed issue

Issue 12491: Section: A.3.1.2 Semantics of Expressions (ocl2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

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

Resolution: The notation "\" is the standard notation for substitution (e.g., see Winskel's book on formal semantics). Thus, there seems to be no need to add an explanation in the standard. Disposition: Closed, no change
Revised Text:
Actions taken:
May 15, 2008: received issue
October 16, 2009: closed issue

Issue 12493: Section: A.3.2.2 Syntax and Semantics of Postconditions (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text: see pages 208 - 210 of ptc/2009-05-04
Actions taken:
May 15, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex to Framemaker conversion. Mathematical symbols were often badly converted. The correct text is in the original from annex A of ptc/03-10-14. The parenthesis problem reported here is just one of the problems that are in this section.

Issue 12494: Section: A.3.2.2 Syntax and Semantics of Postconditions (02) (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

In the paragraph before Definition A.32 you will find, "... ppre = (spre, ßpre) describing a system state and variable assignments before the execution ...." Originally I had taken the ß's to be sets of assignments. Then I noticed that the text before this point refers to it repeatedly as an "assignment" in the singular. Now, here, and also in the middle of page 205 (which says, "ß' := ß{p1/I[[ e1 ]](r), . . . , pn /I[[ en ]](r)}.") the indication is that beta is multiple of assignments. Consistency would be very desirable.

Resolution:
Revised Text:
Actions taken:
May 15, 2008: received issue

Discussion:

Deferred for timing reasons.
Disposition:	Deferred

Issue 12495: Section: A.3.2.2 Syntax and Semantics of Postconditions (03) (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

At the beginning of Definition A.32 you will find the sentence, "The semantics of an expression e ? Post-Exprt is a function I[[ e ]] : Env x Env ? I(t)." It doesn't seem that this can be right since the argument to I[[.]] is an element of Post-Expt-sub-t. So, similarly to Definition A.30, I would suggest that something akin to "I[[ e ]] : Post-Exprt ? (Env x Env ? I(t))" would be more appropriate.

Resolution:
Revised Text:
Actions taken:
May 15, 2008: received issue

Discussion:

Deferred for timing reasons.

Disposition:	Deferred

Issue 12496: Section: A.3.2.2 Syntax and Semantics of Postconditions (04) (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

In the paragraph before Definition A.33 we have, "We say that a precondition P satisfies a pre-environment rpre – written as rpre |= P –....". In the explanation of Definition A.33 we have, "...the pre-environment rpre satisfies the precondition P....". One of these must be backwards. Does the environment satisfy the condition (2nd above) or does the condition satisfy the environment (1st above)?

Resolution:
Revised Text:
Actions taken:
May 15, 2008: received issue

Discussion:

Deferred for timing reasons.

Disposition:	Deferred

Issue 12562: CMOF serializations of its metamodels not published (ocl2-rtf)

Click here for this issue's archive.
Source: Zeligsoft, Inc. (Mr. Christian W. Damus, nobody)
Nature: Clarification
Severity: Significant
Summary:

No CMOF models of OCL Abstract Syntax Unlike most successful specifications in the MOF and UML family, the OCL specification does not publish CMOF serializations of its metamodels. Publication of normative metamodels will greatly improve the clarity of the specification and assist tools in implementing it. XMI serializations of the following metamodels are recommended: - CompleteOCL Abstract Syntax (UML basis) - EssentialOCL Abstract Syntax (EMOF basis) Also, a separate document containing normative EBNF or RelaxNG grammars of: - CompleteOCL Concrete Syntax - EssentialOCL Concrete Syntax

Resolution:
Revised Text:
Actions taken:
July 5, 2008: received issue

Discussion:

Good suggestion. It cannot be treated in this ballot due to timing constraints.

Disposition:	Deferred

Issue 12581: OCL 2.0 8.2 Collection Type name distinguishability (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The name of a Set (or other Collection) is defined to use the element type name.
This is not consistent with the UML requirement for distinguishability of namespace
memebers. (UML Infra 9.14.2 Namespace).


OCL should permit, and perhaps require, that the name of a Collection use
the element type qualified name, so that two sets of distinct element type
are not folded into indistinguishable names.


This is a problem for model to model transformation where the same class name can
easily occur on both input and output meta-model, and where the requirement to reify
collection types can easily result in Set(input::name) and Set(output::name) in
the same namespace.

Resolution:
Revised Text:
Actions taken:
July 19, 2008: received issue

Discussion:

Good remark. Now for the resolution we have the option to explicitly consider that the distinguishability rule does not apply for collections or follow the reporter suggestion, which could have some impact in pre-existing written OCL. I suggest to defer so that we take more time to examine the options.

Disposition:	Deferred

Issue 12582: OCL 2.0 8.2 Collection Type packaging (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

[Pending a resolution of Issue 10946]


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


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


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

Resolution: Resolution of issue 9171 contains an statement saying that collection instances may be in different containers and still represent the same type. Disposition: See issue 9171 for disposition
Revised Text: In the preamble of Section 8.2, after sentence " Conceptually all these types do exist, but such a type should be (lazily) instantiated by a tool, whenever it is needed in an expression. " add the sentence: For convenience an instance representing a collection type or a tuple type may be replicated in different namespaces (such as in a top-level package or within the expression referencing it) , however they represent semantically the same type.
Actions taken:
July 19, 2008: received issue
October 16, 2009: closed issue

Discussion:

A sentence is needed to state that collection types can be replicated in different namespaces and still represent the same type. This is in line with 10946 resolution.

Issue 12795: Special Types violate UML Generalization Semantics (ocl2-rtf)

Click here for this issue's archive.
Source: Zeligsoft, Inc. (Mr. Christian W. Damus, nobody)
Nature: Clarification
Severity: Minor
Summary:

Special Types violate UML Generalization Semantics The definition of OclAny as a general of all classes in the UML model and of OclVoid and OclInvalid as specializations of all classes in the UML model are in violation of the semantics of generalization. Classifiers in the UML may only specialize other classifiers of the same or a conformant metaclass. From the description of Classifier in the UML: [3] A classifier may only specialize classifiers of a valid type. self.parents()->forAll(c | self.maySpecializeType(c)) [8] The query maySpecializeType() determines whether this classifier may have a generalization relationship to classifiers of the specified type. By default a classifier may specialize classifiers of the same or a more general type. It is intended to be redefined by classifiers that have different specialization constraints. Thus, it is not valid for OclAny (an instance of the AnyType metaclass) to be the general of any other class. Likewise, OclVoid and OclInvalid may not specialize any other class at all. This could be corrected in OclVoid and OclInvalid by redefining the maySpecializeType() query. For OclAny, the solution is not so straight-forward, as I don't see that OCL can redefine maySpecializeType() on behalf of the UML metaclasses; according to Section 7.4.4, it is not permitted to attempt to define an additional operation that clashes with an intrinsic operation of the context classifier.

Resolution:
Revised Text:
Actions taken:
August 24, 2008: received issue

Discussion:

The issue requires some further analysis. Deferred for timing reasons.

Disposition:	Deferred

Issue 12854: OCL 2.0 Issue: References to Additional Attributes and Operations (ocl2-rtf)

Click here for this issue's archive.
Source: Zeligsoft, Inc. (Mr. Christian W. Damus, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

Re: OCL 2.0 formal/06-05-01


The Abstract Syntax defines expressions that navigate properties and  
call operations of Classifiers:  the PropertyCallExp and  
OperationCallExp, respectively.  These work well for features of  
Classifiers that are defined by the UML model that is the subject of  
the OCL constraints.


However, OCL also provides a mechanism for defining additional  
attributes and operations on behalf of a classifier:  the definition  
constraint.  As these definitions are extrinsic to the UML model,  
there are no Property and Operation elements for the respective  
expressions to reference.  There are only Constraints with an  
«oclHelper» stereotype and a body expression.  The very purpose of  
these definitions is to assist in the formulation of OCL constraints,  
so it is necessary that the abstract syntax be able to reference them.


I can think of an obvious approach to resolution of this problem:  add  
an association "referredDefinition : Constraint" with 0..1  
multiplicity to both of the existing PropertyCallExp and  
OperationCallExp metaclasses.  The 0..1 multiplicity of the existing  
referredProperty and referredOperation associations, as shown in  
Figure 8.3, appears to be in error (as the rest of the text and, in  
particular, the well-formedness rules of Section 8.3.7, assumes the  
reference to the referred features) but is required by this solution.   
Additional well-formedness rules would stipulate, for each expression,  
that exactly one of the referred feature of referred definition  
associations have a value.


This suggestion is not entirely satisfactory, as it breaks the  
uniformity of references to features in call expressions and encodes,  
in the abstract syntax, a dependency on a feature's being an  
additional definition.  However, this problem is a practical concern  
for the serialization and exchange of the OCL Abstract Syntax, as the  
current metamodel is incomplete.

Resolution:
Revised Text:
Actions taken:
September 14, 2008: received issue

Discussion:

The solution suggested by the reporter as recognized by him is not satisfactory. A more clean "conceptual" solution would be to allow OCL define modules (package) that extend the metamodels (as it works in QVT).
Some further examination is needed of this issue to find the most appropriate solution. 

Disposition:	Deferred

Issue 12943: OCL 2.0: CollectionType constraint for invalid elements is incorrect (ocl2-rtf)

Click here for this issue's archive.
Source: Zeligsoft, Inc. (Mr. Christian W. Damus, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

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


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


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


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

Resolution: As OCL does not permit the invalid value in a collection (as opposed to the null value), it should be made explicit that the evaluation of collection literals containing invalid results in invalid. The CollectionType constraint in Section 8.2.2 attempts to express this, but is incorrect because it is defined on the wrong meta-level (on CollectionType instead of Collection).
Revised Text: Strike the second constraint on CollectionType in Section 8.2.2 “Well-formedness Rules for the Types Package” [1] A collection cannot contain OclInvalid values. context CollectionType inv: self->forAll(not oclIsInvalid()) Add an invariant constraint to Section 11.7.1 “Collection” [1] A collection cannot contain OclInvalid values. context Collection inv: self->forAll(not oclIsInvalid())
Actions taken:
October 9, 2008: received issue
October 16, 2009: closed issue

Discussion:

Issue 12944: Type of a type expression (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Disposition: See issue 9171 for disposition
Revised Text:
Actions taken:
October 10, 2008: received issue
October 16, 2009: closed issue

Issue 12945: Missing definition of of iterators for OrderedSets (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: The missing operations are added. Notice that the list of operations is the union of those supported by sequences and those supported by sets.
Revised Text: The missing operations are added. Notice that the list of operations is the union of those supported by sequences and those supported by sets. Revised Text: Add a new section "11.9.5 OrderedSet" with the following content: The standard iterator expressions with source of type OrderedSet(T) are: select (expression : OclExpression) : OrderedSet(T) The ordered set of the source ordered set for which body is true. source->select(iterator | body) = source->iterate(iterator; result : OrderedSet(T) = OrderedSet{} | if body then result->including(iterator) else result endif) select may have at most one iterator variable. reject (expression : OclExpression) : OrderedSet(T) The ordered set of the source ordered set for which body is false. source->reject(iterator | body) = source->select(iterator | not body) reject may have at most one iterator variable. collectNested (expression : OclExpression) : Sequence(T) The sequence of elements that results from applying body to every member of the source ordered set. source->collectNested(iterators | body) = source->iterate(iterators; result : Sequence(body.type) = Sequence{} | result->append(body ) ) collectNested may have at most one iterator variable. sortedBy (expression : OclExpression) : OrderedSet(T) Results in the ordered set containing all elements of the source collection. The element for which body has the lowest value comes first, and so on. The type of the body expression must have the < operation defined. The < operation must return a Boolean value and must be transitive (i.e., if a < b and b < c then a < c). source->sortedBy(iterator | body) = iterate( iterator ; result : OrderedSet(T) : OrderedSet {} | if result->isEmpty() then result.append(iterator) else let position : Integer = result->indexOf ( result->select (item | body (item) > body (iterator)) ->first() ) in result.insertAt(position, iterator) endif sortedBy may have at most one iterator variable
Actions taken:
October 10, 2008: received issue
October 16, 2009: closed issue

Discussion:

Issue 12946: The operation asSet, asSequence, asBag and asOrderedSet missing for OrderedSets (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Disposition: See issue 4451 for disposition
Revised Text:
Actions taken:
October 10, 2008: received issue
October 16, 2009: closed issue

Issue 12947: Clarify the common supertype of Bag and Sequence (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Adding clarification sentences
Revised Text: In Section 11.6.3, add the sentence: An OrderedSet is not a subtype of Set, neither a subtype of Sequence. The common supertype of Sets and OrderedSets is Collection. In Section 11.6.5 add the sentence. A Sentence is not a subtype of Bag. The common supertype of Sentence and Bags is Collection.
Actions taken:
October 10, 2008: received issue
October 16, 2009: closed issue

Issue 12948: Making OclAny denote any object (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: OclAny denotes now any object including collections. This makes the type system aligned with MOF.
Revised Text: (1) In Section 8.2, AnyType, replace the actual AnyType definition: AnyType is a special type that complies to all the types except the collection types. AnyType has a unique instance named OclAny. It is defined to allow defining generic operations that can be invoked in any object or primitive literal value. By the following: AnyType is the metaclass of the special type OclAny, which is the type to which all other types conform. OclAny is the sole instance of AnyType. This metaclass allows defining the special property of being the generalization of all other Classifiers, including Classes, DataTypes and PrimitiveTypes. (2) In Section "8.2.1 Type Conformance", remove the second rule for Classifiers (All classifiers except collections conform to OclAny) (3) In Section "11.2.1 OclAny", replace the sentences "All types in the UML model and the primitive types in the OCL standard library complies with the type OclAny. Conceptually, OclAny behaves as a supertype for all the types except for the OCL pre-defined collection types." By "All types in the UML model and the primitive and collection types in the OCL standard library conforms to the type OclAny. Conceptually, OclAny behaves as a supertype for all the types."
Actions taken:
October 10, 2008: received issue
October 16, 2009: closed issue

Issue 12949: Incosistency between UnlimitedInteger and UnlimitedNatural (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: In Section 11.4.5, replace all occurrences of UnlimitedInteger by UnilimitedNatural. Also replace UnlimitedIntegerType. By UnlimitedINaturalType.
Actions taken:
October 10, 2008: received issue
October 16, 2009: closed issue

Discussion:

The correct name is UnlimitedNatural. This error only occurs in Section 11.4.5.

Issue 12950: No way to represent type parameters in the standard library (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Clarification
Severity:
Summary:

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

Resolution: Adding a TemplateParameterType. This promotes the solution to this problem as found in QVT.
Revised Text: (1) In Section 8.2, just before 8.2.1, add the definition: TemplateParameterType A TemplateParameterType is used to refer to generic types in parameterized definitions. It is used in the standard library to represent the parameterized collection operations. A template parameter type is usually named "T" (or "T2", "T3" and so on, when more than one type parameter is involved). The TemplateParameterType is a sub-class of Classifier. Attributes: specification : String An un-interpreted opaque definition of the template parameter type. Note: The definition should be placed in line with alphabetical order. (2) Update Figure 8.1 with the inclusion of the TemplateParameterType class. (3) In Section 13.3 Diagrams (Essential OCL), update the diagram (In this case, TemplateParameterType is a sub-class of Type).
Actions taken:
October 10, 2008: received issue
October 16, 2009: closed issue

Issue 12951: Use of MOF reflection in EssentialOCL should be clarified (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: The BasicOCL/EssentialOcl cannot merge EMOF reflection since we have conflict in metaclasses. The role of Object is played by AnyType. At M1 level, OCL has its own reflection mechanism. A clarification sentence is added.
Revised Text: In Section 13.2, after (4) numbered paragraph, add a new numbered paragraph with the following sentence: The EMOF Reflection capability is not merged to the metamodel. AnyType plays the role of Object. At instance level, reflection is provided by the oclIsKindOf(), oclIsTypeOf(), and oclType() operations
Actions taken:
October 10, 2008: received issue
October 16, 2009: closed issue

Issue 12952: Use of simple quotes and double quotes in strings (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
October 10, 2008: received issue

Discussion:

In fact simple quotes are used in OCL for introducing strings, so we guess the request is to allow use of double quotes as an option (like in Javascript). This issue requires some further analysis so I suggest to defer.

Disposition:	Deferred

Issue 12953: Exact type of Set{} and missing Set(MyType){} literal definitions (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
It is not clear what is the concrete type of Set{}. Is it  Set(Object)??, Set(Void)?? 
Also it seems there is no way to explicitly define an empty collection with a given 
type for the elements.

Resolution: Discussion of this issue suggested a number of options: Option 1: The type of Set{} is Set(OclVoid) This does not work because Set{}->including(1) is an error since "1" or indeed anything other than null or invalid does not conform to OclVoid. Option 2: The type of Set{} is Set(OclAny) This does not work because acc : Set(Integer) = Set{}->including(1) is an error since Set(OclAny) is not compatible with Set(Integer). Option 3: The type of Set{} is a new built-in type EmptySet(ET) where ET is determined in some way. This does not work because given the RHS of acc : Set(Integer) = Set{}->including(1.0)- >including(Classifier)->excluding(1.0)->excluding(Classifier) it is difficult to see how ET could be determined more precisely than OclAny causing the same problem as Option 2. Option 4: The type of Set{} is Set(null) Since Set{} and Set(null) have no precise OCL 2.1 semantics there is some discretion in defining them, but eventually a dynamic type validation is needed for acc : Set(String) = Set(null){getInitialValue()}. The impact on evaluation could be mitigated by synthesis of an oclAsType() in the Abstract Syntax Tree, but it is not 18 possible to provide a static type for the CollectionLiteralExp. This option could work but requires revision of abstract syntax and evaluation specifications. Option 5: The type of Set{} is back-propagated For instance in acc : Set(Real) = Set{}->including(1)->including(-1) the type of Set{} is Set(Real) since that is the eventual result type. This involves unusual reverse semantics. Option 6: The type of Set{} is Set(T) with T chosen for well-formedness of the expression in which the Set{} is used. For instance in acc : Set(Real) = Set{}->including(1)->including(-1) the type of Set{} is initially Set(T) where T <= OclVoid. Propagation of the type to Set(T)::including(UnlimitedNatural) requires T <= UnlimitedNatural. Propagation to Set(T)::including(Integer) requires T <= Integer. Finally, propagation to the initializer requires Real <= T. Therefore any Real <= T <= Integer is well-formed. The lower bound, Set(Real), is preferred since it avoids many type conversions. It is also the same result as Option 5. Option 6 involves only additional forward static semantics, has no impact on evaluation, no impact on parsing, and gives the intuitively correct OCL 2.1 results. ----- In order to impose a user-specified element type and so get static type checking of user intent, a collection element type can be specified as: acc : Set(Integer) = Set(Integer){} It is difficult to parse this in OCL 2.1 because Set is not a reserved word and so lookahead is required to determine whether Set(someName) is the start of a StringLiteralExpCS or an OperationCallExpCS, with someName perhaps being a complicated nested type/value ambiguity. Issue 14357 introduces the concept of a restricted word preventing the unqualified use of Set as an operation name. The extension is then straightforward.
Revised Text: In 7.5.11 after A bag: Bag {1, 3, 4, 3, 5 } add The element type may be specified in parentheses. This ensures that the types of elements can be statically checked. Bag(Real) {1, 3, 4, 3, 5 } In 8.3.7 CollectionLiteralExp replace Note that the definition below implicitly states that empty collections have OclVoid as their elementType. by Note that the definition below defines only an upper bound on the elementType. The usage of the CollectionLiteralExp defines a lower bound. If the elementType is not explicitly specified, the elementType must be chosen to ensure the well-formedness of the elements of the CollectionLiteralExp and the usage of the CollectionLiteralExp. For instance in acc : Set(Real) = Set{1}->excluding(-1) Set{1} is well formed for any type Set(T) where T ? UnlimitedNatural. Well-formedness of the excluding operation call requires T ? Integer, and well-formedness of the initializer requires Real ? T. The overall expression is therefore only well-formed if Real ? T ? Integer. Either Set(Real) or Set(Integer) are wellformed. The most general type, Set(Real), is recommended since it minimizes type conversions and can often be easily deduced by considering the result type. In 8.3.7 CollectionLiteralExp replace inv: type.oclAsType (CollectionType).elementType = part->iterate (p; c : Classifier = OclVoid | c.commonSuperType (p.type)) by inv: let elementType : Type = part->iterate (p; c : Classifier = OclVoid | c.commonSuperType (p.type)) in elementType.conformsTo(type.oclAsType (CollectionType).elementType) In 9.3 CollectionLiteralExpCS replace CollectionLiteralExpCS ::= CollectionTypeIdentifierCS ‘{‘ CollectionLiteralPartsCS? ‘}’ Abstract syntax mapping CollectionLiteralExpCS.ast : CollectionLiteralExp Synthesized attributes CollectionLiteralExpCS.ast.parts = CollectionLiteralPartsCS.ast CollectionLiteralExpCS.ast.kind = CollectionTypeIdentifierCS.ast Inherited attributes CollectionTypeIdentifierCS.env = CollectionLiteralExpCS.env CollectionLiteralPartsCS.env = CollectionLiteralExpCS.env Disambiguating rules [1] In a literal the collection type may not be Collection. CollectionTypeIdentifierCS.ast <> ‘Collection’ by [A] CollectionLiteralExpCS ::= CollectionTypeIdentifierCS ‘{‘ CollectionLiteralPartsCS? ‘}’ [B] CollectionLiteralExpCS ::= collectionTypeCS ‘{‘ CollectionLiteralPartsCS? ‘}’ Abstract syntax mapping CollectionLiteralExpCS.ast : CollectionLiteralExp Synthesized attributes [A] CollectionLiteralExpCS.ast.parts = CollectionLiteralPartsCS.ast [A] CollectionLiteralExpCS.ast.kind = CollectionTypeIdentifierCS.ast [B] CollectionLiteralExpCS.ast.parts = CollectionLiteralPartsCS.ast [B] CollectionLiteralExpCS.ast.kind = collectionTypeCS.ast.kind [B] CollectionLiteralExpCS.ast.type = collectionTypeCS.ast Inherited attributes [A] CollectionLiteralPartsCS.env = CollectionLiteralExpCS.env [A] CollectionTypeIdentifierCS.env = CollectionLiteralExpCS.env [B] CollectionLiteralPartsCS.env = CollectionLiteralExpCS.env [B] collectionTypeCS.env = CollectionLiteralExpCS.env Disambiguating rules [A] [1] In a literal the collection type may not be Collection. CollectionTypeIdentifierCS.ast <> ‘Collection’ [B] [1] In a literal the collection type may not be Collection. collectionTypeCS.ast <> CollectionType
Actions taken:
October 10, 2008: received issue
April 25, 2011: closed issue

Discussion:

Resolution of this issue requires some extra analysis

Disposition:	Deferred

Issue 13057: Section: 7.5.15 (ocl2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

Although it is clear that using a constructor to write an object to the system being modelled breaks the property of being side-effect free, it would be useful to return new objects as a result of the query functionality of OCL. It is possible to create a new Tuple for return from a function. For example: def: newDate1() : TupleType {day:Integer, month:Integer, year:Integer} = Tuple{day=10, month=12, year=1950}; It would be useful to have a similar way to generate a query result, but with a complex data type instead of a Tuple. For example: def: newDate2() : Date = Date{day=10, month=12, year=1950}; Rather than write this object to the model under query, it would only be returned as a query result so, under these circumstances, would not break the property of being side-effect free. This feature would be extremely useful to the HL7 GELLO project, which works with data models defined in absense of defined methods or constructors. If this feature were to only apply to classes marked in some way to guarantee they have no side-effects from construction then that would remain useful.

Resolution:
Revised Text:
Actions taken:
November 5, 2008: received issue

Discussion:

Resolution of this issue requires some extra analysis.
Disposition:	Deferred

Issue 13076: The concrete syntax given is extremely difficult to implement (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

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

Resolution: Disposition: See issue 10439 for disposition
Revised Text:
Actions taken:
November 10, 2008: received issue
April 25, 2011: closed issue

Discussion:

Good suggestion. A lot of people has expressed the need for having an alternate BNF based way of providing the syntax. This could be done but requires some analysis to ensure it will be compatible with the way it is actually provided. 

Disposition:	Deferred

Issue 13077: The following collection operations would be useful for the HL7 GELLO project: (ocl2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

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

 

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

 

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

 

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

 

reverse: Returns a sequence in reverse order

 

join(namesOfCollections; namesOfProperties; booleanExpression; orderByExpression)

 

Where:

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

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

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

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

  collections we want to get in the result.  

- booleanExpression is a valid boolean expression containing the 

  conditions the elements from the collections defined in listOfCollections 

  must satisfy in order to be included in the result

- booleanExpression is a valid boolean expression containing the 

  conditions the elements from the collections defined in listOfCollections 

  must satisfy in order to be included in the result

 

average: Calculate the average value in a collection

 

stdev: Calculate the standard deviation of a collection

 

variance: Calculate the variance of a collection

 

median: Calculate the median of a collection

 

mode: Calculate the mode of a collection

Resolution:
Revised Text: (1) At the end of section 11.1 Introduction add the following sentence: The Standard Library may be extended with new types, new operations and new iterators. In particular new operations can be defined for collections. (2) In section 11.7.1 Collection, after "sum" operation definition add the following two definitions: max() : T The element with the maximum value of all elements in self. Elements must be of a type supporting the max operation. The max operation - supported by the elements - must take one parameter of type T and be both associative and commutative. Integer and Real fulfill this condition. post: result = self->iterate( elem; acc : T = self.first() | acc.max(elem) ) min() : T The element with the minimum value of all elements in self. Elements must be of a type supporting the min operation. The min operation - supported by the elements - must take one parameter of type T and be both associative and commutative. Integer and Real fulfill this condition. post: result = self->iterate( elem; acc : T = self.first() | acc.min(elem) ) (3) In section 11.7.3 OrderedSet, append the following operation definition: reverse () : OrderedSet(T) The set of elements with same elements but with the opposite order. post: result->size() = self->size() (4) In section 11.7.5 Sequence, append the following operation definition: reverse () : Sequence(T) The sequence containing the same elements but with the opposite order. post: result->size() = self->size()
Actions taken:
November 10, 2008: received issue
October 16, 2009: closed issue

Discussion:

In the OCL specification we found some statements that indicate that the standard library can be extended (example 11.8.1), not only with new operations but also with iterator expressions. However the mechanism for representing the standard library itself (as a M1 instance of the OCL metamodel) is unclear (a Package containing types which in turn contain operations?) and the extension mechanism for the standard library is also undefined (a pure replacement of the Package, or a new Package importing the StdLib package?).
Some other issues address specifically this problem, so the resolution of this issue will be formulated in a neutral way is respect to this representation issue: we confirm that new collection operations can be defined (adding a sentence) and we treat specifically the case of some generic operations that can be easily introduced: "reverse" as operation of "Sequence" and "OrderedSet", max, min as operations of Collection but with constraints on the type of parameters. 
We consider that average, stdev, variance, median and mode are too specific and can be defined as extensions. The proposed join functionality can be re-formulated as an iterator extending the standard library.

Issue 13225: Redundant CollectionLiteralExp::kind complicates collection type extension (ocl2-rtf)

Click here for this issue's archive.
Source: Borland Software Corporation (Mr. Radek Dvorak, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

The CollectionLiteralExp class defines the 'kind' attribute to indicate the specific collection type of the literal (8.3.5 Literal Expressions).
This information is redundant as the collection kind can be deduced from the 'type' association inherited from the TypedElement.
As the attribute type is CollectionKind enumeration, it restricts to the set of predefined OCL collection types.
Other languages that extend OCL, like QVT does, may need to define custom CollectionType subclasses but can't 
reuse CollectionLiteralExp as it's impossible to provide a suitable collection kind value.
 
Proposed resolution:
Remove the CollectionLiteralExp::kind attribute, eventually consider removing the CollectionKind enumeration.

Resolution:
Revised Text:
Actions taken:
January 8, 2009: rewceived issue

Discussion:

The information CollectionLiteralExp::kind is effectively redundant since in theory it can be computed by inspecting the type information. I guess the 'kind' attribute was introduced to facilitate "very lazy" type instantiation (like not building the type associated with the tuple literal). One possible option, instead of removing the attribute, could be to state it is optional.
I suggest deferring the resolution of this issue to give more time to people to discuss on the resolution proposal.

Disposition:	Deferred

Issue 13535: doubts about the iterator variables (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

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

Resolution:
Revised Text: (1) In Section 7.6.4, add the following sentence at the end of the section. "Similarly to forAll expression an exists expression may declare multiple iterators". (2) In Section 11.9.1 Collection, in IsUnique part, replace occurrences of 'iterators' by 'iterator'. The same for Collect part. (3) In Section 11.9.2 Set, in collectNested, replace occurrences of 'iterators' by 'iterator'. (4) In Section 11.9.3 Bag, in collectNested, replace occurrences of 'iterators' by 'iterator'. (5) In Section 11.9.4 Sequence, in collectNested, replace occurrences of 'iterators' by 'iterator'.
Actions taken:
February 20, 2009: received issue
October 16, 2009: closed issue

Discussion:

The assumption of the reporter concerning the number of iterators in the syntax is correct.
The number of iterators is in fact explicily defined in Section 11.9. By the way, for the last question of the reporter, there is no issue at all since according to the abstract syntax the association end iterator is already declared as multivalued (see LoopExp::iterator [*] in Figure 8.2).
We believe anyway that it is useful to add a sentence in Section 7 stating that 'exists' operator can potentially have multiple iterators since there is no example of this.
Also some minor typo fixing is needed in  11.9.

Issue 13536: type of the iterator variable is expected or not? (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

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

Resolution: It is clear from the various examples in Section 7 that the type declaration of the iterator is optional in collection operations. By default VariableDeclarationCS is defined so that the type of the variable declared is optional. Disposition: Close, no change
Revised Text:
Actions taken:
February 20, 2009: received issue
October 16, 2009: closed issue

Discussion:

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

Disposition:	Close, no change

Issue 13537: have tuple fields and let variables to have the declaration of their types explicity? (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

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

Resolution:
Revised Text: In Section 7.4.3, at the end of the section add the sentence: "A variable declaration inside a let must have a declared type and an initial value".
Actions taken:
February 20, 2009: received issue
October 16, 2009: closed issue

Discussion:

By default a VariableDeclarationCS has the type declarator optional unless it is explicitly stated that it should be present. It is mandatory for Let (see disambiguation rules of LetExpCS) but not mandatory for tuples.
To avoid that people ask the question again for let expression, we add a sentence in 7.4.3.

Issue 13915: Role 'collectionTypes' should be 'collectionType' (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text: In Section 8.2.2, (top of page 39), Classifier well-formedness rule, replace: [1]For each classifier at most one of each of the different collection types exist. context Classifier inv: collectionTypes->select(oclIsTypeOf(CollectionType))->size() <= 1 inv: collectionTypes->select(oclIsTypeOf(BagType ))->size() <= 1 inv: collectionTypes->select(oclIsTypeOf(SequenceType ))->size() <= 1 inv: collectionTypes->select(oclIsTypeOf(SetType ))->size() <= 1 by: [1]For each classifier at most one of each of the different collection types exist. context Classifier inv: collectionType->select(oclIsTypeOf(OrderedSetType))->size() <= 1 inv: collectionType->select(oclIsTypeOf(BagType))->size() <= 1 inv: collectionType->select(oclIsTypeOf(SequenceType))->size() <= 1 inv: collectionType->select(oclIsTypeOf(SetType))->size() <= 1
Actions taken:
May 5, 2009: received issue
October 16, 2009: closed issue

Issue 13944: [OCL-2.1 RTF] Transitive closure operator (ocl2-rtf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Object Constraint Language, formal/06-05-01

Section: 7.6 Collection Operations

 

Summary:

 

The concept of transitive closure is very useful for specifying well-formedness constraints on binary relations.

For a binary relation r:A->A and elements x,y,z in A, r(x,y) is true when r relates x to y and r is transitive whenever for any x,y,z in A, r(x,y) and r(y,z) imply r(x,z). The transitive closure of a binary relation r:A->A is the smallest relation, ^r:A->A, that contains r and is transitive. 

 

In the UML specification, the definition of Classifier::allParents() : Classifier[*] as “all the direct and indirect ancestors of a generalized Classifier” could be equivalently paraphrased as the transitive closure of the Classifier::parents() : Classifier[*] relation.

 

Specifying the notion of transitive closure for the OCL specification can be problematic as this notion refers to a meta-property not expressible in first order logic (i.e., the smallest relation satisfying a given property). However, the notion of transitive closure can be specified in the context of a particular API for evaluating OCL iterator expressions such as that of the Eclipse OCL implementation of the OCL2.0 specification:

 

http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.ocl.doc/references/overview/OCLOverview.html

 

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.mdt/org.eclipse.ocl/plugins/org.eclipse.ocl/src/org/eclipse/ocl/internal/evaluation/IterationTemplateClosure.java?root=Modeling_Project&view=markup

 

A synopsis of the algorithm for computing the transitive closure as an OCL iterator expression is available here:

 

http://dev.eclipse.org/newslists/news.eclipse.modeling.mdt.ocl/msg01390.html

Resolution:
Revised Text: Add an additional section before 7.6.5 7.6.5 Closure Operation The iterators described in the preceding sections return results from the elements of a collection. The closure supports returning results from the elements of a collection, the elements of the elements of a collection, the elements of the elements of the elements of a collection, and so forth. This can be useful for iterating over a transitive relationship such as a UML generalization. The closure operation uses the same syntax as the select and reject iterators and is written as one of source->closure( v : Type | expression-with-v ) source->closure( v | expression-with-v ) source->closure( expression ) The returned collection of the closure iteration is an accumulation of the source collection, and the collections resulting from the recursive invocation of expression-with-v in which v is associated exactly once with each distinct element of the returned collection. The iteration terminates when expression-with-v returns empty collections or collections containing only already accumulated elements. The collection type of the result collection is the unique form (Set or OrderedSet) of the original source collection. If the source collection is ordered, the result is in depth first preorder. The result satisfies the postcondition: post: let sourceAndResult : Set(Type) = source->asSet()->union(result) in sourceAndResult = sourceAndResult->collect(expression) For a simple parent-children relationship and known parents parents->closure(children) computes the set of parents.children, parents.children.children, parents.children.children.children etc. In the opposite direction self->asOrderedSet()->closure(mother) computes the maternal line. For a more complex relationship such as UML Classifier generalization aClassifier.generalization()->closure(general.generalization).general()->including(aClassifier) computes the set comprising aClassifier and all its generalizations. The closure recurses over the Generalizations to compute the transitive set of all Generalizations. The generalized classifier is collected from each of these before including the originating aClassifier in the result. As with all other iterators, self remains unchanged throughout the recursion, and an implicit source attempts to resolve features against iterators. At the end of 7.8 Resolving Properties add A closure iteration may introduce an implicit iterator-variable at each level of recursion and so multiple iterator-variable candidates for consideration as the implicit self. Since all candidates have the same static type, it is only the least deeply nested candidate, with respect to the iteration body, that need be considered as the implicit iterator-variable for a closure. In 8.3.7 IteratorExp add IteratorExp closure [1] There is exactly one iterator. context IteratorExp inv: name = 'closure' implies iterator->size() = 1 [2] The collection type for an OrderedSet or a Sequence source type is OrderedSet. For any other source the collection type is Set. context IteratorExp inv: name = 'closure' implies if source.type.oclIsKindOf(SequenceType) or source.type.oclIsKindOf(OrderedSetType) then type.oclIsKindOf(OrderedSetType) else type.oclIsKindOf(SetType) endif [3] The source element type is the same as type of the body elements or element. context IteratorExp inv: name = 'closure' implies source.type.oclAsType(CollectionType).elementType = if body.type.oclIsKindOf(CollectionType) then body.type.oclAsType(CollectionType).elementType else body.type endif [4] The element type is the same as the source element type. context IteratorExp inv: name = 'closure' implies type.oclAsType(CollectionType).elementType = source.type.oclAsType(CollectionType).elementType In 11.9.1 add closure The closure of applying body transitively to every distinct element of the source collection. source->closure(iterator | body) = anonRecurse(source, Result{}) where: anonRecurse is an invocation-site-specific helper function synthesized by lexical substitution of iterator, body, add and Result in: context OclAny def: anonRecurse(anonSources : Collection(T), anonInit : Result(T)) : Result(T) = anonSources->iterate(iterator : T; anonAcc : Result(T) = anonInit | if anonAcc->includes(iterator) then anonAcc else let anonBody : OclAny = body in let anonResults : Result(T) = anonAcc->add(iterator) in if anonBody.oclIsKindOf(CollectionType) then anonRecurse(anonBody.oclAsType(Collection(T)), anonResults) else anonRecurse(anonBody.oclAsType(T)->asSet(), anonResults) endif endif) where: T is the element type of the source collection. Result is 'OrderedSet' if the source collection is ordered, 'Set' otherwise. add is 'append' if the source collection is ordered, 'including' otherwise. The anonymous variables 'anonRecurse', 'anonAcc', 'anonInit', 'anonResults' and 'anonSources' are named for exposition purposes; they do not form part of the evaluation environment for body.
Actions taken:
May 31, 2009: received issue
April 25, 2011: closed issue

Discussion:

The omission of a closure iterator has been noted by many OCL users. The suggestion is
practical, but since it is a transitive closure the use of the name closure as in the
referenced implementation could be misleading. Conversely the use of a clearer name
such as transitiveClosure() is a bit verbose. Since closure() has already started to be used
and its usage is clearly associated with a context object rather than a global scope,
insisting on the longer name seems unnecessarily pedantic.
A closure iterator is specified below generalising the referenced Eclipse MDT/OCL
implementation to operate on an OrderedSet as well as a Set.
[Design note. An attempt to extract a more generic recurse() building block proved
fruitless. A more general recurse might for instance support transitiveExists,
transitiveForAll etc. It was not clear that, for instance a Bag of multiple encounters was
of any practical use, and the Bag could anyway be generated by an iteration over the
transitiveClosure. Similarly an elaboration to allow a user function of the encounters
requires two bodies and multiple iterate results. Once again it is easier to provide the
simple transitiveClosure and then invoke the user function on the result. Any enhanced
efficiency from the combined operation could still be obtained by an OCL 'compiler' that
optimises a transitiveClosure(...)->forAll(...).]

Issue 14094: Erroneous operation names 'isOclType' and 'asOclType' (ocl2-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. E. Victor Sanchez, vsanchez(at)opencanarias.com)
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text: In Section 10 replace all references to asOclType by oclAsType In Section 10 replace all references to isOclType by oclIsTypeOf
Actions taken:
July 25, 2009: received issue
April 25, 2011: closed issue

Discussion:

These typos all occur in Section 10.

Issue 14196: Missing specification of UnlimitedNatural (ocl2-rtf)

Click here for this issue's archive. Click here for this issue's attachments.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature:
Severity:
Summary:

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

Resolution: see pages 24 - 35 of OMG document ptc/2010-12-01
Revised Text:
Actions taken:
August 22, 2009: received issue
April 25, 2011: closed issue

Discussion:

[The use of e comes from Issue 14197; a much more comprehensive response to Issue 12349 of
the missing distinction between ? as invalid and e as null.]

Issue 14197: OCL 2.0, 2.1 inconsistent definition of null and invalid (ocl2-rtf)

Click here for this issue's archive. Click here for this issue's attachments.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

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


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

Resolution:
Revised Text: In 7.4.10 replace Undefined Values Some expressions will, when evaluated, have an undefined value. For instance, typecasting with oclAsType() to a type that the object does not support or getting the ->first() element of an empty collection will result in undefined. In general, an expression where one of the parts is undefined will itself be undefined. by 7.4.11 Invalid Values Some expressions will, when evaluated, have an invalid value. For instance, typecasting with oclAsType() to a type that the object does not support or getting the ->first() element of an empty collection will result in invalid. In general, an expression where one of the parts is null or invalid will itself be invalid. In 7.4.10 replace Finally, there is an explicit operation for testing if the value of an expression is undefined. oclIsUndefined() is an operation on OclAny that results in True if its argument is undefined and False otherwise. by Finally, there is an explicit operation for testing if the value of an expression is undefined. oclIsUndefined() is an operation on OclAny that results in True if its argument is null or invalid and False otherwise. In 7.7.2 last sentence replace If message.hasReturned() is false, then message.result() will be undefined. by If message.hasReturned() is false, then message.result() will be invalid. In 8.2 VoidType replace VoidType represents a type that conforms to all types. by VoidType is the metaclass of the OclVoid type that conforms to all types except the OclInvalid type. In 8.2 VoidType replace Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections. by Note that in contrast with invalid, null is a valid value and as such can be owned by collections. In 8.2.1 InvalidType replace [1] Invalid conforms to all other types except OclVoid. context InvalidType inv: Classifier.allInstances()->forAll (c | not c.oclIsTypeOf(OclVoid) implies self.conformsTo (c)) by [1] OclInvalid conforms to all other types. context InvalidType inv: Classifier.allInstances()->forAll (c | self.conformsTo (c)) In 8.2.1 VoidType replace [1] Void conforms to all other types except OclInvalid. by [1] OclVoid conforms to all other types except OclInvalid. In 9.3 VariableDeclarationCS replace -- The value OclUndefined is used when no type has been given in the concrete syntax. -- Production rules that use this need to check on this type. VariableDeclarationCS.ast.type = if typeCS->notEmpty() then typeCS.ast else OclUndefined endif by -- The value null is used when no type has been given in the concrete syntax. -- Production rules that use this need to check on this type. VariableDeclarationCS.ast.type = if typeCS->notEmpty() then typeCS.ast else null endif In 9.3 OclMessageExpCS replace in OclMessageExpCS.ast.calledOperation = if operation->isEmpty() then OclUndefined else = operation endif OclMessageExpCS.ast.sentSignal = if signal->isEmpty() then OclUndefined else signal endif by in OclMessageExpCS.ast.calledOperation = if operation->isEmpty() then invalid else = operation endif OclMessageExpCS.ast.sentSignal = if signal->isEmpty() then invalid else signal endif In 9.4.3 final clause replace post: if self.namespace->notEmpty() -- this namespace has an owning namespace then result.parent = self.namespace.getEnvironmentWithParents() else result.parent = OclUndefined endif by post: if self.namespace->notEmpty() -- this namespace has an owning namespace then result.parent = self.namespace.getEnvironmentWithParents() else result.parent = invalid endif In 11.2.3 OclVoid replace The type OclVoid is a type that conforms to all other types except OclInvalid. It has one single instance, identified as null, that corresponds with the UML LiteralNull value specification. Any property call applied on null results in OclInvalid, except for the operation oclIsUndefined(). Any property call applied on null results in OclInvalid, except for the operation oclIsUndefined() and oclIsInvalid(). by The type OclVoid is a type that conforms to all other types except OclInvalid. It has one single instance, identified as null, that corresponds with the UML LiteralNull value specification. Any property call applied on null results in invalid, except for the oclIsUndefined(), oclIsInvalid(), =(OclAny) and <>(OclAny) operations. In 11.2.4 OclInvalid replace The type OclInvalid is a type that conforms to all other types except OclVoid. It has one single instance, identified as invalid. Any property call applied on invalid results in OclInvalid, except for the operations oclIsUndefined() and oclIsInvalid(). by The type OclInvalid is a type that conforms to all other types. It has one single instance, identified as invalid. Any property call applied on invalid results in invalid, except for the oclIsUndefined() and oclIsInvalid() operations. In 11.2.5 oclIsUndefined replace Evaluates to true if the self is equal to OclInvalid or equal to null. by Evaluates to true if the self is equal to invalid or equal to null. In 11.2.6 result replace Otherwise the undefined value is returned. by Otherwise the invalid value is returned. Change 11.2.5 Operations and Well-formedness Rules OclAny ... OclVoid= ... 11.2.6 OclMessage to 11.3 Operations and Well-formedness Rules 11.3.1 OclAny ... 11.3.2 OclVoid ... 11.3.3 OclMessage Move from 11.2.5 OclVoid = (object : OclAny) : Boolean Redefines the OclAny operation, returning true if object is null. post: result = object.oclIsTypeOf(OclVoid) to 11.3.2 OclVoid = (object : OclAny) : Boolean Redefines the OclAny operation, returning true if object is null. post: result = object.oclIsTypeOf(OclVoid) Remove from 11.2.5 OclInvalid = (object : OclAny) : Boolean Redefines the OclAny operation, returning true if object is invalid. post: result = object.oclIsTypeOf(OclInvalid) In 11.5.1 Real / replace Evaluates to OclInvalid if r is equal to zero. by Evaluates to invalid if r is equal to zero. In 11.5.2 Integer / replace Evaluates to OclInvalid if r is equal to zero. by Evaluates to invalid if r is equal to zero. In 11.7.1 Collection flatten replace [1] A collection cannot contain OclInvalid values. by [1] A collection cannot contain invalid values. In 12.12 paragraph 5 replace If more than one classifier is found, the operation returns OclUndefined. by If more than one classifier is found, the operation returns invalid. In A.1.1.1 replace All type domains include an invalid and a null value that allows one to operate respectively with unknown and “null” values. by All type domains include ?, an invalid value, and e, a null value, that allows one to operate respectively with invalid and undefined values. In A.1.1.2 Definition A.1 replace The main difference between classes and object types is that the interpretation of the latter includes a special undefined value. by The main difference between classes and object types is that the interpretation of the latter includes a special undefined value and a special invalid value. (OCL 2.0 typo) In A.1.1.5 Definition A.4 replace (sa) = <? c, c> by (sa) = <c, c> (OCL 2.0 typo) In A.1.1.6 Definition A.7 replace three uses of in the bottom line of the parents: definition by unicode 227A ? OCL 2.0 typo) Following A.1.1.6 Definition A.7 replace in the bottom line of the parents: definition by unicode 227A ? (OCL 2.0 typo) Following A.1.1.6 Definition A.8 point 3 replace by unicode 22C2 ? (OCL 2.0 typo) In A.1.1.7 Definition A.9 replace one use of and one use of by unicode 227A ? and M (OCL 2.0 typo) Following A.1.1.7 Definition A.9 point v. replace one use of by unicode 227A ? (OCL 2.0 typo) In A.1.2.1 remove (OCL 2.0 typo) In A.1.2.1 Definition A.10 restore the last equation to The domain of a class c Î CLASS is defined as ICLASS (c') = ?{oid(c') | c' Î CLASS ^ c' ? c} (OCL 2.0 typo) In A.1.2.2 restore the equation to " c1,c2 Î CLASS : c1 ? c2 ? I(c1) ? I(c2) . (OCL 2.0 typo) In A.1.2.3 Definition A.11 restore the last equation to Ias Î IASSOC(as). In A.2.1 Definition A.14 replace • I(Integer) = Z ? {?} • I(Real) = R ? {?} • I(Boolean) = { true, false } ? {?} • I(String) = A* ? {?} by • I(OclInvalid) = {?} • I(OclVoid) = {e,?} • I(Integer) = Z ? {e,?} • I(Real) = R ? {e,?} • I(Boolean) = { true, false } ? {e,?} • I(String) = A* ? {e,?} • I(UnlimitedNatural) = N ? {8,e,?} Following A.2.1 Definition A.14 replace Each domain also contains a special undefined value that is motivated in the next section. by Each domain also contains two special values e and ?. e coresponds to the null value, and ?, pronounced bottom, corresponds to the invalid value. These are motivated in the next section. In A.2.1.1 replace Each domain of a basic type t contains a special value ?. This value represents an undefined value that is useful for two purposes: 1. An undefined value may, for example, be assigned to an attribute of an object. ... 2. An undefined value can signal an error in the evaluation of an expression. ... The problems with partial functions can be eliminated by including an undefined value ? into the domains of types. ... ... Hence, an undefined argument value causes an undefined operation result. ... by Each domain of a basic type t contains two special values e and ?. e represents an null or undefined value and ? an invalid value. These are useful for the following purposes: 1. An undefined or null value may, for example, be assigned to an attribute of an object. ... 2. An invalid value can signal an error in the evaluation of an expression. ... The problems with partial functions can be eliminated by including the invalid value ? into the domains of types. ... ... Hence, an invalid or null argument value causes an invalid operation result. ... Following A.2.1.4 Definition A.16 replace I ?+??i1 , i2?={i1 + i2 if i1?? and i2?? ? otherwise by I ?+??i1 , i2?={i1 + i2 if i1?? and i1?e and i1?8 and i2?? and i2?e and i2?8 ? otherwise (NB. unlimited 8 is part of the resolution of the missing UnlimitedNatural specification). Replace A2.1.4 Table A.2 b1 b2 b1 and b2 b1 or b2 b1 xor b2 b1 implies b2 not b2 FALS E FALS E FALSE FALSE FALSE TRUE TRUE FALS E TRUE FALSE TRUE TRUE TRUE TRUE TRUE FALS E FALSE TRUE TRUE FALSE FALSE TRUE TRUE TRUE TRUE FALSE TRUE FALSE FALS E ? FALSE ? ? TRUE TRUE TRUE ? ? TRUE ? ? FALSE ? FALS E FAUX ? ? ? ? ? TRUE ? TRUE ? VRAI ? ? ? ? ? ? ? ? by b1 b2 b1 and b2 b1 or b2 b1 xor b2 b1 implies b2 not b2 FALSE FALS E FALSE FALSE FALSE TRUE TRUE FALSE TRUE FALSE TRUE TRUE TRUE TRUE TRUE FALS E FALSE TRUE TRUE FALSE FALSE TRUE TRUE TRUE TRUE FALSE TRUE FALSE FALSE ? or e FALSE ? ? TRUE TRUE TRUE ? or e ? TRUE ? ? FALSE ? or e FALS E FALSE ? ? ? ? ? or e TRUE ? TRUE ? TRUE ? ? or e ? or e ? ? ? ? ? (Only change is introduction of "or e" to the first two columns.) In A.2.2 replace I ?=t ??v1 , v2?={true if v1=v2, and v1?? and v2?? ? if v1=? or v2=? false otherwise by I ?=t ??v1 , v2?={true if v1=v2 and v1?? and v1?e and v1?8 and v2?? and v2?e and v2?8 true if v1=8 and v2=8 true if v1=e and v2=e ? if v1=? or v2=? false otherwise In A.2.2 replace It is also useful to have an operation that allows one to check whether an arbitrary value is well defined or undefined. This can be done with the operations isDefined t : t ? Boolean and isUndefinedt : t ? Boolean for any type t Î T. The semantics of these operations is given for any v Î I(t) by: I(isDefinedt)(v) = (v ? ? ) I(isUndefinedt )(v) = (v = ?) by It is also useful to have an operation that allows one to check whether an arbitrary value is invalid or undefined. This can be done with the operations oclIsInvalidt : t ? Boolean and oclIsUndefinedt : t ? Boolean for any type t Î T. The semantics of these operations is given for any v Î I(t) by: I(oclIsInvalidt)(v) = (v = ?) I(oclIsUndefinedt)(v) = (v = ?) ? (v = e) In A.2.3 Definition A.18 replace I(t) = literals(t) ? {?}. by I(t) = literals(t) ? {e,?}. In A.2.4 Definition A.20 replace I(t) = ICLASS(c) ? {?}. by I(t) = ICLASS(c) ? {e,?}. In A.2.4 Following Definition A.20 replace The undefined value that is only available with the type by The undefined null value that is only available with the type In A.2.4 Following Definition A.20 replace Otherwise, the result is the undefined value. by Otherwise, the result is the invalid value. In A.2.4.3 Following Definition A.21 replace The attempt to access an attribute of a non-existent object results in an undefined value. by The attempt to access an attribute of a non-existent object results in the invalid value. (OCL 2.0 typo) In A.2.4.5 restore the first equation to M = (CLASS, ATTc, OPc, ASSOC, associates, roles, multiplicities, ?). In A.2.5.4 last paragraph replace A collection value therefore may contain undefined values while still being well defined. by A collection value therefore may contain undefined null values while still being well defined. (OCL 2.0 typo) In A.2.5.5 following Table A.3 restore the first equation to Set(t) X t ? Integer In A.2.5.5 following I(count) replace A set may contain the undefined value so that the result of count is 1 if the undefined value is passed as the second argument, for example, count({?}, ?) = 1 and count({1}, ?) = 0. by A set may contain the undefined null value so that the result of count is 1 if the null value is passed as the second argument, for example, count({e}, e) = 1 and count({1}, e) = 0. In A.2.6 replace • OclVoid is the subtype of all other types. The only value of this type is the undefined value. Notice that there is no problem with cyclic domain definitions as ? is an instance of every type. by • OclVoid is the subtype of all types other than OclVoid and OclInvalid. The only value of this type is null, the undefined value. Notice that there is no problem with cyclic domain definitions as e is an instance of every type other than OclInvalid. • OclInvalid is the subtype of all other types. The only value of this type is invalid, the invalid value. Notice that there is no problem with cyclic domain definitions as ? is an instance of every type. In A.2.6.1 replace The set of special types is TS = {OclAny, OclVoid}. Let ^ T be the set of basic, enumeration, and object types ^ T = TB U TE U TC . The domain of OclAny is given as I(OclAny) = (UteT I(t)) U {?}. The domain of OclVoid is I(OclVoid) = {?}. by The set of special types is TS = {OclAny, OclVoid, OclInvalid}. Let T^ be the set of basic, enumeration, and object types T^ = TB U TE U TC . The domain of OclAny is given as I(OclAny) = (UteT I(t)) U {e,?}. The domain of OclVoid is I(OclVoid) = {e,?}. The domain of OclInvalid is I(OclInvalid) = {?}. In A.2.6.1 replace For OclVoid, the constant operation undefined : ? OclVoid results in the undefined value ?. The semantics is given by I(undefined) = ?. by For OclVoid and OclInvalid, the constant operation oclIsUndefined : ? Boolean results in the true value, and for OclInvalid, the constant operation oclIsInvalid : ? Boolean results in the true value. The semantics is given by I(OclVoid) = {e,?} and I(OclInvalid) = ?. In A.2.7 add ?. OclInvalid is a subtype of OclVoid. In A.2.7 replace 4. OclVoid is subtype of all other types. by 4. OclVoid is subtype of all types other than OclVoid and OclInvalid. In A.2.7 Definition A.27 add ?. OclInvalid = OclVoid. (OCL 2.0 typo) In A.2.7 Definition A.27 restore viii to viii. If classOf(t’c) ? classOf(tc) then t’c = tc. In A.3.1.2 above the if then else example replace An undefined condition makes the whole expression undefined. Note that when an expression in one of the alternative branches is undefined, by A null or invalid condition makes the whole expression invalid. Note that when an expression in one of the alternative branches is null or invalid, In A.3.1.2 after the if then else example replace The result of a cast expression (vi) using asType is the value of the expression, if the value lies within the domain of the specified target type, otherwise it is undefined. ... Note that these type cast and test expressions also work with undefined values since every value – including an undefined one – has a welldefined type. by The result of a cast expression (vi) using asType is the value of the expression, if the value lies within the domain of the specified target type, otherwise it is invalid. ... Note that these type cast and test expressions also work with null or invalid values since every value – including a null or invalid one – has a welldefined type. In A.3.1.5 last sentence replace Invariants with undefined result invalidate a system state. by Invariants with null or invalid result invalidate a system state. In A.3.2.1 three bullets from the end replace Hence, a reference to the previous value of attribute c is undefined. by Hence, a reference to the previous value of attribute c is invalid. In A.3.2.2 Definition A.32 second bullet replace Output parameters are undefined on entry: kind(p) = out implies ßpre(p) = ?. by Output parameters are null on entry: kind(p) = out implies ßpre(p) = e. Disposition: Resolved OMG Issue No: 14199 Title: Inaccurate well-formedness constraints for IteratorExp Source: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@willink.me.uk) Summary: The well-formedness constraints for IteratorExp are confusing, incomplete and sometimes wrong. For instance it is specified in words that for 8.3.7 IteratorExp [1] the iterator of forAll is Boolean. The subsequent constraint is correct; it is the iteration type not iterator that is Boolean. 8.3.7 IteratorExp[2] uses a non-existent property collectionType and selects the first of a number of body type returns. This seems to confuse dynamic and static behaviours.. 8.3.7 IteratorExp[4] uses boolean rather than Boolean and tests only for the name and not the meta class. The only one iterator allowed constraint is missing. There are no constraints for any, collectNested, one, sortedBy. The presentation in Section 8.3.5 is unhelpful through bundling the various iterator semantics under a single heading. Multiple headings such as IteratorExp forAll would be more readable for the full set of iterators.. Discussion: The revised text below resolves these issues. Revised Text: In 8.3.7 replace IteratorExp [1] If the iterator is ‘forAll,’ ‘isUnique,’ or ‘exists’ the type of the iterator must be Boolean.
Actions taken:
August 22, 2009: received issue
April 25, 2011: closed issue

Discussion:

The resolution of Issue 6611 is wrong. OclAny=(object : OclAny) should not be
overloaded for OclInvalid.
The resolution violates the principle that invalid results should propagate arithmetically
unless explicitly tested using oclIsInvalid() or oclIsUndefined(). The danger of this is
clear from the following example:
let expr1 : Boolean = eval1() in
let expr2 : Boolean = eval2() in
expr1 = expr2
If both eval1() and eval2() fail and return invalid, the overall result subject to the Issue
6611 resolution is true. The result must be invalid to propagate invalid.
The resolutions of Issue 10433, 10434, 12378, 12484, 12485 are wrong. OclInvalid
should remain conformant to OclVoid.
None of the resolutions address the massive conflict between Section 8 and Section 11.
While neither section is close to self consistent, Section 8 strongly suggests that
OclInvalid is the instance of Invalid which is the instance of InvalidType, while Section
11 almost mandates that invalid is the instance of OclInvalid which is the instance of
InvalidType.
The resolution of Issue 12349 is locally unhelpful through referring to invalid as
unknown and totally inadequate to address the issue of two bottoms throughout the
remaining text.
There is probably little practical difference between the alternative conformance choices
for OclVoid and OclInvalid, however the text should be consistent.
The original 2.0 Appendix A is sensibly interpreted with bottom (?) equated to invalid.
It is just necessary to introduce and equate a nearly-bottom (e) as null and align all the
text accordingly.

Issue 14199: OCL 2.0, 2.1 Inaccurate well-formedness constraints for IteratorExp (ocl2-rtf)

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

Resolution: The revised text below resolves these issues
Revised Text: see pages 53 - 57 of OMG document ptc/2010-12-01
Actions taken:
August 22, 2009: received issue
April 25, 2011: closed issue

Issue 14200: OCL 2.0 Inadequate Headings and PDF index (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

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


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


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


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


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


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


It would be helpful to


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


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


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

Resolution:
Revised Text:
Actions taken:
August 22, 2009: received issue

Issue 14222: OCL 2.1 Inconsistent implementation of Issue 6532 and contradictory resolution of Issues 7341 and 10437 (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

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


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


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

Resolution: Issue 7341 is correct.; invalid should be returned by oclAsType when the type does not conform. Issue 10437 is wrong. The 10437 revised text also incorrectly uses t rather than T. Issue 6532 specified an 'instance of Classifier' return for oclAsType. The convenience document has not been updated.
Revised Text: In Section 11.2.5 as revised by Issue 10437 replace Evaluates to self, where self is of the type identified by t. The type t may be any classifier defined in the UML model; if the actual type of self at evaluation time does not conform to t, then the oclAsType operation evaluates to null. by Evaluates to self, where self is of the type identified by T. The type T may be any classifier defined in the UML model; if the actual type of self at evaluation time does not conform to T, then the oclAsType operation evaluates to invalid. In Section 7.5.9 as revised by Issue 6532 replace oclAsType (t : Classifier) : instance of OclType by oclAsType (t : Classifier) : instance of Classifier
Actions taken:
August 26, 2009: received issue
April 25, 2011: closed issue

Issue 14224: Inconsistent lookup for underscored symbols (ocl2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

Description:


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


Should be


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

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

Resolution: Discussion: Issue 14357 introduces a new underscore-prefix string syntax (_'self') to access awkward spellings. This solves the problem of accessing either _'self' or _'_self'.
Revised Text:
Actions taken:
August 27, 2009: received issue
April 25, 2011: closed issue

Issue 14225: Set operations for OrderedSet (ocl2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

MDT OCL implementation has assumed that OrderedSet is a subtype of Set. It has become clear (11.6.3) that this assumption was erroneous. As a result, operations which are defined on Sets in the standard library (like including, excluding, intersection, union, etc.) must be undefined on OrderedSet. However, many clients (including the ones of Operational QVT) have already written code relying on this behaviour (i.e. considering that OrderedSet is a subtype of Set, they used operations like including()). It would be very helpful to define such operations on OrderedSet. It would be also important to define these counterpart operations so that they would keep the order of the elements of the initial OrderedSet, e.g:


including(object : T) : OrderedSet(T) 


The OrderedSet containing all elements of self plus object added as the last element.

post: result = self.append(object)

Resolution:
Revised Text:
Actions taken:
August 27, 2009: received issue

Issue 14236: OCL 2.1 Incomplete resolution 9913 InvalidLiteralExpCS and NullLiteralExpCS (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

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


Suggest:


Add to PrimitiveLiteralExpCS


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


and


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


(not forgetting UnlimitedNaturalLiteralExpCS

Resolution: Yes; resolution 9913 is incomplete
Revised Text: In 9.3 PrimitiveLiteralExpCS add (noting that [E] for UnlimitedNaturalExpCS is added by Issue 14196) [F] PrimitiveLiteralExpCS ::= NullLiteralExpCS [G] PrimitiveLiteralExpCS ::= InvalidLiteralExpCS and [F] PrimitiveLiteralExpCS.ast = NullLiteralExpCS.ast [G] PrimitiveLiteralExpCS.ast = InvalidLiteralExpCS.ast
Actions taken:
August 29, 2009: received issue
April 25, 2011: closed issue

Issue 14237: OCL 2.0 and 2.1 Section 9.3 CollectionRangeCS incorrect operator spelling (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The definition of the CollectionRangeCS grammar is


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


but everywhere else the operator is '..'


Suggest change to


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

Resolution:
Revised Text:
Actions taken:
August 29, 2009: received issue

Discussion:

Issue 14357: OCL 2.1 Resolution of missing Concrete Syntaxes and Reserved Words (ocl2-rtf)

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


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


Define the concrete syntax of RealLiteralExpCS and IntegerLiteralExpCS.


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

Resolution:
Revised Text: At the end of 7.4 add Multiple adjacent strings are concatenated allowing a long string to be specified on multiple lines. 'This is a ' 'concatenated ''string' -- 'This is a concatenated string' Unicode characters are used within single quoted sequences, with the following backslash based escape sequences used to define backslash and other characters. \b -- backspace \t -- horizontal tab \n -- linefeed \f -- form feed \r -- carriage return \" -- double quote \' -- single quote \\ -- backslash \xhh -- #x00 to #xFF \uhhhh -- #x0000 to #xFFFF where h is a hex digit: 0 to 9, A to F or a to f. Reserved words such as true and arbitrary awkward spellings may be used as names by enclosing the name in underscore-prefixed single quotes. self._'if' = _'tabbed\tvariable'._'spaced operation'() In 7.4.8 replace is conceptually equal to the expression: a.+(b) by is equivalent to the expression: a._'+'(b) In the first paragraph of Section 9.3 replace As a convention to the concrete syntax, conflicting properties or conflicting class names can be aliased using the «_» (underscore) prefix. Inside an OCL expression that is written with the concrete syntax, when a property name or a class name is found to start with a «_›, firstly the symbol is lookup in the metamodel. If not found, the same symbol with the «_» skipped is tried. by In the concrete syntax, names that are reserved words or include punctuation characters can be used by enclosing the required name in underscore-prefixed single quotes. _'and' _'>=' [In OCL 2.0 and 2.1 a reserved word could be used as a name after prefixing it with an underscore. _and The subsequent symbol lookup would look first for the spelling with an underscore in the meta-model and if that was not found would attempt a further lookup after removing the underscore. This behaviour was indeterminate, could not access names that existed both with and without prefixes, and did not support punctuation characters. The simple underscore prefix is therefore deprecated in OCL 2.3 and will be removed in OCL 3.0.] In 9.3 simpleNameCS replace The exact syntax of a String is undefined in UML 1.4, and remains undefined in OCL 2.0. The reason for this is internationalization. simpleNameCS ::= <String> Abstract syntax mapping simpleNameGr.ast : String Synthesized attributes simpleNameGr.ast = <String> Inherited attributes -- none Disambiguating rules -- none by The abstract syntax of a simpleNameCS String is undefined in UML 2.3, and so is undefined in OCL 2.3. The reason for this is internationalization. The concrete syntax of a simpleNameCS String supports a Unicode letter-prefixed identifier (form [A]). Reserved words and names involving awkward characters such as punctuation may be specified by prefixing a String Literal with an '_' (form [B] and [C]). [A] simpleNameCS ::= NameStartChar NameChar* [B] simpleNameCS ::= '_' #x27 StringChar* #x27 [C] simpleNameCS[1] ::= simpleNameCS[2] WhiteSpaceChar* #x27 StringChar* #x27 The identifier form starts with a Unicode letter: NameStartChar ::= [A-Z] | "_" | "$" | [a-z] | [#xC0-#xD6] | [#xD8-#xF6] | [#xF8-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF] and may continue with a Unicode letter or digit. NameChar ::= NameStartChar | [0-9] The StringChar form is defined under StringLiteralExpCS. Example simpleNameCS values are: String i3 a?et? MAX_VALUE isLetterOrDigit _'true' _'>=' _'\'' Abstract syntax mapping simpleNameCS.ast : String Synthesized attributes [A] simpleNameCS.ast = <CodePoints of NameStartChar NameChar*> [B] simpleNameCS.ast = <CodePoints of StringChar*> [C] simpleNameCS[1].ast = simpleNameCS[2] + <CodePoints of StringChar*> Inherited attributes -- none Disambiguating rules [1] [A] the character, if any, following the last NameChar is not a NameChar. [2] [A] simpleNameCS.ast is not a reserved word [3] [B] No whitespace is permitted between the '_' and the first NameChar. [4] [C] simpleNameCS[2] is a simpleNameCS [B] or [C]. In 9.3 IntegerLiteralExpCS replace This rule represents integer literal expressions. IntegerLiteralExpCS ::= <String> ... Synthesized attributes IntegerLiteralExpCS.ast.integerSymbol = <String>.toInteger() by This rule represents integer literal expressions. The lexical representation of an integer is a sequence of at least one of the decimal digit characters, without a leading zero; except that a single leading zero character is required for the zero value. IntegerLiteralExpCS ::= <Integer Lexical Representation> ... Synthesized attributes IntegerLiteralExpCS.ast.integerSymbol = <Integer Value> In 9.3 RealLiteralExpCS replace This rule represents real literal expressions. RealLiteralExpCS ::= <String> ... Synthesized attributes RealLiteralExpCS.ast.realSymbol = <String>.toReal() by This rule represents real literal expressions. A real literal consists of an integer part, a fractional part and an exponent part. The exponent part consists of either the letter 'e' or 'E', followed optionally by a '+' or '-' letter followed by an exponent integer part. Each integer part consists of a sequence of at least one of the decimal digit characters. The fractional part consists of the letter '.' followed by a sequence of at least one of the decimal digit characters. Either the fraction part or the exponent part may be missing but not both. RealLiteralExpCS ::= <Real Lexical Representation> ... Synthesized attributes RealLiteralExpCS.ast.realSymbol = <Real Value> In 9.3 StringLiteralExpCS replace This rule represents string literal expressions. StringLiteralExpCS ::= “<String> “ ... Synthesized attributes StringLiteralExpCS.ast.symbol = <String> by This rule represents string literal expressions. The concrete syntax comprises a sequence of zero or more characters or escape sequences surrounded by single quote characters. The [B] form with adjacent strings allows a long string literal to be split into fragments or to be written across multiple lines. [A] StringLiteralExpCS ::= #x27 StringChar* #x27 [B] StringLiteralExpCS[1] ::= StringLiteralExpCS[2] WhiteSpaceChar* #x27 StringChar* #x27 where StringChar ::= Char | EscapeSequence WhiteSpaceChar ::= #x09 | #x0a | #x0c | #x0d | #x20 Char ::= [#x20-#x26] | [#x28-#x5B] | [#x5D-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] EscapeSequence ::= '\' 'b' -- #x08: backspace BS | '\' 't' -- #x09: horizontal tab HT | '\' 'n' -- #x0a: linefeed LF | '\' 'f' -- #x0c: form feed FF | '\' 'r' -- #x0d: carriage return CR | '\' '"' -- #x22: double quote " | '\' ''' -- #x27: single quote ' | '\' '\' -- #x5c: backslash \ | '\' 'x' Hex Hex -- #x00 to #xFF | '\' 'u' Hex Hex Hex Hex -- #x0000 to #xFFFF Hex ::= [0-9] | [A-F] | [a-f] Synthesized attributes [A] StringLiteralExpCS.ast.symbol = <CodePoints of StringChar*> [B] StringLiteralExpCS.ast.symbol = StringLiteralExpCS[2] + <CodePoints of StringChar*> In 9.3 OperationalCallExpCS remove [3] [C] The name of the referred Operation cannot be an operator. Set{‘+’,’-’,’*’,’/’,’and’,’or’,’xor’,’=’,’<=’,’>=’,’<‘,’>’}->excludes(simpleNameCS.ast) At the end of 9.4.1 add In OCL 2.0 and 2.1 a reserved word could be used as a name after prefixing it with an underscore. Therefore, for compatibility, a lookup of simpleNameCS[A] name with a leading underscore may need to be looked up twice. The symbol is first looked up in the meta-model with the underscore prefix, and if no value is found, the symbol is looked up gain without the underscore prefix. A double lookup is not required for a simpleNameCS[B] or [C] name (an underscore-prefixed singly quoted string). The second lookup after removing the underscore prefix is deprecated in OCL 2.3 and will be discontinued in OCL 3.0. Tool implementors should provide a warning message for this deprecated usage.
Actions taken:
September 10, 2009: received issue
April 25, 2011: closed issue

Discussion:

See Issue 14583 for a resolution of reserved words and definition of
reservedKeywordCS.
Numbers
A valid integer literal should have no leading zeroes to avoid confusion with
languages that use leading zeroes to indicate octal.
A valid integer (or real) literal should have no leading sign; a unary minus may be
used to create negative values. If a leading minus is part of a number, there is a
problem parsing "5-4" after tokenising as UnlimitedNatural(5) Integer(-4) rather
than UnlimitedNatural(5) Letter(-) UnlimitedNatural(4).
A valid real literal should not have a leading or trailing dot to avoid confusion with
a dot or dot dot operator. e.g. "1..2" should be a collection range rather than "1."
and ".2". Prohibiting the edge dots avoids the ambiguity.
63
Strings
OCL 2.1 defines a string as a character string surrounded by single quotes, but
defines no mechanism for defining a single quote. It is unclear how non-printable
characters such as new-lines should be interpreted within strings, or how nonprintable
characters can be specified in the concrete syntax without causing
problems with text editors and other tools that provide special treatment for nonprintable
characters.
QVT 1.0 Operational Mappings defines a number of Java-inspired extensions,
although it applies Unicode escapes in the Concrete Syntax mapping rather than
the character serialisation. QVTo also defines concatenation of adjacent strings.
Adoption of Java-like escape sequences solves the problem of awkward
characters, although support for octal sequences seems unnecessary in modern
languages; the QVTo specification of octal sequences is flawed ('\111" has three
valid meanings).
Concatenation of adjacent strings is useful.
Introduction of \ as an escape character changes the semantics of '\' which in
OCL 2.0 and 2.1 was a valid string defining a single backslash character,
although many practical OCL 2.0 tools may have anticipated this specification of
backslash sequences.
Identifiers
UML places no constraints on identifier spellings. OCL 2.1 in 9.3 simpleNameCS
echoes this lack of constraint, but fails to identify how the arbitrary Abstract
Syntax can be realised in the Concrete Syntax.
Punctuation should not ever be a valid name in the Concrete Syntax. 9.3
OperationCallExpCS disambiguating rule 3 specifically prohibits the 'conceptual'
example in 7.4.8.
A valid Concrete Syntax name should use a Unicode variant of a letter then
letter-or-digit identifier.
An arbitrary Abstract Syntax name should be expressible by enclosing the
correspondingly arbitrary character sequence in some form of quotes, using
Java-like escaping definitions for awkward characters. The 'conceptual' example
in 7.4.8 should therefore be valid using a quoted form.
64
OCL 2.1 uses single quotes, and although OCL 2.1 does not define any
semantics for double quotes, derived languages uch as QVTo do. It is therefore
appropriate to use the existing underscore prefix for reserved words to prefix a
singly quoted string and so convert the string literal to an identifier. This
accommodates any spelling and since the need for conversion is rare the
clumsiness of three characters is acceptable.
9.3 OperationCallExpCS disambiguating rule 3 should therefore prohibit only
unquoted punctuation and reserved words. a.+(b) or a.and(b) is invalid, but
a._'+'(b) or a._'and'(b) is valid. The prohibition is therefore on the reserved
spelling rather than the use of the referenced operation.
A similar escaping mechanism should apply to awkward characters as defined
for single quoted strings, so that the \= operation can be invoked as a._'\\='(b).
Since the underscore-prefixed single quotes supports any awkward characters,
the OCL 2.0 and 2.1 underscore identifier prefix is redundant. In view of the
inadequacies highlighted in 14224 and the need to avoid the underscore prefix
syntax applying within _'_self', it is appropriate to deprecate the old underscore
prefix with a view to removing it in OCL 3.0.

Issue 14576: OCL 2.1 11.7: Clarifying Collection Well-formedness rules (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The discussion of Issue 12953 suggests that two members of the RTF agreed that is unclear
what T in e.g Set's including(Object : T) means.


The first paragraph of Section 11.6 makes clear that the intent of the specification applies to e.g. Set(T)  and
so the well-formedness rules in 11.7 refer to e.g. Set(T)::including(Object: T), so T is the known element
type of the collection. It is therefore a static error to attempt to invoke Set(T) including for an object
incompatible with the known element type T.


It would be helpful for the Section headings in 11.7 to have a (T) appended so that the 11.6 specification
of T was clearly carried over from 11.6 to 11.7. e.g.


Replace


11.7.1 Collection


by


11.7.1 Collection(T)

Resolution:
Revised Text:
Actions taken:
October 26, 2009: received issue

Issue 14577: OCL 2.1 11.7 Inflexible Collection operation signatures (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The Collection(T)::product(c2 : Collection(T2))


signature carefully uses T2 to distinguish self and argument element types.


The same distinction is missing from


Collection(T)::"="(c : Collection(T))
Collection(T)::"<>"(c : Collection(T))
Collection(T)::includesAll(c : Collection(T))
Collection(T)::excludesAll(c : Collection(T))
Set(T)::union(s : Set(T))
Set(T)::union(b : Bag(T))


etc etc


The current definition makes at least one of


Set{1.0}->excluding(1.0) = Set{1}->excluding(1)
Set{1}->excluding(1) = Set{1.0}->excluding(1.0)


invalid through lack of a suitable collection operation.


For some operations, such as union, a T2 conforms to T well-formedness constraint is appropriate,
but for others, such as removeAll, T2 and T can be independent.

Resolution:
Revised Text:
Actions taken:
October 26, 2009: received issue

Issue 14582: OCL 2.1 7.4.7 Inconsistent Operator Associativity and Precedence (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

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

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

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

Parentheses should be bulletted at high precedence.

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

Section 9.3.2 duplicates 7.4.7.

Resolution:
Revised Text: In 7.4.7 replace • message-expression operators: "^" and "^^" • dot and arrow operations: “.” and “->” by • call expressions: "^","^^", “.” and “->” In 7.4.7 remove • “if-then-else-endif” and • “let-in” then add • literal and variable expressions, “(“ and “)”, “if-then-else-endif” • “let-in” above • @pre In 7.4.7 replace Parentheses “(“ and “)” can be used to change precedence. by • “in” All infix operators are left associative, equal precedence operators are evaluated left to right. A let expression is both high precedence and low precedence; high on the left so that a let expression behaves as an atomic value in operations, low on the right so that the in-expression can be an arbitrary expression. "a + let ... in a + let ... in a + a" is "a + (let ... in (a + (let ... in (a + a))))". Parentheses “(“ and “)” can be used to change precedence and associativity. Remove Section 9.3.2
Actions taken:
October 27, 2009: received issue
April 25, 2011: closed issue

Discussion:

A non-duplicate replacement for 9.3.2 appears as a practical grammar provided
in the resolution to Issue 10439.
right-associativity is perhaps not the correct word for the hybrid behaviour of letin
that is very high precedence on the left for "let" but very low precedence on the
right for "in" to allow the let body to be an arbitrary expression.

Issue 14583: OCL 2.1 7.4.9 true, self, Bag and String are not reserved words (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

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


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

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

Resolution:
Revised Text: In 7.4.9 replace That means that the keywords cannot occur anywhere in an OCL expression as the name of a package, a type, or a property. by That means that the keywords cannot occur as a name. A reserved word may be used as the name of a package, a type, a feature, a variable or a constraint by enclosing the word in underscore-prefixed single quotes. Add to 7.4.9 retaining alphabetical order false invalid null self true At the end of 7.4.9 add The following words are restricted. A restricted word can only be used as a name when preceded by a "::". A restricted word may also be used by enclosing the word in underscore-prefixed single quotes. Bag Boolean Collection Integer OclAny OclInvalid OclMessage OclVoid OrderedSet Real Sequence Set String Tuple UnlimitedNatural Note that operation names such as iterate, forAll, and oclType, are not reserved or restricted. In 9.3 VariableExpCS replace A variable expression is just a name that refers to a variable. VariableExpCS ::= simpleNameCS ... VariableExpCS.ast.referredVariable = env.lookup(simpleNameCS.ast).referredElement.oclAsType(VariableDeclaration) ... [1] simpleName must be a name of a visible VariableDeclaration in the current environment env.lookup (simpleNameCS.ast).referredElement.oclIsKindOf (VariableDeclaration) by A variable expression is just a name that refers to a variable or self. [A] VariableExpCS ::= simpleNameCS [B] VariableExpCS ::= 'self' ... [A] VariableExpCS.ast.referredVariable = env.lookup(simpleNameCS.ast).referredElement.oclAsType(VariableDeclaration) [B] VariableExpCS.ast.referredVariable = env.lookup('self').referredElement.oclAsType(VariableDeclaration) ... [1] [A] simpleNameCS must be a name of a visible VariableDeclaration in the current environment env.lookup (simpleNameCS.ast).referredElement.oclIsKindOf (VariableDeclaration) In 9.3 add restrictedKeywordCS This production rule represents any name that is not a reserved keyword. [A] restrictedKeywordCS ::= CollectionTypeIdentifierCS [B] restrictedKeywordCS ::= primitiveTypeCS [C] restrictedKeywordCS ::= oclTypeCS [D] restrictedKeywordCS ::= 'Tuple' Abstract syntax mapping restrictedKeywordCS.ast : String Synthesized attributes [A] restrictedKeywordCS.ast = CollectionTypeIdentifierCS.ast.name [B] restrictedKeywordCS.ast = primitiveTypeCS.ast.name [C] restrictedKeywordCS.ast = oclTypeCS.ast.name [D] restrictedKeywordCS.ast = 'Tuple' Inherited attributes -- none Disambiguating rules -- none In 9.3 add unreservedSimpleNameCS This production rule represents any name that is not a reserved keyword. [A] unreservedSimpleNameCS ::= simpleNameCS [B] unreservedSimpleNameCS ::= restrictedKeywordCS Abstract syntax mapping unreservedSimpleNameCS.ast : String Synthesized attributes [A] unreservedSimpleNameCS.ast = simpleNameCS.ast [B] unreservedSimpleNameCS.ast = restrictedKeywordCS.ast Inherited attributes -- none Disambiguating rules -- none In 9.3 pathNameCS replace pathNameCS ::= simpleNameCS (‘::’ pathNameCS )? ... pathNameCS.ast = Sequence{simpleNameCS.ast}->union(pathNameCS.ast) by [A] pathNameCS ::= simpleNameCS [B] pathNameCS ::= pathNameCS ‘::’ unreservedSimpleNameCS ... [A] pathNameCS.ast = Sequence{simpleNameCS .ast} [B] pathNameCS.ast = pathNameCS.ast->append(unreservedSimpleNameCS.ast) In 9.3 add primitiveTypeCS This production rule denotes a primitive type. Abstract syntax mapping [A] primitiveTypeCS ::= 'Boolean' [B] primitiveTypeCS ::= 'Integer' [C] primitiveTypeCS ::= 'Real' [D] primitiveTypeCS ::= 'String' [E] primitiveTypeCS ::= 'UnlimitedNatural' Synthesized attributes [A] primitiveTypeCS.ast = Boolean [B] primitiveTypeCS.ast = Integer [C] primitiveTypeCS.ast = Real [D] primitiveTypeCS.ast = String [E] primitiveTypeCS.ast = UnlimitedNatural Inherited attributes -- none Disambiguating rules -- none oclTypeCS This production rule denotes a built-in OCL type. Abstract syntax mapping [A] oclTypeCS ::= 'OclAny' [B] oclTypeCS ::= 'OclInvalid' [C] oclTypeCS ::= 'OclMessage' [D] oclTypeCS ::= 'OclVoid' Synthesized attributes [A] oclTypeCS.ast = OclAny [B] oclTypeCS.ast = OclInvalid [C] oclTypeCS.ast = OclMessage [D] oclTypeCS.ast = OclVoid Inherited attributes -- none Disambiguating rules -- none In 9.3 TypeCS replace A typename is either a Classifier, or a collection of some type. by A typename is either a reserved type, or a Classifier, or a collection of some element type, or a tuple of some element types. In 9.3 TypeCS add [D] typeCS ::= primitiveTypeCS [E] typeCS ::= oclTypeCS ... [D] typeCS.ast = primitiveTypeCS.ast [E] typeCS.ast = oclTypeCS.ast In 13.2 add 3: The following operations do not form part of Essential OCL @pre ^^ ^ 4. The following names are not reserved or restricted in Essential OCL OclMessage body context def derive endpackage init inv package post pre static
Actions taken:
October 27, 2009: received issue
April 25, 2011: closed issue

Discussion:

and, else, endif, if, implies, in, let, not, or, then, xor
These are defined as reserved words in OCL 2.1.
No change; these words should be reserved for Essential OCL.
body, context, def, derive, endpackage, init, inv, package, post, pre, static
These are defined as reserved words in OCL 2.1. There is no need for these to
be reserved words in Essential OCL and consequently in derived languages such
as QVT.
Change; these words to be reserved for Complete OCL only.
false, invalid, null, self, true
These are not defined as reserved words in OCL 2.1 although the grammar
clearly uses them in reserved ways. This is very unusual. For instance true, false,
self/this are reserved in Java/C++.
If literal expression keywords are not reserved, a syntax mechanism to defeat the
occlusion by an implicit source property is required, allowing a reference to
perhaps ::true.
It is possible to define a grammar in which all ambiguous usage favours these
words, so that self::true comprises non-reserved names; very strange. Better to
reserve the names and simplify tooling and readability.
Change; these words should be reserved for Essential OCL.
Boolean, Integer, Real, String, UnlimitedNatural, OclAny, OclInvalid,
OclMessage, OclVoid
These are not defined as reserved words in OCL 2.1 although the grammar
again uses them in reserved ways. This is very unusual. For instance
boolean/bool, int, double, void are reserved in Java/C++.
It seems very undesirable that a nested environment should be able to occlude
resolution of a primitive type name and very confusing that such a name should
be used as a property name. Therefore the primitive type names should be
reserved and therefore always visible rather than selectively visible from a root
environment. If occlusion is permitted, a syntax mechanism to defeat the
occlusion would be required, allowing a reference to perhaps ::Integer.
It is possible to define a grammar in which all ambiguous usage favours these
words, so that Integer::String comprises non-reserved names; very strange.
However My::String seems reasonable and clear. This can be accommodated by
a restricted keyword concept; a restricted keyword may only be used following
a ::.
Change; Boolean, Integer, Real, String, UnlimitedNatural, OclAny, OclInvalid,
OclVoid to be restricted for Essential OCL.
Change; OclMessage to be restricted for Complete OCL only.
Bag, Collection, OrderedSet, Sequence, Set, Tuple
These are not defined as reserved words in OCL 2.1 although the grammar
again uses them in reserved ways. This is unusual. For instance class, struct,
union are reserved in Java/C.
The non-reserved status of the collection type names currently causes only minor
parsing difficulties. Problems are avoidable because the () clause is
unambiguous for type names and the {} clause is unambiguous for literals.
However if Issue 12953 is resolved to allow the collection literal syntax to be
enhanced to allow specification of an element type, such as Bag(String){}, it
becomes difficult for a parser to distinguish the prefix from an implicit source
operation call. Better to restrict the names and simplify tooling and readability.
Change; Bag, Collection, OrderedSet, Sequence, Set, Tuple to be restricted for
Essential OCL.
iterate, forAll, oclIsNew, oclIsInState etc
These are not defined as reserved words in OCL 2.1, although the grammar
again appears to use them in reserved ways.
The apparently reserved usage is very dependent on exact signatures and so
non-reserved usage is also permitted. These words are OCL Standard Library
features rather than types and consequently much more prone to extension in
future specifications.
No change; the grammar should accommodate non-reserved behaviour.
Reserved word corrolaries : primitive type names
In OCL 2.1, primitive type names are not distinct from simpleNameCS and so a
pathNameCS covers a primitive type name. Once primitive type names are
reserved it is necessary first to introduce primitiveTypeCS and oclTypeCS, and
then to use it.
primitiveTypeCS ::= 'Boolean'
primitiveTypeCS ::= 'Integer'
primitiveTypeCS ::= 'Real'
primitiveTypeCS ::= 'String'
primitiveTypeCS ::= 'UnlimitedNatural'
oclTypeCS ::= 'OclAny'
oclTypeCS ::= 'OclInvalid'
oclTypeCS ::= 'OclMessage'
oclTypeCS ::= 'OclVoid'
typeCS ::= primitiveTypeCS
typeCS ::= oclTypeCS
Reserved word corrolaries : self
In OCL 2.1, self is not distinct from a simpleNameCS. This is not true once self is
reserved. It therefore necessary to add
VariableExpCS ::= 'self'
Restricted word corrolaries
Support for restricted keywords needs a definition of restrictedKeywordCS and a
reference to it.
restrictedKeywordCS ::= CollectionTypeIdentifierCS
restrictedKeywordCS ::= primitiveTypeCS
restrictedKeywordCS ::= oclTypeCS
restrictedKeywordCS ::= 'Tuple'
unreservedSimpleNameCS ::= simpleNameCS
unreservedSimpleNameCS ::= restrictedKeywordCS
pathNameCS ::= simpleNameCS
pathNameCS ::= pathNameCS '::' unreservedSimpleNameCS

Issue 14584: OCL 2.1 9.3 Inferred TupleLiteralExp part type (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

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


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


However neither 8.3.7 nor 9.3 specifies this inference.


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

Resolution: The synthesized attributes for VariableDeclarationCS should infer when possible.
Revised Text: In Section 9.3 VariableDeclarationCS Synthesized attributes replace (accommodating Issue 14197's resolution of OclUndefined as invalid). VariableDeclarationCS.ast.type = if typeCS->notEmpty() then typeCS.ast else OclUndefined endif by VariableDeclarationCS.ast.type = if typeCS->notEmpty() then typeCS.ast else if VariableDeclarationCS.ast.initExpression.empty() then VariableDeclarationCS.ast.initExpression.type else null endif endif
Actions taken:
October 27, 2009: received issue
April 25, 2011: closed issue

Issue 14585: OCL 2.1 9.3 Missing TypeLiteralExpCS (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The expression


'a'.oclAsType(String)


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


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


Syntactically:


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


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


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

Resolution: In 9.3 LiteralExpCS add [E] LiteralExpCS ::= TypeLiteralExpCS and [E] LiteralExpCS.ast = TypeLiteralExpCS.ast and [E] TypeLiteralExpCS.env = LiteralExpCS.env In 9.3 add TypeLiteralExpCS This production rule references a type name. Abstract syntax mapping TypeLiteralExpCS ::= typeCS Synthesized attributes TypeLiteralExpCS.ast = typeCS.ast Inherited attributes typeCS.env = TypeLiteralExpCS.env Disambiguating rules -- none
Revised Text:
Actions taken:
October 28, 2009: received issue
April 25, 2011: closed issue

Discussion:

A TypeLiteralExpCS whose value is a typeCS is required.
LiteralExpCS ::= TypeLiteralExpCS
TypeLiteralExpCS ::= typeCS
This allows any type, albeit with a parsing ambiguity for pathNameCS. This can
be resolved by flattening typeCS and excluding the pathNameCS.
This extension allows Set{'a'}.oclAsType(Set(OclAny)) to be parsed.

Issue 14586: OCL 2.1 12.2.5 named-self classifierContextDeclCS (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

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


context c : Company inv:
   c.numberOfEmployees > 50

Resolution: In 12.12.2 classifierContextDeclCS replace This production rule represents a context declaration for expressions that can be coupled to classifiers. classifierContextDeclCS ::= ‘context’ pathNameCS invOrDefCS by This production rule represents a context declaration for expressions that can be coupled to classifiers. The variable declaration to the classifier context is 'self' for the A form and explicitly specified for the B form. [A] classifierContextDeclCS ::= ‘context’ pathNameCS invOrDefCS [B] classifierContextDeclCS ::= ‘context’ simpleNameCS ':' pathNameCS invOrDefCS
Revised Text:
Actions taken:
October 28, 2009: received issue
April 25, 2011: closed issue

Issue 14587: OCL 2.1 12.2.3 Incomplete resolution of Issue 9796 for attrOrAssocContextCS (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: In 12.12.2 contextDeclarationCS replace [A] contextDeclarationCS ::= attrOrAssocContextCS by [A] contextDeclarationCS ::= propertyContextDeclCS Replace 12.12.3 attrOrAssocContextCS This production rule represents a context declaration for expressions that can be coupled to an attribute or association end. The path name refers to the “owner” of the attribute or association end, the simple name refers to its name, the type states its type. attrOrAssocContextCS ::= ‘context’ pathNameCS ‘::’ simpleName’:’ typeCS initOrDerValueCS by 12.12.3 propertyContextDeclCS This production rule represents a context declaration for expressions that can be coupled to a property. The path name refers to the “owner” of the property, the simple name refers to its name, the type states its type. propertyContextDeclCS ::= ‘context’ pathNameCS ‘::’ simpleName’:’ typeCS initOrDerValueCS
Revised Text:
Actions taken:
October 28, 2009: received issue
April 25, 2011: closed issue

Issue 14591: OCL 2.1 12 Definition Accessibility Semantics (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Given the following:

context MyClass
def : isaMethod() : Boolean =
    let Collection(Operation) myOperations = oclType().oclAsType(Class).ownedOperations()
    in myOperations->exists(name = 'isaMethod')

is the value of isaMethod() true or false?

This is a more fundamental way of looking at the AST serializability problem in Issue 12854. (The suggested referredDefinition : Constraint [0..1] will not work because there may be 3 operation constraints and two property constraints.)

isaMethod() = false: OCL defininitions are not first class features and so there is no need to support their serialization.

isaMethod() = true: OCL definitions do as implied by Section 12.5 and provide reusable sub-expressions that can be used in an identical way to an atribute or operation.

It seems that an OCL evaluation needs to be defined in the following way.

Phase 1. Load MOF/UML meta-models and OCL contributions
Phase 2: Merge OCL definitions into MOF/UML meta-models
Phase 3: Execute the OCL to support queries/invariants/... on models

Phase 2 solves 12854 by requiring a merged meta-model to reify all definitions.

How the merged model is serialized is an implementation issue

Resolution:
Revised Text:
Actions taken:
October 31, 2009: received issue

Discussion:

Issue 14592: OCL 2.1 12 Definition Referencability Semantics (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The absence of synthesized and inherited attributes in 12.2 makes it unclear how an environment is maintained and so makes it unclear whether OCL supports forward and/or backward references.

Presumably both forward and backward references are allowed, so a two phase behaviour is needed to enter all definition names in the environment(s) in phase 1 so that they are visible for lookup in phase 2.

Resolution:
Revised Text:
Actions taken:
October 31, 2009: received issue

Discussion:

Issue 14593: OCL 2.1 12 UML alignment (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

12.1, 12.2 refer to UML 1.4.

12.1.1, 12.9, 12.12 defers until UML 2.0 is defined.

12.5, 12.8 uses Attribute and AssociationEnd rather than Property

12.5.1[1], 12.6.1[1], 12.7.1[1], 12.7.3[1] make use of self.constraint.stereotype.name. Constraint has
keywords rather than stereotypes

Resolution:
Revised Text:
Actions taken:
October 31, 2009: received issue

Discussion:

Issue 14594: OCL 2.1 12 Definition uses LetExp (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

12.5 define a definition body as one or more LetExps. No example wraps the expression as a LetExp.
Is this an obsolete specification or an unobserved AST structural constraint?

12.5 defines synthesis of a variable or function, but fails to distinguish these from the equivalent property or operation

Resolution:
Revised Text:
Actions taken:
October 31, 2009: received issue

Discussion:

Issue 14595: OCL 2.1 12 Inconsistencies (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

12.12: getClassifier and getPackage in text, but findClassifier and findPackage in signatures

Resolution:
Revised Text:
Actions taken:
October 31, 2009: received issue

Issue 14596: OCL 2.1 12 Essential MOF support (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

12: Why no applicability to Essential MOF models? 

Although EMOF::Operation has no precondition feature, there is no problem in an operationContextDecl imposing a truth upon the operation.

Similarly, if Initial value and Derived values are defined as Constraints in the same way as PreConditions, then the propertyContextDecl can constrain EMOF by imposing a truth upon the Property.default : String even though String is not an Expression

Resolution:
Revised Text:
Actions taken:
October 31, 2009: received issue

Issue 14597: OCL 2.1 12 Typos (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

12.12 para 3 "OCl" for "OCL".

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

12.12.2 No [B] rule

12.12.1/12.12.2 contextDeclCS/contextDeclarationCS

Resolution:
Revised Text:
Actions taken:
October 31, 2009: received issue

Discussion:

Issue 14598: OCL 2.1 12 Incompleteness (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

12.5.1[3], 12.6.1[2], 12.7.1[2], 12.8.1[2] are TBD.

Resolution:
Revised Text:
Actions taken:
October 31, 2009: received issue

Discussion:

Issue 14599: OCL 2.1 12 Documents (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

12.2 defines a syntax for a standalone OCL document, but provides no mechanism to assist an implementation in locating packages or to partition into multiple reusable documents.

a) Suggest addition of an ImportDeclarationCS 

ImportDeclarationCS ::= import StringLiteralExpCS

where StringLiteralExpCS is a URI whose MOF/UML model content an implementation should make visible within the root environment.

import is a new reserved word.

b) Suggest addition of an IncludeDeclarationCS 

IncludeDeclarationCS ::= include StringLiteralExpCS

where StringLiteralExpCS is a URI whose OCL document content an implementation should interpret (at most once) before proceeding.

include is a new reserved word.

c) Suggest addition of an OclDocumentCS

OclDocumentCS ::= (ImportDeclarationCS)* (IncludeDeclarationCS | PackageDeclarationCS[A])*

d) Suggest an OclPackage to own the Constraints for each Package and bypass the problem that Constriants do not have distinguishable names as required by Package content.

Resolution:
Revised Text:
Actions taken:
October 31, 2009: received issue

Discussion:

Issue 14639: OCL 2.1 Loop iterators are not ordered and other inconsistencies (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The iterators of LoopExp and LoopExpEval are not ordered, but the well-formedness constraints on them use ->at() which is only available for ordered collection. Usage of the AST property is subject to a variety of spelling, ordering and multiplicity inconsistencies. 
Section 7.6.3 and 7.6.4 define extended variants of forAll and exists that have two iterators.

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

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

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

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

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

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

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

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

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

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

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

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


The above suggests that the specification should consistently treat iterators as having a 1..2 {ordered} multiplicity.

Resolution:
Revised Text:
Actions taken:
November 15, 2009: received issue

Issue 14642: OCL 2.1 13.2 Reflection in OCL meta-models (correction to Issue 1 2951) (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

13.1 states that "EssentialOCL is the package exposing the minimal OCL
required to work with EMOF. EssentialOcl depends on the
EMOF Package."


13.1 states that "For convenience, because BasicOCL (respectively
EssentialOCL) is - conceptually a subset of the complete OCL
language for UML superstructure."


MOF 06-01-01 defines EMOF and Figure 12.1 clearly shows a merge of
Reflection. Therefore EssentialOCL has reflection.


UML superstructure has almost everything, so BasicOCL has reflection.


Issue 12951 provides the following revised text for 13.2. "The EMOF
Reflection capability is not merged to the metamodel."
This contradicts the above. If this is intended, OCL needs to redefine an
EMOF as perhaps OMOF with the appropriate merges.


Issue 9171 discusses why reflection is not available at the modelling level,
but is available at the meta-modelling level.


Presumably the intent is that MOF Reflection is present in the OCL
meta-model, but is not necessarily present in the constrained models and so
is not necessarily useable in OCL expressions. The revised text for Issue
12951 should be revisited to align with Issue 9171.

Resolution:
Revised Text:
Actions taken:
November 17, 2009: received issue

Discussion:

Issue 14851: OCL 2.1 Nested Collection Iteration (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The OCL specification does not make clear whether an iteration over a Collection of Collections should operate on the flattened or unflattened source.


The Appendix through lack of specification and explicit specification of flattening would suggest that the iterator for a Collection of Collections is a Collection.


Most of the description in Section 7.6 is neutral through use of the term element.


However In 7.6.1 "The variable v is called the iterator. When the select is evaluated, v iterates over the collection and the boolean expression-with-v is evaluated for each v. The v is a reference to the object from the collection and can be used to refer to the objects themselves from the collection." implies that the source collection is flattened; at least in OCL 2.0 where collections were not first class objects, this is a contradiction. In OCL 2.1, collections are nearly first class objects and so perhaps there is just an ambiguity.


Similarly:


In 7.6.2 "When we want to specify a collection which is derived from some other collection, but which contains
different objects from the original collection (i.e., it is not a sub-collection), we can use a collect operation."


In 7.6.3 "The forAll operation in OCL allows specifying a Boolean expression, which must hold for all objects in a collection:"


In 7.6.4 "The exists operation in OCL allows you to specify a Boolean expression that must hold for at least one object in a collection".


Suggest that the specification of iteration avoid the use of 'object', sticking only to 'element'. A clarifying paragraph at the end of 7.6.5 should state that for a 0 or 1 deep Collection source, element is a non-Collection object. For an N-deep Collection source, element is an (N-1)-deep Collection.

Resolution:
Revised Text:
Actions taken:
December 10, 2009: received issue

Issue 14861: OCL 2.1 Inadequate definition of run-time meta-model (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

OCL 2.1 currently specifies an informal run-time meta-model in which all types conform to OclAny. Contributions to this meta-model come from
- the user meta-model(s)
- the standard library and its extensions
- additional constraints

Problem 1: An OCL AST for an OperationCallExp has a referredOperation that must be able to reference an operation that may come from any of these sources. Issue 12854 raised the problem of referencing additional operations and attributes.

Problem 2: The almost trivial problem of referencing standard library features has not been raised. If an AST is to be portable between one OCL tool and another there must be a standard URI by which for instance OclAny::= is referenced. Where is this URI specified?

Problem 3: The semantics of ambiguity resolution between alternative contributions is unclear. UML appears to leave overloading as a semantic variation point, so UML compliance is not helpful. Issue 14591 suggested that a first phase execution created at least a composite UML meta-model.

Problem 4: OCL 2.1 made clear that there is no reflection at run-time, and introduced OclAny::oclType to compensate. This provides very limited capabilities, in particular there is no counterpart to Element::container().

A formal run-time model and meta-model can solve these problems. The run-time model is the OCL library model, it's meta-meta-model is the OCL library meta-model and it's meta-meta-meta-model is MOF/UML. NB The OCL library meta-model is not the OCL meta-model.

The OCL library model comprises primarily oclstdlib::Classifier instances, one of which is named OclAny. OclAny::oclType() returns its oclstdlib::Classifier (NB not a uml::Classifier).

The oclstdlib::Classifier::conformsTo property (like but not uml::Classifier::general) contributes to the reified type conformance hierarchy.
The oclstdlib::Classifier::operations property (like but not uml::Classifier::operations) unifies the three sources of available operations, and three different derivations of oclstdlib::Operation accommodate the three types of contribution.

The oclstdlib model therefore integrates the user's UML meta-model with the standard library and additional constraints and is built during the first phase of execution. The oclstdlib meta-model is much simpler than MOF; there is no need for Associations and ConformsTo is the only Relationship. The semantics of the oclstdlib model defined independently of UML ensure a clear definition of the meaning of OCL execution.

The oclstdlib model should make no pretence at being UML because it is fundamentally different. One form of oclstdlib::Operation integrates a reference to a uml::Operation into a uniform behavioural structure. oclstdlib::Classifier ::conformsTo provides the modification of the user meta-model to insert OclAny as the bottom type, without modifying the user meta-model.

With an oclstdlib metaModel, OclAny could provide reflective capabilities such as oclContainer(), oclContents(), oclGet(), oclSet() etc that provide useful reflective capabilities. self.oclType().operations can satisfactorily return a collection of operations even though the operations come from three diverse sources. self.oclType()->closure(conformsTo) will return the type conformance ancestry.

Resolution:
Revised Text:
Actions taken:
December 14, 2009: received issue

Issue 14881: Undefined operation tail() (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

subclause [4]


It reads:  names->tail()


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

Rationale: tail() is not an operation of Sequence

Resolution:
Revised Text: In Section 9.4.1 [4] replace names->tail() by names->subSequence(2, names->size())
Actions taken:
December 19, 2009: received issue
April 25, 2011: closed issue

Discussion:

Since there is no head() operation, it is not obvious that a tail() operation is merited.

Issue 14882: Undefined operation tail() (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

(Related to Issue 7539)


 It reads:  isOclKind


 It should read: oclIsKindOf

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

Resolution:
Revised Text: In Section 9 and 10 replace three references to isOclKind by oclIsKind Verify that neither “isOcl” nor “asOcl” survive anywhere other than Annex A.
Actions taken:
December 19, 2009: received issue
April 25, 2011: closed issue

Discussion:

Continuing on from the Issue 14094 resolution: This typo occurs once in Section 9.4.1
and twice in Section 10.

Issue 14883: Undefined operation tail() on p 130 (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Related to Issue 7539)


 It reads:  isOclKind


 It should read: oclIsKindOf

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

Resolution: This typo is addressed by Issue 14882 Disposition: Merged
Revised Text:
Actions taken:
December 19, 2009: received issue
April 25, 2011: closed issue

Issue 14884: wrong parameter type for addNamespace operation call (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

(subclause [4])
 It reads: let firstNamespace : ModelElement ... in ... 
           self.nestedEnvironment().addNamespace(firstNamespace)
 It should read:
           self.nestedEnvironment().addNamespace(firstNamespace.oclAsType(Namespace)) 
 Rationale: the signature of addNamespace is (ns: Namespace) as defined in 9.4.1 subclause [7]

Resolution:
Revised Text:
Actions taken:
December 19, 2009: received issue

Issue 14885: lookupProperty instead of lookupAttribute (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It reads: lookupAttribute


It should read: lookupProperty


Rationale: on section 8.3.8 an operation lookupProperty(attName : String) : Attribute
 is added to Classifier. The operation lookupAttribute is never defined in OCL or UML infra/superstructure (v2.1.2)

Resolution:
Revised Text:
Actions taken:
December 19, 2009: received issue

Issue 14886: wrong variable name (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

subclause [10])


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


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

Resolution:
Revised Text:
Actions taken:
December 19, 2009: received issue

Issue 14887: Issue 14593 (UML alignment: Attribute) (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

There are references to Attribute (from Core) in sections 7.5 , 8.2, 8.3.2, 8.3.8, 8.3.9, 9.3, 9.4.1, 10.3.2, 10.4.1, 10.4.3 while the UML infrastructure defines Property instead of Attribute

Resolution:
Revised Text:
Actions taken:
December 19, 2009: received issue

Discussion:

Issue 14888: No postcondition for NamedElement::getType() when self.oclIsKindOf(Namespace) (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

9.4.2 NamedElement 
 
NamedElement, as defined by OCL, links to ModelElement (from Core) and has an operation getType(): Classifier


Postconditions are given when the referred modelelelement is an instance of Classifier, VariableDeclaration or State.
However, from subclause [4] of section 9.4.1 it follows that the referred modelelelement may also be an instance of Namespace.
(let firstNamespace : ModelElement = lookupLocal( names->first() ).referredElement, where lookupLocal returns an OCL NamedElement) 


In the UML Infrastructure, Namespace specializes Core::NamedElement, which does not defines a type attribute (Core::TypedElement does)
Namespace is a generalization of Classifier.


 At least, add: 
  post: referredElement.oclIsKindOf(Namespace) implies
        result = -- TBD: when aligning with UML 2.0 
 
 Should it be result.oclIsUndefined() ?

Resolution:
Revised Text:
Actions taken:
December 19, 2009: received issue

Discussion:

Issue 14918: OCL 2.1 11.2.5 Numeric = and <> operations should compare values rather than objects (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

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


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


The definition therefore implies that:


1 = 1


may often evaluate to false, and that


1.0 = 1


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


Suggest overload {Boolean, Real, String}::{=,<>} to use values rather than objects.

Resolution:
Revised Text:
Actions taken:
January 2, 2010: received issue

Issue 14980: OCL 2.1 11.7.3 OrderedSet addition well-formedness rules (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The OrderedSet well-formedness constraints in 11.7.3 appear to have been
copied and pasted from Sequence. They need revision to consider the Set
consequences of .


Addition operations (includes, insertAt, union, append, prepend) have a
post-condition that the size increases, which is clearly not the case if
an additional element is equal to a pre-existing element.


In the particular case of insertAt there is an ambiguity as to whether
the insert index is the pre or post index. For instance when inserting 3
at index 5 into OrderedSet{1, 2, 3, 4, 5, 6} the pre-index insertion
yields OrderedSet{1,2,4,3,5,6} whereas the post-index insertion yields
OrderedSet{1,2,4,5,3,6}. While the post-index insertion satisfies the
'post: result->at(index) = object' constraint, it is presumably not the
intent.

Resolution:
Revised Text:
Actions taken:
January 17, 2010: received issue

Issue 14981: OCL 2.1 Implicit Conversion to Collection Literal (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

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


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


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


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


When a conversion is applicable is unclear.


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


if self.manager.isUndefined() then Set{} else Set{self.manager} endif->isEmpty()


so that null->isEmpty is also valid.


However is


    null->excludesAll(null)


equivalent to


    Bag{}->excludesAll(Bag{})


and so true?


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


However are


    null = Bag{}


or


    Bag{} = null


both equivalent to


    Bag{} = Bag{}


and so true?


In this case we have a problem of asymmetric overloading.


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


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


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

Resolution:
Revised Text:
Actions taken:
January 17, 2010: received issue

Issue 14982: OCL 2.1 11.7.3 Missing OrderedSet::flatten overload (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Collection::flatten is overloaded for Bag, Sequence and Set but not for OrderedSet.

Resolution:
Revised Text:
Actions taken:
January 17, 2010: received issue

Issue 14983: OCL 2.1 11.7 Missing OrderedSet::excluding and including (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

excluding and including are defined for Bag, Sequence and Set but not OrderedSet or Collection.


The Collections would be more consistent with an OrderedSet::excluding and an OrderedSet::including.


With all concrete Collection types defining excluding and including, the abstract Collection could also
define Collection ::excluding and an Collection ::including supporting fully polymorphic addition and
querying of collections.

Resolution:
Revised Text:
Actions taken:
January 17, 2010: received issue

Issue 14984: OCL 2.1 11.7.3 Missing OrderedSet::- (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The minus operation should be provided for OrderedSet as well as Set.

Resolution:
Revised Text:
Actions taken:
January 17, 2010: received issue

Issue 14985: OCL 2.1 11.2 Conflicting {OclVoid, OclInvalid}::{oclIsTypeOf, oclIsKindOf, oclAsType} semantics (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

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


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


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


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


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


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


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

Resolution:
Revised Text:
Actions taken:
January 17, 2010: received issue

Discussion:

Issue 14986: OCL 2.1 Feature Overloading Semantics are not defined (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

OCL supports feature overloading and attempts to comply with UML. OCL does not define feature overloading itself. UML leaves feature overloading as a semantic variation point.


The OCL behaviour is therefore undefined. However a variety of behaviours particularly those involving null and invalid only make sense if operations are selected at run-time according to the dynamic type.


The example from an earilier pending issue:


Sequence(OclAny){3, 3.0, '3'}->count(-(-3)) = 2


wherein


UnlimitedNatural 3 widens to Integer 3 for successful comparison with Integer 3
Real 3.0 is successfully compared to Integer 3 widened to Real
String '3' widens to OclAny and fails to compare to Integer 3 widened to OclAny.


is difficult to realise if static type resolution is applicable in which case all pair-wise value comparisons would use OclAny::= rather than Real::=.


Suggest:


OCL define that features are selected dynamically at run-time.

Resolution:
Revised Text:
Actions taken:
January 18, 2010: received issue

Issue 15005: OCL 2.1 8.3.8 OclInvalid::allInstances (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

8.3.8 states that in regard to allInstances


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


While it is true that OclInvalid has exactly one instance, the corresponding return of Set{invalid} is not well-formed.


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


Suggest:


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

Resolution:
Revised Text: In 8.2.2 replace Well-formedness Rules for the Types Package by Operations and Well-formedness Rules for the Types Package In 8.2.2 add BooleanType allInstances() : Set(Boolean) Returns Set{true,false}. In 8.2.2 add InvalidType allInstances() : Set(OclInvalid) Returns invalid, since the notional return of Set{invalid} is not well-formed. In 8.2.2 add VoidType allInstances() : Set(OclVoid) Returns Set{null}. In the last paragraph of 8.3.8 Classifier replace and other special types such as OclVoid and OclInvalid. by and other special types such as OclVoid.
Actions taken:
January 25, 2010: received issue
April 25, 2011: closed issue

Discussion:

As summarised, the consistent return of Set{invalid} is not well-formed so the actual
return must be invalid, which the text should indicate.
Migration of allInstances to Classifier by Issue 6532 has left it undefined for non-
Classifiers

Issue 15009: OCL 2.1 11.2.3 Navigated Implicit Conversion to Collection Literal (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

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

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

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

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

Resolution:
Revised Text:
Actions taken:
January 29, 2010: received issue

Issue 15010: Collection::sum is not realisable for empty collection of user defined type (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Collection::sum is defined to exploit an associative and commutative T::+(T).


However for an empty collection, the result must be a zero value of the
user defined type and there is no mechanism to determine its 0.


Suggest: require a T::zero() and provide corresponding Real::zero() and Integer::zero() and UnlimitedNatural() operations.

Resolution: deferred
Revised Text:
Actions taken:
January 31, 2010: received issue

Discussion:

Revised Text: (DO NOT APPLY REVISION SINCE FINAL DISPOSITION IS
DEFERRED)
In 11.4.1 Real add
oclZero : Real
The additive identity.
init: 0.0
oclOne : Real
The multiplicative identity.
init: 1.0
100
In 11.4.2 Integer add
oclZero : Integer
The additive identity.
init: 0
oclOne : Integer
The multiplicative identity.
init: 1
In 11.4.3 String add
oclZero : String
The additive identity.
init: ''
In 11.5.? UnlimitedNatural add
oclZero : UnlimitedNatural
The additive identity.
init: 0
oclOne : UnlimitedNatural
The multiplicative identity.
init: 1
In 11.6.1 sum() replace
Elements must be of a type supporting the + operation. … Integer and Real fulfill this condition.
post: result = self->iterate( elem; acc : T = 0 | acc + elem )
by
Elements must be of a type supporting the + operation and the oclZero property. … The oclZero property
provides the additive identity. UnlimitedNatural, Integer, Real and String fulfill this condition.
post: result = self->iterate( elem; acc : T = T::oclZero | acc + elem )
Disposition: DEFERRED
NOTE: The vote did not passed for this issue (initial disposition was
Resolved).
101
Reason :
Issue 15010 uses redefined properties with covariant types. Once the Standard
Library is
aligned with UML, this usage will not be allowed

Issue 15013: OCL 2.1 Overload resolution (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Issue 6555 introduced the 'missing' Collection::=(Collection(T)) and Collection::=(Collection(T)).


Issue 12948 changed Collection to conform to OclAny


This means that "Set{} = 1" is no longer self-evidently invalid.


According to the inherited OclAny::=(OclAny), "Set{} = 1" should be semantically legal and evaluate to false.


But if Collection::=(Collection(T)) fully occludes OclAny::=(OclAny) ,"Set{} = 1" should be a semantic analysis failure and so invalid.


Conversely "1 = Set{}" is OclAny::=(OclAny) and unambiguously false (until a Real::=(Real) overload is introduced to accommodate value rather object identity).


OCL does not specify any policy for static or dynamic resolution of overloads.


A Java-like policy of static determination of the most derived valid signature, then dynamic dispatch on the self object would seem appropriate, but:


let c1 : OclAny = Set{1}, c2 : OclAny = Set{1} in c1 = c2


must select OclAny::=(OclAny) as the static signature. Collection::=(Collection(T)) is not a derived operation with the same signature, so evaluation should use OclAny::=(OclAny) rather than Collection::=(Collection(T)) and give erroneous results swhen the collections are compared by object identity rather than collection kind and content.


Either:
OCL must specify multi-dimensional dynamic overload resolution on source and arguments


Or:
OCL should specify Java-like single-dimension dynamic overload resolution and the signature of derived operations such as Collection::=(Collection(T)) should be changed to match their inherited signature, i.e. to Collection::=(OclAny).


[Or:
All derived functionality must be folded into the base (OclAny) operation.]

Resolution:
Revised Text:
Actions taken:
January 30, 2010: received issue

Issue 15037: OCL 2.1 Section 10 problems (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Section 10 is suffering seriously from lack of update and review.

The old AssociationClassCall/AssociationEndCall/ModelPropertyCall spellings are in use throughout.

OrderedSetValue is omitted throughout.

UnlimitedNaturalExpValue is omitted throughout.

TypeExpEval is omitted throughout thereby avoiding tackling the irregular semantics of the oclIsKindOf argument.

'undefined' does not distinguish null and invalid and is variously undefined, void, UndefinedValue, OclVoidValue and UnspecifiedValue including a reference to UnspecifiedValueExp that does not exist. There should be just an OclVoidValue and an OclInvalidValue.

OrderedSet is not used where elements are clearly unique e.g. Sequence(LocalSnapShot).

OCL is regularly spelled ocl or Ocl as a non-word prefix.

An Element::indexNr is imposed on all Collection elements. Surely a distinct OrderedCollectionValue intermediate value should use the stronger OrderedCollectionElement.

It is not specified whether Element::indexNr indexes from 0 or 1 or indeed even monontonically.

Figure 10.4 omits many {ordered}and {unique} constraints.

Figure 10.4 omits LocalSnapShot.pred and succ.

10.2.1 Element assserts that Element is a tuple NameValueBinding.

10.2.1 OclMessageValue italicises the wrong use of 'name'.

10.2.2 LocalSnapShot[1] refers to ispre rather than isPre.

10.2.2 LocalSnapShot[2] asserts that the result of an implicit collect is a boolean (missing ->any).

10.2.2 ObjectValue omits the doubly-linked list validity constraint

10.2.2 TupleValue assserts that a NameValueBinding is an Element.

10.2.3 SequenceTypeValue omits a constraint on the sequential validity of Element.indexNr

10.2.3 LocalSnapShot uses notEmpty rather than nonEmpty()

10.3 para 2 refers to a non-existent OclEvaluation class

10.3 para 2 has erroneous figure references to 10.6,7 rather than 10.7,8

10.3.2 OperationCallExpEval relies on UML semantics, but fails to resolve UML's unspecified behavioural variation point on operator overload resolution. See Issue 15013.

10.3.2 OperationCallExpEval spells forAll as forall.

10.3.2 CollectionRangeEval uses isOclType(Sequence(Integer)). Any such use of collection types was invalid in OCL 2.0. Use of a collection type is not valid concrete syntax in OCL 2.1/2. The resolution of 10439 for OCL 2.3 provides concrete syntax support, but the semantics remains undefined although perhaps intuitively obvious.

As separately raised isOclType etc are incorrect spellings.

The x .. y syntax could be used to advantage in places such as 10.3.3 CollectionRangeEval.

The explicit iterator is unnecessary in for instance 10.2.2 TupleValue.

Figure 10.14 has layout problems.

Figure 10.14 shows instances <-> model associations for both Concrete and Abstract classes. The model for derived classes should be marked as derived.

10.4.2 BooleanLiteralExpEval has an unresolved MOF/UML alignment.

10.4.2 EvalEnvironment has a missing constraint on uniqueness of binding names.

10.4.2 IfExpEval has missing and operators

Generally: the constraints should be validated by an OCL checking tool.

Resolution:
Revised Text:
Actions taken:
February 4, 2010: received issue

Issue 15072: OCL 2.1 12 Missing specification of initial and derived value constraints (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Sections 12.5.1, 12.6.1, 12.7.1 specify the "invariant", "precondition", "postcondition" spellings.


Sections 12.8, 12.9, 12.10, 12.11 do not specify their corresponding spellings.


Suggest: "initial", "derivation", "body", "guard" as the conventional adjective used to qualify "constraint".

Resolution:
Revised Text:
Actions taken:
February 19, 2010: received issue

Issue 15092: OCL 2.1 conformsTo definition suggestion (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

OCL allows a user to define a run-time OCL meta-model through Property and Operation definitions that is based upon a specification-time UML meta-model.


It would be useful to allow a user to also introduce inheritance/conformance polymorphisms.


Thus:


context CommonPackage::CommonObject


context CommonPackage::CommonObject::isSerializable() : Boolean = false


context OCL::String conformsTo CommonPackage::CommonObject


context MyPackage::MyObject conformsTo CommonPackage::CommonObject


context YourPackage::YourObject conformsTo CommonPackage::CommonObject


could mix-in the capabilities of CommonObject to each of MyObject and YourObject and String.


This would allow common functionality to be mixed in once and used polymorphically rather than being added in amorphously and requiring an if-tree of per-context invocations of that functionality.

Resolution:
Revised Text:
Actions taken:
February 26, 2010: received issue

Issue 15134: String.equalsIgnoreCase(String) should result in Boolean (ocl2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Len Charest, nobody)
Nature: Revision
Severity: Significant
Summary:

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

Resolution:
Revised Text: In 11.5.1 Real replace equalsIgnoreCase(s : String) : Integer Queries whether s and self are equivalent under case-insensitive collation in the locale of self. by equalsIgnoreCase(s : String) : Boolean Queries whether s and self are equivalent under case-insensitive collation. post: result = (self.toUpperCase() = s.toUpperCase())
Actions taken:
March 17, 2010: received issue
April 25, 2011: closed issue

Discussion:

The OCL 2.2 definition provides no indication as to what the Integer return might signify,
the definition is therefore useless.
Presumably the intent is to provide similar functionality to Java's
java.lang.String.equalsIgnoreCase(String) : Boolean.

Issue 15156: OCL 2.1 Parametric references (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

OCL supports access to a variety of properties such as self.a, self.b, self.c but provides no mechanism for indirection of the property selection.


Perhaps that the standard library support reflection more effectively with:


    self.oclGet(MyClass::a)

Resolution:
Revised Text:
Actions taken:
March 30, 2010: received issue

Issue 15175: OCL 2.1 Navigation of opposites (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

UML models may explicitly declare that a Property is not navigable in order to simplify the complexity of the run-time representation of that Property.


In an EMOF representation, the non-navigable Property is missing and so an OCL constraint cannot use it, even though the OCL constraint is used at compile-time rather than run-time.


In a UML direction, a Property may be unnamed in one direction and the implicit naming of such opposites may be inadequate to permit unambiguous usage.


QVT Relations 1.1 partially works around this by introducing an opposite(Property) declaration that may be used for Keys and PropertyTemplateItems.


OCL, rather than QVT, should provide an ability to navigate a Property in an opposite direction.


In the Abstract Syntax, OppositePropertyCallExp is required to capture the inverse navigation semantics of PropertyCallExp.


In the Concrete Syntax, some alternate navigation operator is required. Perhaps "a.~b" indicates that "b" is in an inverted direction.

Resolution:
Revised Text:
Actions taken:
April 13, 2010: received issue

Issue 15218: OCL 2.2 UML-alignment of redefinition (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

At the end of Section 7.4.6 OCL 2.2 says


"For example, if class Employee redefines the age() : Integer operation of
the Person class, a constraint may access the
Person definition as in
context Employee
inv: self.age() <= self.Person::age()
For clarity, the qualified form may only be used with an explicit source
expression."


and in Section 7.5.8:


"Whenever properties are redefined within a type, the property of the
supertypes can be accessed using the oclAsType()
operation. Whenever we have a class B as a subtype of class A, and a
property p1 of both A and B, we can write:"


a clarifying example follows that is actually a disambiguation not a
redefinition.


In UML redefinition replaces an old definition with something else, which is
not what the above
excerpts imply.


In the case of redefining "Person::age() : Integer". If the redefinition is
"Employee::age() : UnlimitedNatural"
the redefinition is compatible (valid UML), so perhaps self.age() being
UnlimitedNatural and self.Person::age()
being Integer just might be useful. But allowing them to invoke different
operation bodies seems to violate
UML.


Suggest that use of a path qualification may select an occluded definition
signature for static analysis,
but may not use a redefined value or body.


[This then avoids a need for the AST to persist the distinction between X::y
as an explicit feature for
static resolution or as an implicit feature for dynamic resolution. All
features in the AST are identified by
static analysis and evaluated by dynamic resolution.]

Resolution:
Revised Text:
Actions taken:
April 22, 2010: received issue

Issue 15219: OCL 2.2 Clarity of qualified path names (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature:
Severity:
Summary:

At the end of Section 7.4.6 OCL 2.2 says


"For clarity, the qualified form may only be used with an explicit source
expression."


thereby requiring "self.Person::age()" rather than just "Person::age()".


This 'clarity' is surely just a stylistic issue.


An organisation may advocate an OCL-style guide that discourages the use of
implicit-self.
That is a free choice made by that organisation.


It does not seem appropriate for one corner of the OCL specification to
prohibit implicit-self
where consistency would imply that it should be present.


This is not a 'clarity', it is a confusion.


Suggest allow implicit-self before qualified path names (unless there is a
different
strong technical reason.)

Resolution:
Revised Text:
Actions taken:
April 22, 2010: received issue

Issue 15220: OCL 2.2 7.5.4 Property-qualified association navigation has no concrete or abstract syntax (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Section 7.5.4 describes an association navigation qualification to
accommodate
recursive associations.


e.g. self.employeeRanking[bosses]


in which "bosses" is a Property role name.


OCL 2.2 has no concrete syntax for this. Superficially it resembles an
AssociationClassCallExp, but that requires OclExpression values for its
qualifiers.


Prior to OCL 2.0 (and still present in many obstinate residual artefacts in
OCL 2.2),
there was an AssociationEndCallExp, whose syntax was identical to an
AssociationClassCallExp
and so it was removed and merged with AttributeCallExp as PropertyCallExp.


It would appear that a form of AssociationEndCallExp is required with
syntaxes


OclExpressionCS '.' pathNameCS[1] ('[' pathNameCS[2] ']')? isMarkedPreCS?
pathNameCS[1] ('[' pathNameCS[2] ']')? isMarkedPreCS?


in which pathNameCS[2] defines the NavigationCallExpCS.ast.navigationSource
that is currently completely undefined and very confusingly described in
Section 8.3.2:


"navigationSource The source denotes the association end Property at the end
of the object itself. This is used to
resolve ambiguities when the same Classifier is at more than one end (plays
more than one
role) in the same association. In other cases it can be derived."


Suggest:


Remove NavigationCallExp::navigationSource that currently has no semantics


Introduce QualifiedPropertyCallExp (and etc.) as a further NavigationCallExp
to support
the qualified navigation. It has two associations:


referredSourceProperty: Property (e.g. "bosses")
referredTargetProperty: Property (e.g. "employeeRanking").

Resolution:
Revised Text:
Actions taken:
April 22, 2010: received issue

Discussion:

Issue 15222: OCL 2.2 11.7.1 Why must + be associative for Collection::sum() (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Collection::sum() requires that its T::+() is commutative and associative.


Associativity is necessary for predictable results.


However what if it isn't?


Is there an obligation on the OCL runtime to detect non-associativity and return invalid?
- probably not possible.


Is there a permission on the OCL runtime to detect non-associativity and return invalid?
- difficult to ensure implementation portability


Is there just an informal caution to users that non-associativity may lead to unpredictable results?


Suggest: reword to permit an implementation to return invalid and caution users about unpredictable results.

Resolution:
Revised Text: At the end of 11.6.1 Collection, sum() : T insert If the + operation is not both associative and commutative, the sum expression is not well-formed, which may result in unpredictable results during evaluation. If an implementation is able to detect a lack of associativity or commutativity, the implementation may bypass the evaluation and return an invalid result.
Actions taken:
April 23, 2010: received issue
April 25, 2011: closed issue

Discussion:

No. Both associativity and commutativity are necessary for predictable results on
arbitrary collections. (Issue 15223 relaxes both for ordered collections.)
Yes. It does not seem reasonable to require an implementation to detect a lack of
associativity or commutativity, so reword to permit and warn as suggested.

Issue 15223: OCL 2.2 11.7.1 Why must + be commutative for Collection::sum() (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Collection::sum() requires that its T::+() is commutative and associative.


Associativity is necessary for predictable results.


Commutativity is not necessary, most trivially for String::+ for which sum() could usefully
concatenate an OrderedSet.


Suggest: remove the requirement for commutativity.

Resolution:
Revised Text: In 11.6.3 OrderedSet and 11.6.5 Sequence add sum() : T Redefines the Collection operation to remove the requirement for the + operation to be associative and/or commutative, since the order of evaluation is well-defined by the iteration over an ordered collection.
Actions taken:
April 23, 2010: received issue
April 25, 2011: closed issue

Discussion:

Yes. Introduction of String::+() as a shorthand for String::concat() makes the
suggestion a natural extension, but only for OrderedCollections.
No. Neither associativity nor commutativity is necessary for OrderedCollections

Issue 15224: OCL 2.2 11.5.3 What is a locale? (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The new toUpperCase, toLowerCase and equalsIgnoreCase refer to case conversion if appropriate to the locale without ever defining what a locale is or defining the preconditions for appropriateness.


These methods closely resemble Java Library methods, perhaps they should reference rather than duplicate the Java specification.


The Java toUpperCase method provides locale-dependent and local-independent variants.


Is it right for OCL to make it difficult to achieve predictable results under a Turkish locale?


It seems that the OCL standard library must provide access to the Locale and provide both Java's toUpperCase variants.

Resolution:
Revised Text: At the end of 11.1 add Certain String operations depend on the prevailing locale to ensure that Strings are collated and characters are caseconverted in an appropriate fashion. A locale is defined as a concatenation of up to three character sequences separated by underscores, with the first sequence identifying the language and the second sequence identifying the country. The third sequence is empty but may encode an implementation-specific variant. Trailing empty strings and separators may be omitted. The character sequences for languages are defined by ISO 639. The character sequences for countries are defined by ISO 3166. 'fr_CA' therefore identifies the locale for the French language in the Canada country. Comparison of strings and consequently the collation order of Collection::sortedBy() conforms to the Unicode Collation algorithm defined by Unicode Technical Standard#10. The locale is 'en_us' by default but may be configured by a property constraint on OclAny::oclLocale. The prevailing locale is defined by the prevailing value of oclLocale within the current environment; it may therefore be changed temporarily by using a Let expression. let oclLocale : String = 'fr_CA' in aString.toUpperCase() At the end of 11.2.5 add oclLocale : String Defines the default locale for local-dependent library operations such as String::toUpperCase(). In 11.4.3 String add < (s : String) : Boolean True if self is less than s, using the locale defined by looking up oclLocale in the current environment. > (s : String) : Boolean True if self is greater than s, using the locale defined by looking up oclLocale in the current environment. post: result = not (self <= s) <= (s : String) : Boolean True if self is less than or equal to s, using the locale defined by looking up oclLocale in the current environment. post: result = ((self = s) or (self < s)) >= (s : String) : Boolean True if self is greater than or equal to s, using the locale defined by looking up oclLocale in the current environment. post: result = ((self = s) or (self > s)) In 11.4.3 String toUpperCase() replace if appropriate to the locale by using the locale defined by looking up oclLocale in the current environment. In 11.4.3 String toLowerCase() replace if appropriate to the locale by using the locale defined by looking up oclLocale in the current environment.
Actions taken:
April 23, 2010: received issue
April 25, 2011: closed issue

Discussion:

Introduction of a Locale class into the OCL Standard Library to allow a Locale to
be passed as an additional argument to all locale-dependent functions is a rather
heavyweight solution to this problem.
It seems much simpler to define OclAny::oclLocale as the default locale, with
oclLocale in the current context as the prevailing locale so that users may
temporarily change locale using a let expression.
(Issue 15134 corrects the 'locale' reference in equalsIgnoreCase).

Issue 15232: OCL 2.2 Correction to Issue 9796 for isPre (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Issue 9796 responded to the problem with the undefined (and undefinable) withAtPre().


However the textual replacement of ".withAtPre()" by ".isPre = true" is not valid.


For instance


[D] AttributeCallExpCS.ast.source = if isMarkedPreCS->isEmpty()
then OclExpressionCS.ast
else OclExpressionCS.ast.withAtPre() endif


should be elaborated to:


[D] AttributeCallExpCS.ast.source = OclExpressionCS.ast
[D] AttributeCallExpCS.ast.isPre = isMarkedPreCS->notEmpty()

Resolution:
Revised Text:
Actions taken:
April 29, 2010: received issue

Issue 15233: OCL 2.2 Correction to Issue 9796 for AssociationEndCall (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Issue 9796 responded to the merge of Attribute and AssociationEnd as Property in UML
by merging AttributeCallExp and AssociationEndCallExp.


This merge was not appropriate since UML made no change to the required OCL navigability.


Without AssociationEndCallExp, it is not possible to express a qualified association navigation,
since the 'replacement' PropertyCallExp does not allow for the qualifiers in:


    self.customer[123456]

Resolution:
Revised Text:
Actions taken:
April 29, 2010: reeived issue

Issue 15234: OCL 2.2 Generalisation of Issue 7341 PathNames (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Issue 7341 changed a number of syntaxes to permit a PathNameCS rather than a SimpleNameCS,
so that scope ambiguities could be resolved.


It is not clear why this was applied uniformly to all syntaxes where a name reference is in use. As a minimum
it just gives the user the discretion to clarify a subtle statement, and it avoids the impression that pathed-names
are special. It also avoids the need for some very similar concrete syntax expositions.


More specifically in an AssociationClassCallExpCS it would allow disambiguation of Left::Link and Right::Link as
alternate AssociationClasses.


Suggest allow PathNameCS in all places where there is not a specific requirement for a SimpleNameCS.

Resolution:
Revised Text:
Actions taken:
April 29, 2010: received issue

Issue 15235: OCL 2.2 UML Alignment of association names (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

In accordance with Nicolas Rouquette's observations in the discussion on "15233 -- OCL 2.2 Correction to Issue 9796 for AssociationEndCall":

The problem with OCL 2.2, Fig 7.1 are: 
- give a name to the association end near Bank, e.g. 'bankAccount'
- fix the multiplicity of: Person::bankAccount from 0..1 to * -- i.e., a person can have zero or more bank accounts!
- fix the multiplicity of Bank::customer from 0..* to 0..1 -- i.e., there is zero or one customer for a given 'accountNumber' value.
- give a name to the association itself, e.g., BankAccount, or, if you want to use the UML notation convention, A_customer_bankAccount

and

The OCL examples for Figure 7.2, currently: 


context Person inv: self.employeeRanking[bosses]->sum() > 0 
context Person inv: self.employeeRanking[employees]->sum() > 0 
context Person inv: self.employeeRanking->sum() > 0 -- INVALID! 
context Person inv: self.job[employer] 


should be fixed to:


context Person inv: self.EmployeeRanking[bosses]->sum() > 0 
context Person inv: self.EmployeeRanking[employees]->sum() > 0 
context Person inv: self.EmployeeRanking->sum() > 0 -- INVALID! 
context Person inv: self.Job[employer] 


That is, 'EmployeeRanking' is the name of the association shown in Fig 7.2
That figure does not have anything called 'employeeRanking' and it is misleading to suggest that in OCL the name of the association could be written with a lowercase initial letter when the name of the association itself has an initial capital letter. Since lexical names are case-sensitive in both UML and OCL, case-sensitivity should be respected to avoid creating confusion and potential ambiguity with other names that are lexically different only by their upper/lower case letter.

and


In particular, the text in clause 7.5.4 about using the name of an association class with a lowercase initial letter should be removed.
That is, change the following, currently:


To specify navigation to association classes (Job and Marriage in the example), OCL uses a dot and the name of the association class starting with a lowercase character: 


context Person inv: self.job 


The sub-expression self.job evaluates to a Set of all the jobs a person has with the companies that are his/her employer. In the case of an association class, there is no explicit rolename in the class diagram. The name job used in this navigation is the name of the association class starting with a lowercase character, similar to the way described in the sub clause “Missing AssociationEnd names” above. 


to:


To specify navigation to association classes (Job and Marriage in the example), OCL uses a dot and the name of the association class:


context Person inv: self.Job 


The sub-expression self.Job evaluates to a Set of all the jobs a person has with the companies that are his/her employer. In the case of an association class, there is no explicit rolename in the class diagram. The name Job used in this navigation is the name of the association class.

Resolution:
Revised Text: In Figure 7.1 add bankAccount as the opposite role name of Bank.customer. change the multiplicity of Person.bankAccount from 0..1 to 0..*. change the multiplicity of Bank.customer from 0..* to 0..1. add CustomerAccount as the name of the Bank..Person association. In 7.5.3 replace Missing AssociationEnd names When the name of an association-end is missing at one of the ends of an association, the name of the type at the association end starting with a lowercase character is used as the rolename. If this results in an ambiguity, the rolename is mandatory. This is, for example, the case with unnamed rolenames in reflexive associations. If the rolename is ambiguous, then it cannot be used in OCL. Qualifying association ends with association names In cases the association that is being navigated has a non empty name, it is possible to qualify the accessed role name with the name of the association. This notation can be used to solve ambiguities as in the example below: A1 and A2 are two associations both linking classes C1 and C2 and each with ends c1 and c2. If a C1 is aC1 access, aC1.c2 will not be valid since it is ambiguous, whereas aC1.A1::c2 or aC1.A2::c2 will be valid. by Missing Association names The association name is never missing. If no explicit name is available, an implicit name is constructed in accordance with the UML style guide. Associations that are not explicitly named, are given names that are constructed according to the following production rule: “A_” <association-end-name1> “_” <association-end-name2> where <association-end-name1> is the name of one association end and lexically precedes <association-end-name2> which is the name of the other association end. Missing Association End names The name of an association-end is never missing. If no explicit name is available an implicit name is taken from the name of the class to which the end is attached. Note to tool vendors; this is a non-normative change from OCL 2.2, where the UML style guidance of converting the first letter of the implicit name to lowercase was endorsed. The normative text has never defined how implicit names are obtained. Tool vendors may wish to provide backward/forward compatibility warnings for this change. This may result in an ambiguity between an implicit association end name and another explicit name, unless only one of the association ends is navigable. The ambiguous name cannot be used in OCL. aPerson.role -- ambiguous Qualifying association ends with association names An association end name may be qualified with its association name or its source classifier name to resolve an ambiguity. aPerson.Person::role -- still ambiguous aPerson.A_person_role::role -- some Parts, using implicit Person to Part association name aPerson.A_owner_role::role -- a Role, using implicit Person to Role association name In 7.5.4 first paragraph delete starting with a lowercase character: In 7.5.4 first example replace self.job by self.Job In 7.5.4 second paragraph replace self.job by self.Job and job by Job and delete starting with a lowercase character, similar to the way described in the sub clause “Missing AssociationEnd names” above. In 7.5.4 second, third and fourth examples replace self.employeeRanking by self.EmployeeRanking In 7.5.4 fourth, fifth and sixth paragraphs replace employeeRanking by EmployeeRanking In 7.5.4 fifth example replace self.job by self.Job In 7.5.15 third example replace two occurrences of c.job by c.Job
Actions taken:
April 30, 2010: received issue
April 25, 2011: closed issue

Discussion:

The summary summarises a thread discussion.
Introduction of the new names in Figure 7.1 is not absolutely necessary, but it
may prove helpful in discussions and related examples.
CustomerAccount seems better than BankAccount since there is no possibility of
111
misinterpretation as a case conversion with respect to another name.
The multiplicities in Figure 7.1 are surprising, but not actually wrong. The
suggested replacements are better, although they do not accommodate a joint
account.
While aligning association names with UML, it seems appropriate to make the
corresponding association end name alignment clearer.

Issue 15249: Why OCL does not have "super" reference? (ocl2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

I hope someone can explain to me why OCL does not have a reference to "super" (similar to the existing reference to "self"). Wouldn't you want to sometimes call the redefined version of an operation from an OCL exrpression, similar to how you can do that in Java?

From my limited knowledge of ALF (the action language), I understand it supports the "super" reference, so this tells me there is no semantic restriction there?

Resolution:
Revised Text:
Actions taken:
April 20, 2010: received issue

Discussion:

Issue 15254: the use of the keyword 'attr' (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

I've seen, in the version 2.0, the existence of the keyword 'attr'. But then, in fact, there isn't any reference or explanation about the use of this keyword.
I've seen that this keyword is not in the new versión 2.2. But, you use it in the page 25, ln 12.

Resolution: deferred
Revised Text:
Actions taken:
May 14, 2010: received issue

Discussion:

The 'attr' is a relic of a former (pre OCL 2.0) syntax.
The 'attr' should be omitted, and 'TupleType' should be 'Tuple'. [UML compliance,
as observed in Issue 15235, requires 'Job' rather than 'job'].
This issue is resolved as part Issue 12456.
Disposition: Deferred
NOTE: Initialdisposition: Merged with 12456. Issue is Deferred since votation did not pass.
Reason: (missing merged resolution 12456)

Issue 15257: OCL 2.2 OclState and oclIsInState (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The oclIsInState takes an OclState argument, which is referenced extensively
in
Annex A, although the OclState type is never defined in the main text and is
not
mentioned in the grammar as a reserved word.


oclIsInState is misspelled as oclInState 7 times in Section 7.5.9 and once
in A.2.6.

Resolution:
Revised Text:
Actions taken:
May 18, 2010: received issue

Issue 15258: OCL 2.2 OclMessage types are not statically derivable (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The intro to Section 8.2 states:


"OCL is a typed language. Each expression has a type that is either
explicitly declared or can be statically derived."


However OclMessage lacks type parameterisation and so the 7.7.2 example


context Subject::hasChanged()
post: let messages : Sequence(OclMessage) = observer^^update(? : Integer, ?
: Integer) in
        messages->notEmpty() and
        messages->exists( m | m.i > 0 and m.j >= m.i )


only works if the type analysis proceeds beyond "messages :
Sequence(OclMessage)" to
discover the initialiser with formal signature "Observer::update(i :
Integer, j : Integer)".


This will not in general be possible and so expressions such as "m.i > 0"
cannot be
statically checked, and cannot be dynamically expressed. Indeed since m is
an OclMessage,
"m.i" is not well-formed.


Suggest that OclMessage is redefined as:


OclMessage<OclOperation> or OclMessage<OclSignal>


requiring the type to be determinate or discovered by oclAsType.

Resolution:
Revised Text:
Actions taken:
May 18, 2010: received issue

Issue 15270: Definition for symmetric difference is wrong (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

symmetricDifference: is defined as (S1 u S2) - (S1 u S2), but this always yields the empty set. I believe the intended writing is (S1 u S2) - (S1 n S2).

Resolution:
Revised Text: Throughout Annex A change ? to whichever of. ? or n is used in Annex A of 03-10-14.
Actions taken:
June 1, 2010: received issue
April 25, 2011: closed issue

Discussion:

Absolutely.
This is another corruption resulting from the migration of the Latex Annex A of 03-10-14
(which is correct) to FrameMaker.
Looking at Table A.4 suggests that all n have been converted to ?. The entire Annex
must therefore be checked for every occurrence of ?.

Issue 15357: OCL 2.2 OclState, State, StateExp, StateExpCS, StateValue and StateExpEval (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The use of OclState in the specification is not defined in the normative part of the specification, where it appears solely as OclAny.oclIsInState(statespec : OclState).


A corresponding StateExp exists to convey this as a referredState of type State.


Surely the OclState type is redundant and it should be OclAny.oclIsInState(statespec : State)?


The use of OclState in Annex A may be helpful, so perhaps an introduction to Annex A could explain the mappings between the names used for clarity in Annex A and those used in the normative specification.


Aren't a StateValue and StateExpEval needed to define the semantics?


Isn't a StateExpCS needed to define the abstract/concrete syntax? Perhaps this could merge with TypeExpCS, TypeLiteralExpCS as ModelElementLiteralCS.

Resolution:
Revised Text:
Actions taken:
July 8, 2010: received issue

Issue 15367: OCL 2.2 Add endlet to make grammar extensible (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Further to Bran Selic's observation on Issue 15357 that UML-specifics should not really impact the OCL core. This is easy for State via a ModelLiteralExp, but hard for Message which has associated concrete syntax.


The expression grammar could be made extensible to accommodate custom/orthogonal infix, prefix, suffix, precedence if an expression could be parsed by the generic:


expr ::= affixed (infix affixed)*
affixed ::= prefix* suffixed
suffixed ::= atom (suffix | '(' expr ')' | '[' expr ']' | '{' expr '}' )*
atom ::= '(' expr ')'
    | name
    | 'if' expr 'then' expr 'else' expr 'endif'
    | 'let' expr 'in' expr 'endlet'


The major problem is the missing 'endlet', which makes accurate parsing difficult and complex expressions easy for humans to misinterpret too.


Suggest introduce the 'endlet' keyword.

Resolution:
Revised Text:
Actions taken:
July 9, 2010: received issue

Issue 15368: OCL 2.2: Section: 7.5.3 Clarification required for Qualifying association ends with association names (ocl2-rtf)

Click here for this issue's archive.
Source: EMC (Mr. George Ericson, ericson_george(at)emc.com)
Nature: Uncategorized Issue
Severity:
Summary:

The text in the clause titled “Qualifying association ends with association names” points out that it is possible to qualify an accessed role name with the name of the association using the ‘::’ separator.  (In the example: aC1.A1::c2.)   There is no issue with this as a means to access the associated instance.  However, in doing so, the clause misses the opportunity to also say that it is also possible to reference the same associated instance using the ‘.’ (dot) operator in place of the ‘..’ separator, (for example: aC1.A1.c2).

 

While this was also true prior to OCL 2.2, only the later technique was referenced in OCL 2.0.   

 

Clarification is needed with respect to whether or not there are any semantic differences between the uses of these two techniques.  Where the functionality overlaps, is there a preferred technique?

 

Nit: the last sentence of the example:  

“If a C1 is aC1 access, aC1.c2 will not be valid since it is ambiguous, whereas aC1.A1::c2 or aC1.A2::c2 will be valid.”  

Should probably say: 

“If aC1 isa C1, then aC1.c2 will not be valid since it is ambiguous, whereas aC1.A1::c2 or aC1.A2::c2 will be valid.”

Resolution:
Revised Text:
Actions taken:
July 9, 2010: received issue

Issue 15387: OCL 2.2: AST is an ASG (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The AS is referred to in a number of places as an abstract syntax tree. This is a misnomer that causes confusion in some academic circles. The AS should always be referred to as a Graph.

Resolution:
Revised Text:
Actions taken:
July 29, 2010: received issue

Issue 15412: OCL Constraint violation messages (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

OCL supports definition of constraints, but it is difficult for tools to offer better error messages to a user than 'Constraint <constraint-name> violated for <constrained-element-name>'.


It would be helpful if Constraints had an additional String-valued expression to be evaluated in the context of the error, so that tools could evaluate it and present the result to the user.


Suggest add an optional argument to the (not-optional) constraint name. e.g.


inv ConstraintName('Unable to find ' + self.target.name): ...

Resolution:
Revised Text:
Actions taken:
August 11, 2010: received issue

Issue 15420: OCL Enumeration allInstances (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

UML defines Enumeration.ownedLiteral as an ordered set. Surely allInstances() should therefore return an OrderedSet for an enumeration, and perhaps an ordinal property should be added by the Standard Library.

Resolution:
Revised Text:
Actions taken:
August 18, 2010: received issue

Issue 15425: OCL Generics (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

UML supports generics/templates. OCL doesn't. This is a UML alignment failure.

Resolution:
Revised Text:
Actions taken:
August 21, 2010: received issue

Issue 15426: OCL Stereotypes (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The OCL 2.2 specification refers to stereotypes in the UML 1.x sense. These need to be aligned with UML 2.x. Are they 'keyword' or 'Stereotype'? Is there an OCL Profile to be applied?


NB. the sterotypes are of two forms:
a) Constraint role: invaraint/precondition/...
b) UML extension: OclHelper for a Complete OCL def (see 7.4.4.)

Resolution:
Revised Text:
Actions taken:
August 23, 2010: received issue

Issue 15527: toLowerCase referred to as toLower (similarly for toUpperCase) (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

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

Also toUpperCase is referred to as toUpper in the same places

Resolution:
Revised Text: In Section A.2.1.2 change are possible with toUpper and toLower to are possible with toUpperCase and toLowerCase In Table A.1 change ToUpper to toUpperCase In Table A.1 change toLower to toLowerCase
Actions taken:

Discussion:

Issue 15528: toLowerCase() declared as returning Integer (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

In section "11.4.3 String" on p145 toLowerCase() is declared as returning Integer, correct type is String

Resolution:
Revised Text: In Section 11.4.3 change toLowerCase : Integer to toLowerCase : String
Actions taken:
September 14, 2010: received issue
September 14, 2010: received issue
April 25, 2011: closed issue
April 25, 2011: closed issue

Issue 15710: OCL 2.2 forAllAt suggestion (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

It is common in an iteration to require in iteration index.


This can be achieved rather expensively by indexOf, or less expensively by
iterating over an integer literal range.


It would be easier to define e.g.


forAllAt(index : Integer, i : T)


etc so that an implementation can supply the index efficiently.

Resolution:
Revised Text:
Actions taken:
October 8, 2010: received issue

Issue 15712: OCL 2.2 Allow optional let type (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

9.3.36 states "A variable declaration inside a let must have a declared type and an initial value."


In the case of a Tuple literal assigned to a let variable, this requires that the tuple signature be entered twice.


Suggest relaxing the requirement on a type to allow deduction from the initial value.

Resolution:
Revised Text:
Actions taken:
October 11, 2010: received issue

Issue 15761: OCL 2.3 Ballotted: Retracting resolutions for Issue 10439/13076 (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

I am no longer happy with my resolution of 10439/13076 which provides a 
very high resolution LALR grammar. This is inefficient to emulate with 
LL and cannot provide the flexibility of configurable precedence. It 
will also be very difficult to accommodate a template parameter parse 
with similarly high precision. I now favour a low precision syntactic 
parse augmented by high precision disambiguation/semantic checks.

If the high precision LALR grammar may need retraction, it seems 
undesirable to put it into 2.3 only to remove it in 2.4.

Suggest retract the resolutions for OCL 2.3 and rewrite for OCL 2.4 once 
UML-alignment of templates has been accommodated

Resolution:
Revised Text: Do not apply the text revisions in the resolution of Issue 10439. Issues 10439 and 13076 remain Deferred.
Actions taken:
October 9, 2010: received issue
April 25, 2011: closed issue

Discussion:

As suggested, exclude the LALR grammar from OCL 2.3, deferring resolution of issues
10439 and 13076 until UML-alignment issues such as templates (Issue 15425) have been
accommodated in a practical grammar.

Issue 15780: OCL 2.2 Unlimited and Infinity (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

OCL supports a '*' value for UnlimitedNatural in order to accommodate the
full range of UML multiplicities.


UnlimitedNatural conforms to Integer and Real, so that any UnlimitedNatural
conversion must perform a run-time check in order to convert '*' to invalid.
This conversion cannot be replicated in the reverse direction.


Suggest that '*' be aligned with the conventional IEEE math notion of
infinity, so that
* and -* are valid values for Integer and Real. UnlimitedNatural is then a
simple restriction of Integer which is a simple restriction of Real.

Resolution:
Revised Text:
Actions taken:
October 25, 2010: received issue

Issue 15789: Vagueness about meaning of 0..1 multiplicity in OCL and UML (ocl2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

UML-alignment of OCL type signatures
--------------------------------------------------------
 
Following discussion in the "Vagueness about meaning of 0..1 multiplicity in OCL and UML" threads
of the UML2 and OCL RTFs the following problems exist in alignment of the UML and OCL type systems.
 
The OCL specification does not provide a clear description of the comparative semantics of for instance
Integer[1] and Integer[0..1].
 
The Complete OCL syntax for an Operation Context Declaration uses OCL type decalarations and so
fails to provide the same expressivity as a UML operation declaration with multiplicities.
 
Suggest:
 
a) a clear indication that 
 
An Integer[1] may have integer values, null or invalid, of which only integer values are well-formed.
 
An Integer[0..1] may have integer values, null or invalid, of which integer values and null are well-formed.
 
b) an enhancement to the type declaration syntax to allow
 
Integer[0..1] or Integer[1] to indicate a nullable/non-nullable value.
 
Set(Integer[1..7]) to capture the expressivity of a UML multiplicity

Resolution:
Revised Text:
Actions taken:
October 28, 2010: received issue

Issue 15790: OCL 2.2 Missing definition of navigation (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Dot and arrow navigation have implied definitions in the non-normative clause 7, but nothing in the normative clauses.


Implicit collect is missing from clause 9, save for the throwaway final sentence "The mapping
is not formally defined in this document but should be obvious."


This mapping is far from obvious; if it was obvious it would be easy to define.


In particular it is important to define that a static syntax determination is made to ensure that:


anObject . feature => object navigation
anObject -> feature => implicit collection (of anObject's static ordering/uniqueness) containing a non-null anObject
aCollection -> feature (or iterator) => collection navigation
aCollection . feature (or iterator) => implicit collect = aCollection -> collect(feature or iterator)
(implicit source object implicit .) feature => object navigation
(implicit source collection implicit ->) feature (or iterator) => collection navigation


with the object/collection discrimination performed statically, so that the navigation
algorithm is statically determinate; only the dynamic dispatch on self is subject to
dynamic determination.


The conformance of a collection to OclAny must never used to allow object navigation on a collection. This avoids a syntax ambiguity for "aCollection . name" between implicit collect and object navigation of a collection feature, or between implicit collect and object navigation of an object feature.

Resolution:
Revised Text:
Actions taken:
October 31, 2010: received issue

Issue 15836: OCL 2.3 Incomplete CollectionRange well-formedness rules (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
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}.

Resolution:
Revised Text:
Actions taken:
November 18, 2010: received issue

Discussion:

Issue 15838: OCL 2.3 max, min iterations (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

It would be usefuil to have iterations analoguous to isUnique that compute max or min of a user-defined expression body over a collection.

Resolution:
Revised Text:
Actions taken:
November 20, 2010: received issue

Discussion:

Issue 15877: Issue on Alignment of next OCL version and references UML 2.4/ MOF 2.4 (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
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.

Resolution:
Revised Text:
Actions taken:
December 7, 2010: received issue

Issue 15920: OCL 2.3.TupleType semantics and AST (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

8.2 Does the lack of restriction on feature types for a TupleType extend to InvalidType and VoidType? With an InvalidType feature the tuple could only be 'well-formed' when containing an invalid value. Surely a tuple with an invalid value is itself invalid and not well-formed?


8.2.2 TupleType has some ASCII code corruptions in the OCL.


8.2.2 TupleType uses unqualified names for feature types allowing an ambiguity when package path is significant.


10.2 TupleValue surely values must not be invalid?


13 TupleLiteralExp has a TupleLiteralPart which has a Property, not accommodating the OclExpression of an initExpression provided by the concrete syntax. Surely a TupleLiteralPart is a derived VariableDeclaration adding an initExpression?

Resolution:
Revised Text:
Actions taken:
January 8, 2011: received issue

Discussion:

Issue 15922: typo in ptc/2010-11-42 and pas/2010-08-02 (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Hiroshi Miyazaki, miyazaki.hir-02(at)jp.fujitsu.com)
Nature: Uncategorized Issue
Severity:
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".

Resolution:
Revised Text:
Actions taken:
January 10, 2011: received issue

Issue 15980: The opertion "collect" is confused with the operation "reject" (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

"Reject" should be replaced with "collect" in the following line:
"The value of the reject operation is the collection of the results of all the evaluations of expression-with-v."

Resolution:
Revised Text:
Actions taken:
January 24, 2011: received issue

Issue 16018: OCL 2.3 : Introduce Lambda functions (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

OCL already has an implicit form of Lambda function in the intuitive declaration of collect(). This should be formalised and made more versatile. It doesn't seem to be possible to formulate a declaration for collect() without a Lambda Function:


Sequence(T1)::collect(T2)(iterator : T1 | body : Lambda T1() : T2) : Sequence(T2)


The mandatory collect body is a parameter-less Lambda function whose context-type is the class template parameter T1 and the return-type is the operation template parameter T2.


For other iterators the declaration can be just OclExpression since the type is not exploited.

Resolution:
Revised Text:
Actions taken:
February 12, 2011: received issue

Discussion:

Issue 16019: OCL 2.3 Introduce a reserved OclSelf template parameter (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Three library operations do not appear to be declarable without intuitive typing semantics.


Introduction of an OclSelf template parameter that is the statically determined type of self can solve the problem. OclSelf is a reserved spelling.


Classifier::allInstances(OclSelf)() : Set(OclSelf)        -- set of the derived classifier
OclAny::oclType(OclSelf)() : OclSelf                          -- my own type as statically known
OclAny::oclAsSet(OclSelf)() : Set(OclSelf)                -- set of my own and derived types, declared as the statically known type


[oclAsSet is the currently unspecified library operation used to realise implicit object-to-set conversion]


Without an OclSelf, almost any usage of these library operations must be followed by an oclAsType to the already known type.


e.g. with the OCL 2.3 type system the library function is


Classifier::allInstances() : Set(Classifier)


and so the usage is


MyType.allInstances()      -- is MyType instances as a Set(Classifier)
MyType.allInstances().oclAsType(Set(MyType))             -- necessary cast to statically known type

Resolution:
Revised Text:
Actions taken:
February 12, 2011: received issue

Discussion:

Issue 16044: OCL 2.3 Pathname syntax does not allow access to hidden names (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

If meta-models provide both 'B::x' and 'A::B::x', it is not possible to access 'B::x' from a context with 'A::B' since 9.4.1[4] searches from the current scope and so resolve 'B' in 'B::x' to 'A::B'.


Suggest adoption of the C++ '::' global prefix so that '::B::x' can be used when 'A::B' occludes.

Resolution:
Revised Text:
Actions taken:
February 27, 2011: received issue

Issue 16048: oclIsInState() (ocl2-rtf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
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 “::”.

Resolution:
Revised Text:
Actions taken:
March 7, 2011: received issue

Issue 16106: OCL 2.3 - heterogeneous collections cannot be typed (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

A Collection containing both 'a', and {'b', 'c'} must be typed as a
Collection of OclAny since that is the only common type.


This is unhelpful for tree structures.


Suggest introduction of a pseudo-collection type Tree(T) to which
both T and Collection(Tree(T)) conform.


A String content tree then then be declared as a Tree(String).

Resolution:
Revised Text:
Actions taken:
April 4, 2011: received issue

Issue 16121: US PAS Ballot Comment 1 (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
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.

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Issue 16122: US PAS Ballot Comment 2 (ocl2-rtf) References (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
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
“

Resolution:
Revised Text: The following updates will be applied: (0) In Section 1 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. By This specification defines the Object Constraint Language (OCL), version 2.3.1. OCL version 2.3.1 is the latest version of OCL that is aligned with UML 2.3 and MOF 2.0. (1) In Section 3, 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.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.3 Superstructure Specification: http://www.omg.org/spec/UML/2.3/Superstructure/PDF/ • UML 2.3 Infrastructure Specification: http://www.omg.org/spec/UML/2.3/Infrastructure/PDF/ • MOF 2.0 Core Specification: http://www.omg.org/spec/MOF/2.0/PDF/ • ISO/IEC 10646:2003 Information technology -- Universal Multiple-Octet Coded Character Set (UCS) • UNICODE 5.1 Standard: http://www.unicode.org/versions/Unicode5.1.0/ • Unicode Technical Standard#10: http://www.unicode.org/reports/tr10/ • ISO 639 Codes for the representation of names of languages • ISO 3166 Codes for the representation of names of countries and their subdivisions 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 “ (2) In Section 7.3.3 Invariants, replace text: “In the following example the name of the constraint is enoughEmployees. ”In the UML 1.4 metamodel, this name is a (meta-)attribute of the metaclass Constraint that is inherited from ModelElement.” By: “In the following example the name of the constraint is enoughEmployees.” (3) In Section 7.5.12 Collections of Collections, replace the paragraph: “In UML 1.4 a collection in OCL was always flattened (i.e., a collection could never contain other collections as elements). This restriction is relieved in UML 2.0. OCL allows elements of collections to be collections themselves. The OCL Standard Library includes specific flattened operations for collections. These can be used to flatten collections of collections explicitly.” By “ OCL allows elements of collections to be collections themselves. The OCL Standard Library includes specific flattened operations for collections. These can be used to flatten collections of collections explicitly” (4) At the end of Section 9.1 replace sentence: “The disambiguating rules are written in OCL, and use some metaclasses and additional operations from the UML 1.4 semantics” by “The disambiguating rules are written in OCL, and use some metaclasses and additional operations from UML”. (5) In Section 10.2.1, in foot note of “StaticValue” clause, replace sentence: “As StaticValue is the counterpart of the DataType concept in the abstract syntax, the name DataValue would be preferable. Because this name is used in the UML 1.4 specification to denote a model of a data value, the name StaticValue is used here” By “StaticValue is the counterpart of the DataType concept in the abstract syntax, the name DataValue would be preferable. StaticValue is used for historical reasons concerning past versions of UML. “ (6) In Section 10.4.2, in clause OclMessageExpEval , rule [5] replace sentence “Note that the Parameter type is defined in the UML 1.4 foundation package” by “Note that the Parameter type is defined in the UML metamodel” (7) In Section 12.1 Introduction, replace sentence: “In principle, everywhere in the UML specification where the term expression is used, an OCL expression can be used. In UML 1.4 OCL expressions could be used (e.g., for invariants, preconditions, and postconditions)” by “ n principle, everywhere in the UML specification where the term expression is used, an OCL expression can be used.(e.g., for invariants, preconditions, and postconditions). (8) In Section A.2.6 Special Types replace the sentence “The exception has been introduced in UML1.3 because it considerably simplifies the type system [CKM+99]” by “The exception has been introduced in UML because it considerably simplifies the type system [CKM+99]” (9) In Section 6.2 replace sentence: “The OCL Language Description clause gives an informal description of OCL in the style that has been used in the UML versions 1.1 through 1.4.” By “The OCL Language Description clause gives an informal description of OCL” (10) In Section 6.2 replace sentence: “Clause 8 (“Abstract Syntax”) describes the abstract syntax of OCL using a MOF 2.0 compliant metamodel. This is the same approach as used in the UML, v1.4 and other UML 2.0 specifications. The metamodel is MOF 2.0 compliant in the sense that it only uses constructs that are defined in the MOF 2.0.” by “Clause 8 (“Abstract Syntax”) describes the abstract syntax of OCL using a MOF compliant metamodel . This is the same approach as used in UML specifications. The metamodel is MOF compliant in the sense that it only uses constructs that are defined in the MOF.” (11) In Section 12.2 replace “ In UML (1.4) the Expression … “ By “In UML the Expression ...”
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

Comment:
References to UML and MOF need to be updated to most recent versions.
Unnecessary references to UML 1.4 need to be removed or replaced by more neutral
references (“UML” instead of “UML 1.4”). This concerns at least 6 locations in the spec,
like in Section 7.3.3 Invariants and in Section 7.5.12 Collection of Collections.

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
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. ”

Resolution:
Revised Text: In Section 6.1 replace: “ This specification replaces the specification of OCL given in OCL 2.2. “ With: “ This specification replaces the specification of OCL given in OCL 2.2. The version of OCL specified in ISO/IEC 19501:2005 is intended for use in models based on UML 1.4.2 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. ”
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Issue 16124: Japan PAS Ballot Comment 1 (ocl2-rtf) (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: As the text above the table 2.1 explains, said template table is intended to be filled by OCL Tool implementors. Disposition: Closed
Revised Text:
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
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.

Resolution: 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
Revised Text:
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Usage of upper/lower case letter is inconsistent with UML.
For example, “Invariant”, “Precondition”, “Postcondition”, etc, in the text should be lower case letter. However, there are UML metamodel elements, such as “Classifier”.
Especially, “collection type” in function flatten, p158, is lower case letter. If this is designated in lower case letter, it is difficult to understand the meaning of sentence. What about “collection type” L1 on 11.2.1? It is confusing whether those are metamodel elements or not.)
It is required to be consistent with convention of UML upper case letter, since this standard is a family of UML, that is, it is required to use upper case letter only for UML/OCL Metamodel element.

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Discussion:

Initial Comment : It is required to be consistent with convention of UML upper case letter, since this
standard is a family of UML, that is, it is required to use upper case letter only for UML/OCL Metamodel
element.
Comment: In general metaclass names start with upper letter whereas attributes and operations with lower
letters. However within an explanatory text, to ease reading, we believe it make sense not always to use the
capitalized form to refer to a metaclass concept, specially when the term has a meaning in natural language
like “invariant”.
Anyway, a more detailed check to the spec is needed to see if this issue requires any change.
Disposition: Deferred

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Many figures shown by UML are not unified in line color and  hatching color. Unify them.

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Discussion:

Initial Comment/Suggestion: Unify them.
Comment: Figures in chapter 8 are all unified, but this is not the case for chapters 9 and 10
because they were constructed by different tools and people and not yet re-build since the FTF.
Disposition: Deferred

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
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:

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
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”.

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Discussion:

See comment JP 6 in “…_JISC.doc”  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip Initial Comment/Suggestion: : OCL “Constraint” should be distinguishable from UML
“Constraint”.
Comment: In fact OCL do not define the concept of Constraint since this concept is taken from UML. So
there is no need to distinguish them since they are the same concept.
A more detailed check to the spec is needed to see if this issue requires any change.
Disposition: Deferred

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: 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.
Revised Text: In section 7.4.5, the paragraph just above the Table 7.4: Replace: The type conformance rules for the types from the OCL Standard Library are listed in Table 7.4. By: The type conformance rules for the types from the OCL Standard Library are listed in Table 7.4, where the third column specifies an additional condition which must be satisfied by the involved types to verify the type conformance rule. In section 7.4.5, after the paragraph just below the Table 7.4 Add: Although UnlimitedNatural conforms to Integer, '*' is an invalid Integer, so that the evaluation of the expression '1 + *' results in invalid.
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

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

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Initial Comment: Make clear which “latter” implies.
Revised Text: Change In Section 10.3.2 OperationCallExpEval P127: “type. The latter will be specified in 10.4 “ to “type, as specified in clause 10.4 “
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

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

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
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.

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Discussion:

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

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
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”.

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

See comment JP 10 in “…_JISC.doc”  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip In OCL 2.3, 7.4.9 section, there is a statement which clarifies how this kind of operation
names should be treated: "Note that operation names such as iterate, forAll, and oclType,
are not reserved or restricted."
Therefore, “forAll”, “exists”, “any”, etc are not keywords.
Disposition: Closed

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Closed as Fixed by OCL 2.3 Disposition: Closed
Revised Text:
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

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

Issue 16135: Issue nnnn: Japan PAS Ballot Comment 12 (ocl2-rtf) Section 8.3.1 Fig 8.2 & FeatureCallExp in p43 (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

There is no attribute designation of FeatureCallExp in Fig 8.2. However, in Attribute of FeatureCallExp class description (p43), isPre is described. Add isPre to Class “FeatureCallExp” on the class diagram (Fig. 8.2)

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Discussion:

See comment JP 12 in “…_JISC.doc”  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip. Initial comment/suggestion: Add isPre to Class “FeatureCallExp” on the class diagram
Comment: Normally attributes should appear in all diagrams in chapter 8 (exactly as
'stringSymbol' in Fig 8.12). Hence an update of the diagram is needed.
Revised Text:
Change Diagrams 8.8, 8.9, 13.22 and 13.23 so that FeatureCallExp has the “isPre” attribute.
Proposed Disposition: Resolved
Disposition after 1st ballot: Deferred
(Majority of YES not reached. Reason: The change should apply to Figures 8.8
and 8.9 but should not apply to figures 13.22 and 13.23 because isPre is not
part of EssentialOCL).

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Typo. contaxt, change to context

Resolution: Initial Comment: contaxt->context Comment: Close as Fixed by OCL 2.3 Disposition: Closed
Revised Text:
Actions taken:
January 11, 2012: closed issue

Discussion:

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

Issue 16137: Japan PAS Ballot Comment 14 (ocl2-rtf) - Section 8.3.2 Fig8.3 & AssociationClassCallExp (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

As class description, there is a AssociationClassCallExp. However, there is no Class on the class diagram in Fig.8.3.. Proposed change: Add Class “AssociationClassCallExp” on the class diagram in Fig. 8.3.

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Discussion:

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

Issue 16138: Japan PAS Ballot Comment 15 (ocl2-rtf) Section 8.3.5 Fig8.7 & following class description (p50-p51) (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

The class diagram on Fig8.6 & Fig8.7 and its class description is inconsistent. For example, there is TupleLIteralPart on the class diagram. However, there is no class description in p51. Additionally, as class description of CollectionLiteralPart, Associations describes “type”. Furthermore, PrimitiveLiteralExp doesn’t have any attributes on the class diagram (Fig 8.6). However, followed class description, p51, Attribute “symbol” is described. And, there is a referredEnumLiteral as class description. However, class diagram doesn’t have referredEnumLiteral on Fig. 8.6. PROPOSED RESOLUTION: Correct class diagram and its class description

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Discussion:

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

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Initial comment: Replace this with [1]. Comment: Close as Fixed by OCL 2.3 Disposition: Closed
Revised Text:
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

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

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Initial comment: Replace this with simpleNameCS. Comment: Close as Fixed by OCL 2.3 Disposition: Closed
Revised Text:
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

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

Issue 16141: Japan PAS Ballot Comment 18 (ocl2-rtf) (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
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.

Resolution: 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
Revised Text:
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

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

Issue 16142: Issue from PAS Ballot comment for ISO/IEC DIS 19507 Section 9.3.29 OperationCallExpCS (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
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).

Resolution: Initial Comment/Suggestion: Replace that part with the list below this table (Listing#1).
Revised Text: In Section 9.3.35 OperationCallExpCS, increase the indentation for line starting “SetType.allInstances”
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

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

Issue 16143: Japan PAS Ballot Comment 20 Section 9.3.29 OperationCallExpCS (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Synthesized attributes, [D], [F], [G]   The meaning of “and” at the end of the line is not clear and seems inconsistent with other parts. Are these logical operations? Add text to clarify this

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Discussion:

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

Issue 16144: Japan PAS Ballot Comment 21 (ocl2-rtf) Section 9.3.37 OclMessageExpCS (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Synthesized attributes, [B]   TBD should not be a part of International Standard. Modify the text as appropriate

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Discussion:

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

Issue 16145: Japan PAS Ballot Comment 22 (ocl2-rtf) .4.2 NamedElement 9.4.3 Namespace, 11.2.5(p.135), 12.8.1(p.173) (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Main text. TBD should not be a part of International Standard. Modify the text as appropriate.

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: 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
Revised Text: (1) In 8.3.4, remove “See [Kleppe2000] for a complete description and motivation of this type of expression, also called “action clause.” (2) In OclMessageExpVal clause, replace “As explained in [Kleppe2000] the only demand..” by “The only demand ..” .. (3) In Section 10, remove the sentence: I”t explains the semantics of OCL in a manner based on the report Unification of Static and Dynamic Semantics for UML [Kleppe2001], which in its turn is based on the MML report [Clark2000].”
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

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

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
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’

Resolution: Initial Comment: Complete the quote like the following. ’The Expressions Package’ ’The Types Package’ Comment: Close as Fixed by OCL 2.3 Disposition: Closed
Revised Text:
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

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

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Discussion:

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

Issue 16149: Japan PAS Ballot Comment 26 (ocl2-rtf) 10.2 The Values Package, 1st paragraph (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

UndefinedValue is explained in the text but is not included in any of the following diagrams. Add this element to the diagram.

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Discussion:

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

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
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

Resolution: 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
Revised Text:
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

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

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
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.

Resolution: “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
Revised Text: In section 10.2.3, ObjectValue[1]: Replace: The operation getCurrentValueOf results in the value that is bound to the name parameter in the latest snapshot in the history of an object value. By: The operation getCurrentValueOf results in the value that is bound to the name parameter in the bindings of the latest snapshot in the history of an object value.
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

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

Issue 16152: Japan PAS Ballot Comment 29 (ocl2-rtf) 10.2.4 Overview of the Values Package (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Figure 10.5 StringValue only appears here. No explanation was given before the diagram. Add definition or explanation of StringValue before this diagram

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Discussion:

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

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
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

Resolution: 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.
Revised Text: In Section 10.3, after Figure 10.6 change paragraph “Figure 10.6 shows the core part of the Evaluations package. The basic elements in the package are the classes OclEvaluation, PropertyCallExpEval, and VariableExpEval. An OclEvaluation always has a result value, and a name space that binds names to values. In Figure 10.7 the various subtypes of model propertycall evaluation are defined. “ to “Figure 10.6 shows the core part of the Evaluations package. In Figure 10.7 the various subtypes of OclExpEval are defined. An OclExpEval always has a result value, and a name space that binds names to values.”
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

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

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Suggested action: Modify the heading as appropriate.
Revised Text: In Section 10.3.1 change the heading “OperationCallExp” to “OperationCallExpEval”.
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

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

Issue 16155: Japan PAS Ballot Comment 32 (ocl2-rtf): 10.3.1 Definitions of Concepts for the Evaluations Package, figure 10.11 (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

TupleLiteralExpPartEval is not included in Figure 10.11.  Is VariableDeclEval the one? Add this element to Figure 10.11.

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Discussion:

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

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Initial Comment/Suggestion: Use the same UML description Comment : Resolved by using uml infrastructure 13.2.4 definition for string type:
Revised Text: In Section 11.4.3 String, change “which can be both ASCII or Unicode “ to “A string is a sequence of characters in some suitable character set used to display information about the model. Character sets may include non-Roman alphabets and characters.
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

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

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
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

Resolution: The unique difference, that the first diagram misses the CollectionKind.Collection Enumeration literal. Remove the first diagram.
Revised Text: In section 13.3, figure 13.27, there are two diagrams. Remove the first one.
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

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

Issue 16161: OCL 2.3 7.5.3 Missing Association End name problems (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The 'clarified' text in OCL 2.3 for missing association ends, is still unclear.


Problem 1: if multiple association ends acquire the same name, what happens? Suggest: they all acquire the same name and the resulting lookup up finds multiple names which should be diagnosed as an ambiguity and consequently a semantic error.


Problem 2: if a missing association end is recursive, a class acquires a property with the same name as the class. Consequently invocation of e.g X.allInstances() for class X may encounter an ambiguity while resolving X. Is it self.X or global X? Suggest: auto-generated missing names may only be invoked via a navigation operator.


Problem 3: does a derived association end get a resolution for a missing name? if OCL is used to define a number of helper properties that all return the same type, then provision of the  missing 'opposites' results in unhelpful clutter at best. Suggest: missing names are not provided for derived association ends.

Resolution:
Revised Text:
Actions taken:
April 26, 2011: received issue

Issue 16168: OCL 2.3 Enumeration::allInstances() does not return instances (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

a)  an OrderedSet would be more appropriate
b) enumeration literals are instances of EnumerationLiteral; they are not instances of an Enumeration


cf. MyClass.allInstances() dynamically overloads Classifier.allInstances() to return all known instantiations of MyClass, rather than all features of MyClass.


so why does MyEnumeration.allInstances() prevent me discovering all instantiations of MyEnumeration; Enumeration is a Classifier.


The required functionality of MyEnumeration::allInstances() is available as MyEnumeration.ownedLiteral provided reflection is consistently defined.


Suggest: remove the Enumeration.allInstances() overload.

Resolution:
Revised Text:
Actions taken:
May 6, 2011: received issue

Issue 16235: Use of the word meta (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
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.

Resolution:
Revised Text:
Actions taken:
May 13, 2011: received issue

Issue 16260: on page 153 oclIsInState is used instead of oclInState (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
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!

Resolution:
Revised Text:
Actions taken:
May 20, 2011: received issue

Issue 16291: Confusing usage of the "precedes" symbol for generalization hierarchy (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

The symbol &#8826; 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 &#8827; 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.

Resolution:
Revised Text:
Actions taken:
May 28, 2011: received issue

Issue 16302: Prime symbol lacking in the explanation preceding the formula (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

In the 3rd item of the definition A.12 (System State), the paragraph before the formula ends by :
 "whereas the function &#61552;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.

Resolution:
Revised Text:
Actions taken:
June 1, 2011: received issue

Issue 16303: Unbalanced parenthesis in the formula (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 1, 2011: received issue

Issue 16305: Comparison operators don't exist for Boolean (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
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.

Resolution:
Revised Text:
Actions taken:
June 1, 2011: received issue

Issue 16306: The t should be subscripted next to the equal sign (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
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.

Resolution:
Revised Text:
Actions taken:
June 1, 2011: received issue

Issue 16348: OCL 2.3 Collecting elemental collections (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

collect and collectNested have irregular semantics that ignore the natural (outer) collection element type when used on nested collections:


i.e Set{Set{1.0}}->collect(toString()) is Set{Set{1.0}}->collect(s : String | s.toString())


so how might an iteration over the outer collection element type be performed?


Presumably, for homegeneous collections, by explicitly specifying the iterator type as Set{Set{1.0}}->collect(s : Set(String) | s->size())


Suggest: collect, collectNested specify that the implicit iterator type is the innermost collection type, and that an explicit type may
specify a collection type that successfully iterates when all leaves of the tree are uniquely contained in a corrsponding iteration element
of the iterator type, else the iteration is invalid.


Can't see a solution for heterogeneous solutions

Resolution:
Revised Text:
Actions taken:
June 25, 2011: received issue

Issue 16370: OCL parsed OCL string literal (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

As part of the support for lambda expressions an ability to parse OCL from a string would be useful

Resolution:
Revised Text:
Actions taken:
July 14, 2011: received issue

Issue 16487: OCL 2.3 A.2.6 Collection conforms to OclAny contradiction (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Issue 12948 "Making OclAny denote any object" was resolved to allow Collection to conform to OclAny.


A.2.6 still states "A simple set inclusion semantics for subtype relationships as described in the next sub section would not be possible due to cyclic domain definitions if OclAny
were the supertype of Set(OclAny)."


A premise for Annex A has therefore been violated requiring rework to consider at least a less simple set inclusion semantics.

Resolution:
Revised Text:
Actions taken:
August 6, 2011: received issue

Issue 16911: OCL 2.3: Message support hard to consume (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The support for messages uniquely requires dedicated concrete syntax: ^, ^^, ?


This makes provision of Essential OCL tooling without messages and Complete OCL tooling with messages hard.


The operators are hard to remember and inconsistent with OCL where "forAll" is favoured over upside-down A.


Suggest replace ^,^^,? by OclElement::hasSent(), OclElement::messages() and Message::Unspecified (possibly just null), so that Messages can be modularized as an Standard Library extension of additional types, operations and attributes only. No concrete syntax change.

Resolution:
Revised Text:
Actions taken:
December 14, 2011: received issue

Issue 16936: need clear specification for how to write OCL that refers to the stereotypes applied to a model within a UML profile (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Yet another query on an Eclipse newsgroup has asked how stereotypes/profiles work in a transformation language, so I've taken a brief look and it appears that UML 2.5 Section 12 appears gives the only clue as to how an OCL expression might navigate a Stereotype:


self.base_Interface.ownedAttributes->size() = 0


This is a particularly unfortunate example since it uses reflection, or at least multiple meta-levels, which are not currently supported in OCL 2.x.


Once OCL supports reflection and type literals, I would expect to see something more like


Interface.ownedAttribute->size() = 0


The constraint presumably is that the stereotype has no attributes, regardless of the class to which it is applied.


Reflective operation might do something like


self.oclType().selectFragment(Interface).ownedAttribute->size() = 0


(if selectFragment is an OCL library operation that selects a type merge contribution).


The utility of the meta-level traversing 'base_xxxx' and 'extension_xxxx' seems very suspect. Does any tool support them? I know Eclipse UML2 has at least a 'base_xxxx' name, but I doubt that it is reflective. It's sole purpose seems to be to give me trouble with validation errors.


-----------------


It seems to me that in the same way that (for base classes):


A class C (with property c) may have base classes B1 (with properties b, b1) and B2 (with property b, b2) allowing implicit access such as aC.c, aC.b1, aC.b2, but requiring qualification for aC.B1::b and allowing redundant qualification for aC.B1::b1.


then (for stereotypes):


A Class C may have stereotypes S1 (with properties s, s1) and S2 (with properties s, s2) allowing implicit access such as aC.s1, aC.s2, but requiring qualification for aC.S1::s and allowing redundant qualification for aC.S1::s1. The implicit access is only permissible when it is statically known that the Stereotype has been applied, i.e for an expression whose context is the Stereotype. In more general contexts the Stereotype qualification may need a run-time check and an invalid result if the Stereotype has not been applied. Thus:


not aC.S1::s1.oclIsInvalid() implies some-expression-when-S1::s-exists


If property overloading is forbidden, but operation overloading permitted, in the above


adding a property C::b, or S1::c or S2::b2 would be a static error since the added property overloads a property name already present in the extended class. Note that this is not in accord with the current OCL specification that motivates the introduction of qualification to support access to hidden property names, which UML prohibits.


adding any operation in a stereotype is valid; it is either a new or overloaded operation. However two stereotypes contributing the same operation signature is a static error to be detected by the attempt to apply both stereotypes.


Since the WFRs for the above belong in UML, presumably the above should be in the UML specification, and the OCL specification should just map the alternate navigation syntaxes appearing in the UML specification to appropriate Concrete and Abstract Syntax Expression elements.

Resolution:
Revised Text:
Actions taken:
December 30, 2011: received issue

Discussion:

Issue 16998: OCL 2.3 OclInvalid::= is vague (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Issue 14197 finally resolved the semantiscs of OclInvalid, but the end result was that there is no OclInvalid section in 11.3. Add an 11.3.x for OclInvalid that enumerates all relevant OclInvalid behaviors; in particular = and <> return invalid for any invalid argument.

Resolution:
Revised Text:
Actions taken:
January 14, 2012: received issue

Issue 17220: OCL String::indexOf (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The description of String::indexOf() states "No string is a substring of the empty string.".


This modifies the axiom that every string is a substring of itself. It would appear that the empty string has got confused with null.


An extension of the library with startsWith and endsWith operations would require the modified axiom to be accommodated making corner cases equivalently strange.


This modified axiom is not observed by other String libraries such as the java.lang.String.


Suggest: Replace the text:


"The empty string is considered to be a substring of every string but the empty string, at index 1. No string is a substring of the empty string."


by


"The empty string is a substring of every string at index 1 (and also at all other indexes)."

Resolution:
Revised Text:
Actions taken:
March 9, 2012: received issue

Issue 17306: ISO has changed the following normative references to its documents (ocl2-rtf)

Click here for this issue's archive.
Source: Object Management Group (Ms. Linda Heaton, linda(at)omg.org)
Nature: Uncategorized Issue
Severity:
Summary:

ISO 639 has been replaced by a six-part series.  The new reference should be:  ISO 639 (all parts)
ISO 3166 has been replaced by a three part series.  The new reference should be:  ISO 3166 (all parts)
ISO 10646 is new and this reference should be:  ISO 10646:2011, Information technology - Universal Coded Character Set (UCS)

Resolution:
Revised Text:
Actions taken:
April 12, 2012: received issue

Issue 17463: Navigation from Association Classes does not conform to UML 2.4.1 (ocl2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

The navigation from Association Classes does not conform to UML 2.4.1 because of 7.3.4 AssociationClass on page 44 UML Superstructure Specification, v2.4.1. the kind of navigation allowed by OCL is not allowed by UML, i.e. the navigation from the association class to the ends of the association is explicitly not allowed by UML but allowed by OCL. I see here a contradiction. I checked UML 2.1.2 from 2007 and in that UML this navigation from the association class the ends of the association was still allowed. I think that OCL 2.3.1 is not compatible with UML 2.4.2 from this point of view. Please tell me if this opinion is correct. If this contradiction that I remarked really exists than what to expect from the future: OCL or UML point of view?

Resolution:
Revised Text:
Actions taken:
July 1, 2012: received issue

Issue 17531: non(not(X)) should be X (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Revision
Severity: Minor
Summary:

In http://www.linkedin.com/redirect?url=http%3A%2F%2Fwww%2Ebrucker%2Ech%2Fprojects%2Fhol-ocl%2FFeatherweight-OCL%2Foutline%2Epdf&urlhash=vacm&_t=tracking_anet Burkhart Wol ff argues that lopgical consistency requires that not(not(X)) is X.


OCL 2.3.x does not satisfy this for 'null'.

Similary null and true  = null not invalid ...

Resolution:
Revised Text:
Actions taken:
July 27, 2012: received issue

Issue 18125: any iteration unsuitable for null Collection content (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

The any() iteration is specified to return null in the event that no match is found. However null could also be the return of a successful match of null. e.g


Sequence{null}->any(s | s = null)

Suggest: change the match-not-found return to invalid.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18254: Align OCL bodyExpression and UML bodyCondition (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

OCL 12.10 awaits alignment with the UML 2.0 metamodel.


Consequently, the relationship between a result-valued OCL bodyExpression and a Boolean-valued UML bodyCondition is unspecified. A common pragmatic resolution has been to equate the two and ignore the Boolean-valued requirement of a UML Constraint.


In order to accommodate prevailing practice and also support UML's multiple out/inouts, suggest:


Reinterpret the grammar


prePostOrBodyDeclCS ::= ‘body’ (simpleNameCS)? ‘:’ OclExpressionCS


such that


the simpleNameCS is the name of the return parameter with 'result' as the anonymous default


OclExpressionCS is a result-valued bodyExpression if OclExpressionCS does not reference the simpleNameCS or its defgault.
OclExpressionCS is a Boolean-valued bodyCondition if the return parameter is referenced.


[Allow multiple body declarations.]


Thus


"body: ..." is a shortform of "body result: ..." which is a shortform for "body result: result = ..."


and


body: ...
body A: ...
body B: ...


could be the specification of a UML operation

f(out a : A, inout b : B, in c : C) : Z

Resolution:
Revised Text:
Actions taken:
November 9, 2012: received issue

Issue 18255: Align OCL with out/inout UML Operation Parameters (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

OCL 9.4.5 gives no recommendation on how to handle the multiple out capability of UML.


Suggest that the mapping of a UML operation with out or inout parameters to an OCL operation do the following:


remove all 'out' parameters from the OCL parameter list so that the OCL parameter list contains only 'in' and 'inout' parameters with 'read-only' behavior


change the return type to a Tuple whose part-names and types are determined by the conventional 'result' and the 'out' and 'inout' parameters.

It is also desirable to relax the upper multiplicity bound to allow multiple bodyExpressions in Complete OCL, one bodyExpression per returning parameter.

Resolution:
Revised Text:
Actions taken:
November 9, 2012: received issue

Issue 18319: OclAny::oclAsType postcondition implies type change (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

post: (result = self) and result.oclIsTypeOf( t )


requires oclAsType to change the type of self.


The constraint should be:


post: (result = self) and result.oclIsKindOf(t)


[Review all usage of oclIsType() since it's nearly always wrong to use oclIsType rather than oclIsKindOf.]

Resolution:
Revised Text:
Actions taken:
December 14, 2012: received issue

Issue 18437: Clarify invalid propgation/conformance priority (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

There is a contradiction between invalid conform to anything and invalid always propagates for e.g.


Sequence{}->first().oclIsKindOf(Class)


oclIsKindOf uses the invalid input to return true.


Invalid propagation should dominate giving invalid.

This requires OclInvalid::oclIsKindOf, oclIsTypeOf, oclType, oclAsType overloads to explicitly return invalid.

Resolution:
Revised Text:
Actions taken:
February 11, 2013: received issue

Issue 18464: Inconsistent inclusion of source in closure results (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

"The returned collection of the closure iteration is an accumulation of the source, and the collections resulting from ..."

incorrectly includes the source. The algorithm in 11.9.1 correctly includes the source only if the source is reached by some traversal from the source.

Resolution:
Revised Text:
Actions taken:
February 20, 2013: received issue

Issue 18504: Collection::any() violates precondition if the collection is empty (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Section 11.9.1.4 states that "there must be at least one element fulfilling body, otherwise the result of this IteratorExp is null."  And defines


source->any(iterator|body) = source->select(iterator | body)->asSequence()->first()


However 


let seq:Sequence<T>=source->select(body)->asSequence()
in source->any(body)=seq->at(1)


>From section 11.7.5


 context Sequence::first() : T 
 post: result = self->at(1)


 context Sequence::at(i : Integer) : T 
 pre : i >= 1 and i <= self->size()


If there is no element fulfilling body, then seq is empty and the precondition of Sequence::at does not hold because 1 > seq->size().

Related to: Issue 18125 [OCL 2.4]

Resolution:
Revised Text:
Actions taken:
February 26, 2013: received issue

Issue 18515: Collection::min/max accumulator initialized as self.first() (ocl2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

The accumulator in the definition of Collection::min and Collection::max is initialized as self.first(). 


post: result = self->iterate( elem; acc : T = self.first() | acc.min(elem) )


post: result = self->iterate( elem; acc : T = self.first() | acc.max(elem) )


The accumulator should be initialized as self.asSequence()->first(), because Collection::first() is undefined.

Resolution:
Revised Text:
Actions taken:
March 1, 2013: received issue

Issue 18516: Introduce a Safe Navigation Operator (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

Languages such as Groovy have found it helpful to intrioduce the safe navigation operator ?: so that navigation over null yields null rather than a problem (invalid in OCL).


In OCL it could be a pure syntax sugar:


(x?.y) = (if x == null then null else x.y endif)


or perhaps an additional PropertyCallExp operator

Resolution:
Revised Text:
Actions taken:
March 1, 2013: received issue

Issue 18539: Complete OCL document must be a Package (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Significant
Summary:

In order for a UML model to import some Complete OCL for use in the model's constraints, a Complete OCL document must be a (derived) Package. Any tool can therefore import Complete OCL using its conventional metamodel import syntax; just needs per-tool support.


Complete OCL documents must not conflict. For instance if MM imports COD1 for its own purposes and then your usage imports MM (and COD1) and also COD2, the declarations in COD2 may not introduce anything that requires re-analysis of the OCL expressions in MM or COD1; the only change to MM+COD1 execution may arise through additional derived virtual functions.


Avoiding conflicts requires some strong WFRs.


Once conflicts are avoided, Complete OCL documents can be pre-compiled and loaded in compiled form.

Resolution:
Revised Text:
Actions taken:
March 10, 2013: received issue

Issue 18829: Introduce selectByKind and selectByType operations (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

A very common 'idiom' in OCL expressions is


sources->select(oclIsKindOf(T))->collect(oclAsType(T))->asSet()


to select the sub-set of type T.


This involves four library calls and requires T to be typed twice.


In practice 


sources->select(oclIsKindOf(T)).oclAsType(T)


may save one operation call at the expense of the wrong collection type.


Suggest introduce


sources->selectByKind(T)
sources->selectByType(T)


to simplify this oclIsKindOf/oclIsTypeOf usage.

Resolution:
Revised Text:
Actions taken:
July 21, 2013: received issue