Issues for OCL 2.5 Revision Task Force

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

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

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

Jira Issues

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 ([email protected])  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 ([email protected])  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 6541: Exception of strict evaluation (=) (ocl2-rtf)

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

Author: Thomas Baar ([email protected])  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 ([email protected])  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 ([email protected]),  Rolf Hennicker ([email protected]),  Alexander Knapp ([email protected])  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 ([email protected])  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 ([email protected]),  Burkhart Wolff ([email protected])  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 ([email protected]),  Rolf Hennicker ([email protected]),  Alexander Knapp ([email protected])  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 6557: Introduce a "tuplejoin" operator (ocl2-rtf)

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

Author: Herman Balsters ([email protected])  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 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 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 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 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 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 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 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: received 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 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:
June 10, 2004: received issue
October 16, 2009: closed issue; Duplicate or Merged

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 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 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 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 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 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 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 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 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 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 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 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 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 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 10786: Naming of Constraints in OCL (02) (ocl2-rtf)

Click here for this issue's archive.
Source: Dell Technologies (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: Dell Technologies (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 11056: Provide the list of reflective MOF operations that are available (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:

Is not very clear what are the reflective MOF operations that are available   to QVT operational transformation writers

Resolution: Once OCL resolves outstanding issues regarding reflection as required by the draft OCL 2.5 RFP, the available operations should be obvious
Revised Text:
Actions taken:
May 24, 2007: received issue
April 29, 2014: moved to OCL RTF

Discussion:

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 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 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 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: Model Driven Solutions (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 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 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 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: received 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 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 14576: OCL 2.1 11.7: Clarifying Collection Well-formedness rules (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (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: Model Driven Solutions (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 14591: OCL 2.1 12 Definition Accessibility Semantics (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (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: Model Driven Solutions (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: Model Driven Solutions (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: Model Driven Solutions (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: Model Driven Solutions (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: Model Driven Solutions (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 14598: OCL 2.1 12 Incompleteness (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (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: Model Driven Solutions (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: Model Driven Solutions (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: Model Driven Solutions (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: Model Driven Solutions (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: Model Driven Solutions (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 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 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 14980: OCL 2.1 11.7.3 OrderedSet addition well-formedness rules (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (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 14982: OCL 2.1 11.7.3 Missing OrderedSet::flatten overload (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (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: Model Driven Solutions (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: Model Driven Solutions (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 14986: OCL 2.1 Feature Overloading Semantics are not defined (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (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 15010: Collection::sum is not realisable for empty collection of user defined type (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (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: Model Driven Solutions (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: Model Driven Solutions (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: Model Driven Solutions (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: Model Driven Solutions (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 15156: OCL 2.1 Parametric references (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (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: Model Driven Solutions (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: Model Driven Solutions (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: Model Driven Solutions (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: Model Driven Solutions (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 15232: OCL 2.2 Correction to Issue 9796 for isPre (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (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: Model Driven Solutions (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: received issue

Issue 15234: OCL 2.2 Generalisation of Issue 7341 PathNames (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (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 15249: Why OCL does not have "super" reference? (ocl2-rtf)

Click here for this issue's archive.
Source: NASA (Dr. Maged Elaasar, Maged.E.Elaasar(at)jpl.nasa.gov)
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 15257: OCL 2.2 OclState and oclIsInState (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (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: Model Driven Solutions (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 15357: OCL 2.2 OclState, State, StateExp, StateExpCS, StateValue and StateExpEval (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (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: Model Driven Solutions (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: Dell Technologies (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: Model Driven Solutions (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: Model Driven Solutions (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: Model Driven Solutions (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: Model Driven Solutions (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: Model Driven Solutions (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 15710: OCL 2.2 forAllAt suggestion (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (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: Model Driven Solutions (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 15780: OCL 2.2 Unlimited and Infinity (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (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: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
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: Model Driven Solutions (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 15838: OCL 2.3 max, min iterations (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (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 15920: OCL 2.3.TupleType semantics and AST (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (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 16018: OCL 2.3 : Introduce Lambda functions (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (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: Model Driven Solutions (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: Model Driven Solutions (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 16106: OCL 2.3 - heterogeneous collections cannot be typed (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (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 16126: Issue nnnn: Japan PAS Ballot Comment 3 (ocl2-rtf) (ocl2-rtf)

Click here for this issue's archive.
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.
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 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.
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 https://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 16137: Japan PAS Ballot Comment 14 (ocl2-rtf) - Section 8.3.2 Fig8.3 & AssociationClassCallExp (ocl2-rtf)

Click here for this issue's archive.
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 https://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.
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 https://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.
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 https://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.
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 https://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.
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 16149: Japan PAS Ballot Comment 26 (ocl2-rtf) 10.2 The Values Package, 1st paragraph (ocl2-rtf)

Click here for this issue's archive.
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 https://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.
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 https://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.
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 https://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: Model Driven Solutions (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: Model Driven Solutions (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 16348: OCL 2.3 Collecting elemental collections (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (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: Model Driven Solutions (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: Model Driven Solutions (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: Model Driven Solutions (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

Discussion:

Changing concrete syntax is desirable but out of scope for an RTF.  Disposition: Deferred

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: Model Driven Solutions (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: There is a gaping chasm between UML and OCL with regard to how stereotype names are used. There is no example of any kind in the OCL specification that uses a stereotype. My current thinking is that most of the complexity vanishes if stereotypes are resolved by the metamodel loader so that for the purposes of OCL evaluation, the M2 properties of the stereotype become regular, although static, M1 properties. Prototyping in Eclipse OCL demonstrates that this works and avoids loss of static type information. The semantics of static properties is currently limited to intuitive extrapolation from the existence of the keyword in the concrete syntax. There is a lot of work to do here. Disposition: Deferred
Revised Text:
Actions taken:
December 30, 2011: received issue

Discussion:

Issue 18254: Align OCL bodyExpression and UML bodyCondition (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (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: Model Driven Solutions (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 18516: Introduce a Safe Navigation Operator (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (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: Model Driven Solutions (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 18880: Conflicting String::indexOf postConditions (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

The Issue 17220 clarification that the empty string is a substring at index 1 failed to revise the postcondition that the index of of any string in the empty string is at index 0.      Replace:      post: self.size() = 0 implies result = 0      by      post: self.size() = 0 and s.size() > 0 implies result = 0      and move it to the second postcondition

Resolution:
Revised Text:
Actions taken:
August 24, 2013: received issue

Issue 18882: Unify @pre, ^, ^^, ? as extensibility mechanisms (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Enhancement
Severity: Minor
Summary:

The OCL expression syntax is difficult to extend for other purposes. The @pre postcondition operator, and the ^,^^,? tokens are examples of extension of the core syntax.      Perhaps @pre could be generalized as an instance of an @token{....} suffix which could be parsed as an AnnotationExp for tooling to ignore but support extension for.    Can more arbitrary punctuation such as ^,^^,?,#,% be generalized?

Resolution:
Revised Text:
Actions taken:
August 30, 2013: received issue

Issue 18911: Missing Real::= overload (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Significant
Summary:

Issue 14918 went most of the way to clarifying '=' behaviour.      But the Real::'=' and Real::'<>' overloads were omitted.      Consequently the fix to ensure that 1.0 = 1  evaluates to true when (1.0 <= 1) and (1.0 >= 1) will evaluate true is missing.

Resolution:
Revised Text:
Actions taken:
September 15, 2013: received issue

Issue 18980: OclVoid::oclIsKindOf/oclIsTypeOf should return true/false rather than invalid (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

The Isabelle evolution for Annex A highlight two errors in the OCL 2.4 clarifications.      OclVoid::oclIsKindOf/oclIsTypeOf should return true/false rather than invalid.    ? oclIsKindof true for all types except OclIsInvalid.

Resolution:
Revised Text:
Actions taken:
September 30, 2013: received issue

Issue 18985: Reverse CollectionRange should be empty rather than invalid (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

The clarification of Issue 15836 is too strong.      For an empty collection it is im,portant that      let s = Sequence{} in Sequence{1..s->size()}    is Sequence{}, i.e. the valid indexes of an empty Sequence are empty not invalid.

Resolution:
Revised Text:
Actions taken:
October 3, 2013: received issue

Issue 19020: How does Set distinguish duplicate values? (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

In 11.6.2: "It [Set] contains elements without duplicates."      What is a duplicate?      In 10.2.2.13 SetTypeValue  "All elements belonging to a set value have unique values.  self.element->isUnique(e : Element | e.value)"      >From 11.9.1.3 isUnique, the basis of comparison is <>:  forAll (x, y | (x.iter <> y.iter) implies (x.value <> y.value))      But what is the Element::value to which "<>" is applied. It is far from clear that the semantics of the Element in Section 10 which is completely unrelated to MOF::Element leads to the obvious answer.      Suggest adding the obvious WFR.      context Set  inv: forAll(x | self->count(x) = 1)      (count is already defined using "=")     [And chnage 11.9.1.3 isUnique to use this much more readable formulation.]

Resolution:
Revised Text:
Actions taken:
October 23, 2013: received issue

Issue 19127: Support zero and multiple context invariants (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

A.5.1.5 suggests that an invariant may be specified for many contexts. The Complete OCL syntax does not support this.      Many users like to write grandiose truths:      context X  inv: X.allInstances()->...      These do not use the context and so naively increase the complexity from O(N) to O(N*N).    Suggest allowing such constraints to be context-less constraints provided by the Package rather than a spurious Classifier.

Resolution:
Revised Text:
Actions taken:
November 27, 2013: received issue

Issue 19192: Missing/Poor definition of iterate() (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

The non-normative text defines iterate() and suggests that all iterators may be defined in terms of iterate() and notes that the use of iterate() on Bag/Set is indeterminate.      The normative text omits iterate() and states that all iterators are defined in terms of iterate().      Suggest: Add iterate() to Section 11.       Suggest: explicitly asSequence() all unordered iterate() inputs.    Suggest: retract availability of iterate() on Bag/Set forcing an explicit asSequence().

Resolution:
Revised Text:
Actions taken:
January 18, 2014: received issue

Issue 19210: Append/prepend on OrderedSet does not necessarily increase the collection size (ocl2-rtf)

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

The spec defines the following postcondition for the append/prepend operations on OrderedSet:      result->size() = self->size() + 1    However, if self does already contain the added element, the size does not increase by one since the elements are unique.

Resolution:
Revised Text:
Actions taken:
February 11, 2014: received issue

Issue 19434: Example of collect in terms of iterate is not flattened (ocl2-rtf)

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

The example of collect in terms of iterate given in section section 7.6.6 is not flattened. Actually it is a copy of the definition of collectNested in section 11.9.2.

Resolution:
Revised Text:
Actions taken:
May 26, 2014: received issue

Discussion:

Issue 19460: Error in OCL 2.4 spec (ocl2-rtf)

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

For reference: https://www.omg.org/spec/OCL/2.4/  The concrete syntax for the rule invOrDefCS in section 12.12.6 seems to establish an infinite recursive relation without a terminal rule. Perhaps a question mark is needed, or some clarification?

Resolution:
Revised Text:
Actions taken:
June 11, 2014: received issue

Issue 19510: Invalid algorithm in definitions of sortedBy (ocl2-rtf)

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

The following problems are common to all definitions of sortedBy in 11.9:      Invalid algorithm:  * When the current element is not the first one, but is the     greatest one so far, for example 2 in      Sequence{1,2}->sortedBy(x|x),    then      result->select (item | body (item) > body (iterator))    is empty and calling ->first on it would result in invalid.      Inconsistent use of < and >:  * The text descriptions mention using < operation on the elements,    but the algorithm uses > operator.      Typos:  * The accumulator initialization incorrectly uses : instead of =.  * The source for the iterate expression is missing.  * The closing parenthesis for the iterate expression is missing.  * The operations append and insertAt are called by . operator.        SOLUTION:  * Introduce a new local variable upperBounds, containing elements from the    accumulator that are greater than the current element.  * Swap body (iterator) and body (item).  * Fix typos.      Corrected algorithm for Set (11.9.2) and OrderedSet (11.9.5):      ****************************************  source->sortedBy(iterator | body) =   source->iterate( iterator ; result : OrderedSet(T) = OrderedSet {} |    let upperBounds : OrderedSet(T) =     result->select (item | body (iterator) < body (item) )    in     if upperBounds->isEmpty() then      result->append(iterator)     else      let position : Integer = result->indexOf ( upperBounds->first() )      in       result->insertAt(position, iterator)     endif   )  ****************************************      Corrected algorithm for Sequence (11.9.4) and Bag (11.9.3):      ****************************************  source->sortedBy(iterator | body) =   source->iterate( iterator ; result : Sequence(T) = Sequence {} |    let upperBounds : Sequence(T) =     result->select (item | body (iterator) < body (item) )    in     if upperBounds->isEmpty() then      result->append(iterator)     else      let position : Integer = result->indexOf ( upperBounds->first() )      in       result->insertAt(position, iterator)     endif   )  ****************************************      FURTHER SUGGESTIONS:  * The presented algorithm works only under assumption that indexOf(obj:T)    on Sequence(T) returns the first occurence. This is not mentioned in the    definition of indexOf. If indexOf can return any index, for example:      Sequence{2, 2}->indexOf(2) = 2,    then the above algorithm could insert the element at the wrong place,    for example:      Sequence{2, 2, 1}->sortedBy(x|x) = Sequence{2, 1, 2}  * The algorithm is stable for Sequence and OrderedSet, this fact could be    mentioned in the description, to make it clear that successive    sortedBy iterations can be used to sort by multiple criteria.

Resolution:
Revised Text:
Actions taken:
July 4, 2014: received issue

Issue 19532: indentified (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

Change to identified

Resolution:
Revised Text:
Actions taken:
July 22, 2014: received issue

Issue 19533: Add isInteger/isReal (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

Add isInteger/isReal predicates to avoid need to test invlaid on toInteger/toReal    Add isBoolean/toBoolean/toString

Resolution:
Revised Text:
Actions taken:
July 22, 2014: received issue

Issue 19534: Coolection operations do not allow invalid inputs (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

Add not oclIsInvalid() precondition on all non-Collection inputs.      e.g including(object : T)    pre: not object.oclIsInvalid()

Resolution:
Revised Text:
Actions taken:
July 22, 2014: received issue

Issue 19535: i/r typo (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

In Integer::/ change "r is equal" to "i is equal"

Resolution:
Revised Text:
Actions taken:
July 22, 2014: received issue

Issue 19536: Missing mode precondition (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

To Integer::mod all    pre: i <> 0

Resolution:
Revised Text:
Actions taken:
July 22, 2014: received issue

Issue 19537: Obsolete implicit cast to Bag (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

Descriptions of Collection::InEmpty(), notEmpty() refer to the implicit cast to Bag rather than use of oclAsSet().

Resolution:
Revised Text:
Actions taken:
July 22, 2014: received issue

Issue 19612: Collection{} is Collection(OclVoid){} (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

Issue 12953 considered the problem of the element type of an empty collection and rejected OclVoid (Option 1) because Set{}->including(1) would fail.    This rejection is appropriate when the collection is modified as in Java, but is inappropriate for OCL where a new Collection is created. There is therefore no problem in deciding that the most derived common element type of Set{} (OclVoid) and 1 (Integer) is Integer causing Set(Integer)::including(Integer) to be invoked.

Resolution:
Revised Text:
Actions taken:
September 22, 2014: received issue

Issue 19702: Support zero argument iterations (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

Some iterations are needlessly verbose to use for simple cases.      ->sortedBy(n |n) for a simple self sort could be abbreviated to ->sortedBy()      ->forAll(n | n) for ANDall could be abbreviated to ->forAll()      ->exists(n | n) for ORall could be abbreviated to ->exists()    ->any(true) could be abbreviated by ->any()

Resolution:
Revised Text:
Actions taken:
January 6, 2015: received issue

Issue 19750: Inconsistent OclVoid::oclAsType return (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Significant
Summary:

7.4.6 states: If the actual type of the object, at evaluation time, is not  a subtype of the type to which it is re-typed, then the result of oclAsType is invalid.      7.5.8 states: self.oclAsType(A).p1 -- accesses the p1 property defined in A - this is incompatible with the no-class-change-to-A so A::p1 is not available for null.      But the normative 11.3.2 states: oclAsType(type : Classifier) : T  Evaluates to self.    The OCL 2.4 contribution to 11.3.2 was a typo. It should be "evaluates to invalid".

Resolution:
Revised Text:
Actions taken:
April 21, 2015: received issue

Issue 19820: Indaequate Issue 15836 resultion of negative CollectionRange (ocl2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

Issue 15836 suggests that a negative CollectionRanbge should be invalid even after considering the Sequence{1..size}->forAll idiom.    The idiom clearly requires that a negative range gives an empty range.

Resolution:
Revised Text:
Actions taken:
July 27, 2015: received issue

Issue 19824: oclInState instead of oclIsInState (ocl2-rtf)

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

The name of the predefined property is "oclInState" according to chapter 7.6.9. In chapter 11.3.1 the name "oclIsInState" is used.

Resolution:
Revised Text:
Actions taken:
August 5, 2015: received issue

Issue 19825: StateSpec for oclInState() (ocl2-rtf)

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

Please add that the StateSpec may include the names of Regions.

Resolution:
Revised Text:
Actions taken:
August 5, 2015: received issue

Issue 19865: Wrong color for abstract syntax presentation (ocl2-rtf)

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

The last sentence of the first paragraph on page 37 says "All metaclasses defined as part of the OCL abstract syntax are shown with a light gray background.", but subsequent abstract syntaxs show OLC defined metaclasses in yellow

Resolution:
Revised Text:
Actions taken:
December 3, 2015: received issue