Issues for OCL 2.4 Revision Task Force mailing list

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

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

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

Issue 8917: allInstances (ocl2-rtf)

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

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

Recommendation:

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

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

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

Discussion:

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

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

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

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

 

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

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

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


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

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

Discussion:

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


Disposition:	Closed, no change

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

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

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

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

Discussion:

A simple duplication of issue 8902


Disposition:	See Issue 8902 for disposition

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

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

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

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

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

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

Proposed solution: 

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

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

Discussion:

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

Issue 8982: Circular imports (ocl2-rtf)

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

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

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

Discussion:

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


Disposition: Close, no change

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

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

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


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


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


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


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

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

Discussion:

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

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

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

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

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

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

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

Discussion:

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

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

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

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

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

Discussion:

NavigationCallExp must be the supertype of PropertyCallExp for two reasons:

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

Issue 9796: Section: 7.3.4 (ocl2-rtf)

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

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

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

Discussion:

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

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

Issue 9913: Section: 8.3.5 (ocl2-rtf)

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

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

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

Issue 9914: Section: 7.5.9 (ocl2-rtf)

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

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

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

Discussion:

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

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

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

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

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

Discussion:

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

Issue 10344: Section: 7.4.9 (ocl2-rtf)

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

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

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

Discussion:

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

Issue 10346: Section: 7.8 (ocl2-rtf)

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

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

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

Discussion:

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


Disposition: Close, No Change.

Issue 10430: Section 7.6.3 (ocl2-rtf)

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

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


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

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

Discussion:

Issue 10431: Section 9.2.2 (ocl2-rtf)

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

"The OCL specification puts no restriction on visibility."


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

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

Discussion:

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

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

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

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

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

Discussion:

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

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

Issue 10433: 11.2.3 (ocl2-rtf)

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

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


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

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

Discussion:

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

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

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

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

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

Discussion:

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

Issue 10435: 11.8.1 (ocl2-rtf)

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

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


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

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

Discussion:

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

Issue 10436: 11.2.5 (ocl2-rtf)

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

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


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


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

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

Discussion:

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

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

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

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


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


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

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

Discussion:

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

Issue 10438: 11.7.1 (ocl2-rtf)

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

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

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

Discussion:

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

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

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

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

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

Discussion:

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

Disposition:	Closed, no change

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

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

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



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


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


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


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

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

Discussion:

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

Issue 10921: TypeType (ocl2-rtf)

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

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


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

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

Discussion:

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

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

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

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

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


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


Suggest: 


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

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

Discussion:

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

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

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

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

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


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


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

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

Discussion:

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

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

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

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

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

Discussion:

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

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

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

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

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

Discussion:

Correct, two parenthesis are missing.

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

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

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


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


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


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


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


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



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


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


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


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


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


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


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



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



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

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

Discussion:

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

Disposition:	Closed, no change

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

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

The operator precedence rules in 9.3.2 are identical to the precedence rules in 7.4.7. Both sets are incomplete in that they do not specify the precedence of the 'let' operator. For example, in a UML profile, a constraint on a 'Property' stereotype might be: not self.base_Property.allNamespaces()->exists(oclIsKindOf(Profile) or oclIsKindOf(Stereotype)) implies let prop:Property=self.base_Property in prop.defaultValue->isEmpty() To parse properly (with RSA 7.0.0.2), this constraint must instead be written as: not self.base_Property.allNamespaces()->exists(oclIsKindOf(Profile) or oclIsKindOf(Stereotype)) implies (let prop:Property=self.base_Property in prop.defaultValue->isEmpty()) This suggests that the 'let' operator has a lower precedence than that of the 'implies' operator. Of course, there is an alternative way to write this constraint that does not expose this issue: let prop:Property=self.base_Property in not prop.allNamespaces()->exists(oclIsKindOf(Profile) or oclIsKindOf(Stereotype)) implies prop.defaultValue->isEmpty() The suggestion is to revise 7.4.7 and 9.3.2 to account for *all* keywords in 7.4.9. The keywords defined in 7.4.9 but not accounted for in 7.4.7 or in 9.3.2 are: - attr - context - def - endpackage - in - inv - let - oper - package - post - pre The keywords referenced in 7.4.7 or in 9.3.2 that are *not* defined in 7.4.9 are: - @pre Nicolas F. Rouquette Principal Computer Scientist http://www.jpl.nasa.gov Jet Propulsion Laboratory, Caltech M/S 301-270 Pasadena, CA 91109, USA phone: +1-818-354-9600 fax: +1-818-393-4100 e-mail: nicolas.f.rouquette@jpl.nasa.gov

Resolution:
Revised Text: Update sections 7.4.7 and 9.3.2 to insert the let-in expression at the bottom of the precedence scale: 1. ... 2.�implies� 3.�let-in�
Actions taken:
June 5, 2007: received issue
October 16, 2009: closed issue

Discussion:

Most of the keywords listed by the submitter are not used in the syntax of expressions, but of constraint context declarations.  Only the �let� and �in� keywords need to be addressed.

Issue 12378: Section 8.2 InvalidType (ocl2-rtf)

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

For the InvalidType it is stated that: "The only instance of InvalidType is Invalid, which is further defined in the standard library. Furthermore Invalid has exactly one runtime instance called OclInvalid." It should read: "The only instance of InvalidType is OclInvalid, which is further defined in the standard library. Furthermore OclInvalid has exactly one runtime instance called invalid." because this is in line with ch. 11.2.4, p. 138:"It [OclInvalid] has one single instance called invalid. [...] OclInvalid is itself an instance of the metatype InvalidType

Resolution:
Revised Text: Update the description in Section 8.2 The Types Package InvalidType represents a type that conforms to all types except the VoidType type. The only instance of InvalidType is OclInvalid, which is further defined in the standard library. Furthermore OclInvalid has exactly one runtime instance identified as invalid.
Actions taken:
April 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

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

Issue 12419: CollectionType and CollectionKind (ocl2-rtf)

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

The abstractness of CollectionType and corresponding existence of the Collection CollectionKind is inconsistent:
--
9.3 collectionTypeCS synthesized attributes, page 79, contains:


kind = CollectionKind::Collection implies collectionTypeCS.ast.oclIsKindOf(CollectionType)


using CollectionKind::Collection.
--
8.3.5 CollectionKind, page 48, Collection is not one of the enumeration values.
--
11.6.1, page 144, specifies that Collection is an instance of CollectionType
requiring Collection to not be abstract.
--
8.2 CollectionType, page 34, CollectionType is identified as an abstract class.
--
An expression like the following is valid:


  context Package
  def getClasses() : Set(Class) =
    let c : Collection(Type) = self.ownedType in
      c->select(oclIsKindOf(Class))->asSet()


and demonstrates the need for a concrete CollectionType.
--
Recommendation:


Collection should not be abstract; change Fig 8.1, 8.2 CollectionType text.
CollectionKind requires a Collection value; change Fig 8.7, 8.3.5 CollectionKind.

Resolution:
Revised Text: Update Figures 8.1 and 13.1 to remove the italic style from CollectionType. Update Section 8.2 description of the CollectionType metaclass to read thus: CollectionType describes a list of elements of a particular given type. CollectionType is a concrete metaclass whose instances are the family of abstract Collection(T) data types. Its subclasses are SetType, OrderedSetType, SequenceType, and BagType, whose instances are the concrete Set(T), OrderedSet(T), Sequence(T), and Bag(T), data types, respectively. Part of every collection type is the declaration of the type of its elements (i.e., a collection type is parameterized with an element type). In the metamodel, this is shown as an association from CollectionType to Classifier. Note that there is no restriction on the element type of a collection type. This means in particular that a collection type may be parameterized with other collection types allowing collections to be nested arbitrarily deep. Update Figures 8.7 and 13.8 to add Collection to the CollectionKind enumeration. Update section 8.3.5 Literal Expressions: CollectionKind The CollectionKind enumeration lists the kinds of collections. Its literals are Collection, Set, OrderedSet, Bag, and Sequence.
Actions taken:
April 19, 2008: received issue
October 16, 2009: closed issue

Discussion:

There is no inconsistency in CollectionType being concrete while Collection(T) is abstract; they are defined on different metalevels.  Indeed, the Collection(T) type would not exist if CollectionType were abstract, as it would then not be permitted to have instances

Issue 12438: last line on page 28 (ocl2-rtf)

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

The last line on page 28 is an example in Java-like code that is supposed to show the accumulation of values into a Bag. The line currently is acc = <expression-with-elem-and-acc> Since such an assignment would not add to the Bag, but more likely produce a compile error in Java, I would think use of the common method name "add" would be more appropriate: acc.add(<expression-with-elem-and-acc>);

Resolution:
Revised Text: n Section 7.6.5, at the en of page 28, replace: acc = <expression-with-elem-and-acc> by acc.add(<expression-with-elem-and-acc>
Actions taken:
May 13, 2008: received issue
October 16, 2009: closed issue

Issue 12439: Section: A/1.1.1 Types (ocl2-rtf)

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

The following grammatically incorrect sentence is present in the document: All type domains include an undefined value that allows to operate with unknown or �null� values. This could be corrected in various ways, a couple of which would be: All type domains include an undefined value that allows one to operate with unknown or �null� values. or All type domains include an undefined value that allows operations with unknown or �null� values.

Resolution:
Revised Text: Replace " All type domains include an undefined value that allows to operate with unknown or �null� values" by 'All type domains include an invalid and a null value that allows one to operate respectively with unknown and �null� values.
Actions taken:
May 13, 2008: received issue
October 16, 2009: closed issue

Discussion:

The rresolution needs to take into account the fact that Null and Invalid are introduced in OCL2 replacing undefined.

Issue 12440: Section: A/1.1.5 Associations (ocl2-rtf)

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

The next to last line of Definition A.4 begins, "that associates (sa) = <oc, c>." I think this should read instead, "that associates (sa) = <c, c>." If I am mistaken, then a note to remind the reader what "oc" means would be helpful, as would a note describing why the classes are not the same.

Resolution:
Revised Text: In Section A/1.1.5 Associations replace " that associates (sa) = <oc, c>." by " that associates (sa) = <c, c>."
Actions taken:
May 13, 2008: received issue
October 16, 2009: closed issue

Issue 12441: Section: A/1.1.5 Associations -- missing word (ocl2-rtf)

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

Between the definitions of "participating" and "navends" is a sentence that, "The following function navends give ...." The s is missing on "gives". It should instead read, "The following function navends gives ...."

Resolution:
Revised Text: .In Section A/1.1.5 Associations, replace "The following function navends give ...." by "The following function navends gives ...."
Actions taken:
May 13, 2008: received issue
October 16, 2009: closed issue

Issue 12442: Section: A/1.1.5 Associations (ocl2-rtf)

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

In the definition of "navends" the symbol for "and", which was a nice looking capital lambda in previous definitions, is here a more traditional, at least in my mind, "and" sign. Consistency would be nice

Resolution:
Revised Text: In Section A/1.1.5, replace the uppercase lambda in the example "participating" by "and" .
Actions taken:
May 13, 2008: received issue
October 16, 2009: closed issue

Issue 12443: Section: A/1.1.6 Generalization (ocl2-rtf)

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

At the top of page 182 there are 3 definitions, all of which have the index domain, i.e. C' an element of parents(c), in the wrong place horizontally. In the first two it appears to be associated with the small union symbol, rather than with the large one as it should be. In the third it seems not to be associated with anything in particular. Additionally, in the first line on the page there is an extraneous underscore in the name of the object of the first definition.

Resolution:
Revised Text: see page 166 of ptc/2009-05-04
Actions taken:
May 13, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex to Framemaker conversion. Mathematical symbols were often badly converted. The correct text is in the original from annex A of ptc/03-10-14.

Issue 12444: Section: A/1.1.6 Generalization - editorial issues (ocl2-rtf)

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

In WF-1 there is an "is an element of" sign missing just before the "ATT" in the first line. In WF-2, at a minimum, the first small omega should have a t-sub-1 a bit after it so that the sameness of arguments from t-sub-1 through t-sub-n is clear for both small omegas. Also the second colon is on the wrong side of the small omega. On the other hand, I'm not sure why you don't write it in the same form as WF-1, since it's a similar statement. I hope you can interpret my attempts to get by without sub and superscripts. Since the reader has already waded through WF-1, wouldn't it be more useful like this? ? (? : tc x t1 x �x tn ? t, ?' : tc' x t1 x �x tn ? t' ? OP*c) : (? = ?' => tc = tc' ? t = t')

Resolution:
Revised Text: In Section A/1.1.6 Generalization, replace the actual enumeration starting with "1. Attributes �" by: SEE page 168 of ptc/2009-05-04
Actions taken:
May 13, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex to Framemaker conversion. Mathematical symbols were often badly converted. The correct text is in the original from annex A of ptc/03-10-14.

Issue 12445: Section: A/1.2.1 Objects (ocl2-rtf)

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

In Definition A.10 Object Identifiers, part ii, you have the domain of a class c defined as: ICLASS(c') = U{oid(c) | c' ? CLASS ^ c' "gr<" c}. where I've used "gr<" for the generalization relation. I see 4 things that ought to be changed: 1. The initial c' should obviously be a c. 2. The oid(c) should be oid(c') 3. We have still another symbol for "and" 4. There's an extraneous newline before the final c.

Resolution:
Revised Text: see page 169 of ptc/2009-05-04
Actions taken:
May 13, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex to Framemaker conversion. Mathematical symbols were often badly converted. The correct text is in the original from annex A of ptc/03-10-14.

Issue 12446: Section: A/1.2.4 System State (ocl2-rtf)

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

Definition 1.12 (System State) ends with "(the function pi(l) projects the ith component of a tuple or list l, whereas the function pi(l) projects all but the ith component):" Obviously the same notation can't mean opposite things, but what was intended here I don't yet know. Perhaps I will as I read on, but I thought I'd report this typo now so I don't forget.

Resolution:
Revised Text: see page 170 of ptc/2009-05-04
Actions taken:
May 13, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex to Framemaker conversion. Mathematical symbols were often badly converted. The correct text is in the original from annex A of ptc/03-10-14.

Issue 12447: Section: A/2.2 Common Operations on All Types (ocl2-rtf)

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

This is another omission of the word "one", making the sentence grammatically incorrect. It is also useful to have an operation that allows to check whether an arbitrary value is well defined or undefined. should be "... allows one to ...." or "... allows the checking of whether ...."

Resolution:
Revised Text: In Section A/2.2, replace "allows to check�" by "... allows one to check....".
Actions taken:
May 13, 2008: received issue
October 16, 2009: closed issue

Issue 12448: section 7.4.6 (p. 12) (ocl2-rtf)

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

In section 7.4.6 (p. 12) it is said "An object can only be re-typed to one of its subtypes; ... If the actual type of the object is not a subtype of the type to which it is re-typed, the expression is undefined" While in section 7.5.8 (p. 19) it is said Whenever we have a class B as a subtype of class A, and a property p1 of both A and B, we can write: context B inv: self.oclAsType(A).p1 -- accesses the p1 property defined in A self.p1 -- accesses the p1 property defined in B and thus an example is shown where an object is retyped to its supertype. Both sections 7.4.6 and 7.5.8 should be joined into one. See slide 32 in my handouts to see a possible abstract of the joined section.

Resolution: The problem is fixed by resolution of issue 7341. Casting and accessing properties from a supertype are two different things. Disposition: See Issue 7341 for disposition
Revised Text:
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

The problem is fixed by resolution of issue 7341. Casting and accessing properties from a supertype are two different things.


Disposition:	See Issue 7341 for disposition

Issue 12449: no explanations about how to manipulate optional and multivalued attributes (ocl2-rtf)

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

There are no explanations about how to manipulate optional and multivalued attributes. On the other hand optional and multivalued associations are discussed in detail. For example, while I can use context Person inv: self.job->notEmpty() implies ... to test "whether there is an object or not when navigating the association", I do not know how do a similar test for optional attributes. Is it context Person inv: self.maidenName <> `' implies ... or context Person inv: self.maidenName -> notEmpty() implies ... ?

Resolution:
Revised Text:
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

Associations are attributes.  No further information is required.
Disposition:	Closed, no change

Issue 12450: The Tuple constructor is problematic (ocl2-rtf)

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

The Tuple constructor is problematic. It is not a first-class citizen in the specifications. It appears in many parts but it is not formally introduced.

Resolution:
Revised Text:
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

The discussion of tuple literal expressions in Section 7.5.15 Tuples is quite thorough.  The description of the abstract syntax of the TupleLiteralExp in Section 8.3.5 is terse but complete, and the concrete syntax of tuple literals in Section 9.3 is also complete.
Disposition:	Closed, no change

Issue 12451: OrderedSet collection (ocl2-rtf)

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

The OrderedSet collection is a later adjunction with respect to previous versions of OCL. However, it has not been systematically introduced in all relevant places. As one example among many, conformance rules in Table 7.3 (p.12) do not include OrderedSet. Also, the semantics defined in Appendix A should be extended to include OrderedSet. By the way, there is no place where the difference between OrderedSet and Sequence is discussed. From my understanding, they are much like the same concept. If it is not the case, the differences must be explicitly stated.

Resolution:
Revised Text: In the table 7.3 add a row between Bag(T1) and Integer with the following content: OrderedSet(T1) | Collection(T2) | if T1 conforms to T2
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

Various issue resolution solve the problem mentioned by the reporter. The table 7.3 was not yet completed. This resolution solves that. 
Regarding the difference between OrderedSet and Sequence it is very clear in the types section.

Issue 12454: The constraint [1] on the TupleLiteralPart metaclass is overconstrained (ocl2-rtf)

Click here for this issue's archive.
Source: Zeligsoft, Inc. (Mr. Christian W. Damus, nobody)
Nature: Revision
Severity: Significant
Summary:

The constraint [1] on the TupleLiteralPart metaclass is overconstrained. It requires that the type of the value of a tuple literal part be identical to the corresponding attribute of the tuple type. However, the value type should only be required to conform to the attribute type because tuple literals may optionally specify the part types (in the same fashion as variable declarations). Thus, a more appropriate formulation of this constraint would be: context TupleLiteralPart inv: attribute.type.conformsTo(value.type )

Resolution:
Revised Text: In Page 55, Section 8.3.7 Replace [1]The type of the attribute is the type of the value expression. context TupleLiteralPart inv: attribute.type = value.type by: [1]The type of the attribute conforms to the type of the value expression. context TupleLiteralPart inv: attribute.type.conformsTo(value.type)
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Issue 12457: Section: A/2.3 Enumeration Types (ocl2-rtf)

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

This may be simply my misunderstanding of what is intended. In the final sentence before Definition A.18 (Semantics of Enumeration Types), the word "interpreted" seems inappropriate. "Defined" is often used in such sentences is mathematics. I just wanted to draw attention to this in case it is a mistake. If not then my apologies

Resolution: issue withdrawn by submitter
Revised Text:
Actions taken:
May 14, 2008: received issue
May 14, 2008: closed issue

Issue 12458: Section: A/2.3 Enumeration Types -- editorial (ocl2-rtf)

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

The last sentence of the page is missing the word "one" or, alternately, proper forms of the verbs "to follow" and "to retrieve". A correct form of this sentence would be, "Navigation operations: An object may be connected to other objects via association links. A navigation expression allows one to follow these links and to retrieve connected objects."

Resolution:
Revised Text: In Section A.2.4.1 Operations, Replace "An object may be connected to other objects via association links. A navigation expression allows to follow these links and to retrieve connected objects." By " An object may be connected to other objects via association links. A navigation expression allows one to follow these links and to retrieve connected objects."
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

Issue 12459: Section: Definition A.23 (Semantics of Navigation Operations) (ocl2-rtf)

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

Maybe I misunderstand, but it seems to me that L(as)(ci), as defined, has some problems: 1. "(c1, . . . , c i, . . . , c j , . . . , c n )" is undefined in that one doesn't know what it is, and 2. c is undefined in "sCLASS(c)". It seems to me that what you want is "L(as)(ci) = {cj | i ? j ? (c1, . . . , ci, . . . , cj , . . . , cn ) ? I-sub-ASSOC(as)}" - where the characters following the c's are subscripts and each such combination should be underlined to show that it is an object, - and where I-sub-ASSOC(as) is an italic I with a subscripted "ASSOC(as)".

Resolution:
Revised Text: see page 179 of ptc/2009-05-04
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex to Framemaker conversion. Mathematical symbols were often badly converted. The correct text is in the original from annex A of ptc/03-10-14..

Issue 12460: Section: A.2.5.2 Definition A.24 (Type Expressions) (ocl2-rtf)

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

This may not have been a problem with earlier versions of Adobe Acrobat/Reader but in looking at this section I see two typographical representations of "T-hat". The first two occurances are the letter T followed by a small circumflex substript. Subsequent occurances are a large circumflex followed by the letter T. It would be nice if this were fixed to be consistent, and even nicer if the circumflex could be placed over the T, as I imagine was intended.

Resolution:
Revised Text: see page 180 of ptc/2009-05-04
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex to Framemaker conversion. Mathematical symbols were often badly converted. The correct text is in the original from annex A of ptc/03-10-14.

Issue 12461: Section: A.2.5.5 Collection Operations (ocl2-rtf)

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

The 5th word of this section is "of" but was probably meant to be "on". Also, in Table A.3 in this section the entry in the second row, third column is pretty much unreadable because there are so many symbols written on top of each other. I checked this with Internet Explorer as well as Firefox, in case they affected Adobe Acrobat, but the entry looked equally bad in both.

Resolution:
Revised Text: see pages 181-182 of ptc/2009-05-04
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex to Framemaker conversion. Mathematical symbols were often badly converted. The correct text is in the original from annex A of ptc/03-10-14.

Issue 12464: Section: A/2.5.5 Collection Operations - just before table A.3 (ocl2-rtf)

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

Just before Table A.3, is a sentence, "For this purpose, C, C, C2 ...." The second "C" should have a subscript "1" and the "C2" should have the 2 as a subscript.

Resolution:
Revised Text:
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

Disposition:	See Issue 12463 for disposition

Issue 12469: A.2.5.5 Collection Operations (ocl2-rtf)

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

In the paragraph under table A.3, toward the end, it says, "... count : Set(t) _ t ! Integer ...." These are the wrong symbols, of course. The underscore should be a cross and the ! should be an arrow. Also, just below this is the definition of I(count). This contains a 2 that should be a 0.

Resolution: Disposition: See Issue 12463 for disposition
Revised Text:
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Issue 12470: There are two instances of missing and misplaced parentheses (ocl2-rtf)

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

There are two instances of missing and misplaced parentheses. One is near the bottom of page 195 in the definition of I(count). The line begins, "I(count : Bag)(t) x t ? Integer)". That last closing paren does not match anything. I believe the line should instead begin "(I(count) : Bag(t) x t ? Integer) The other is at the top of page 196. It is currently "I(count : Collection)(t) x t ? Integer)(c,v)" and, I believe, should be "(I(count) : Collection(t) x t ? Integer)(c,v)"

Resolution: Disposition: See Issue 12463 for disposition
Revised Text:
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Issue 12471: Section: A.2.5.6 Set Operations (ocl2-rtf)

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

The second sentence of this section ends, "... B is a value of type t.". It should say "... B is a value of type Bag(t).

Resolution:
Revised Text: Replace: Operations on sets include the operations listed in Table A.3. These are inherited from Collection(t). Operations which are specific to sets are shown in Table A.4 where S, S1, S2 are values of type Set(t), B is a value of type t. By: Operations on sets include the operations listed in Table A.3. These are inherited from Collection(t). Operations which are specific to sets are shown in Table A.4 where S, S1, S2 are values of type Set(t), B is a value of type Bag(t) and v is a value of type t.
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

The original text of Annex A (ptc/03-10-14) was left unchanged by the FTF. However some editorial copy/paste errors were introduced when moving from latex to framemaker. In the case of this issue this concerns the description text (not only the math symbols).

Issue 12472: Section: A.2.5.6 Set Operations Table A.4 (ocl2-rtf)

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

Table A.4 has several rows in the Semantics column where a "union" symbol is used where an "intersection" symbol should have been used. These are rows 3, 4, 5, and 6. Table A.5 of section A.2.5.7 has the same problem in rows 3 and 4.

Resolution:
Revised Text: see page 187 of ptc/2009-05-04
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Issue 12473: Section: A.2.5.8 Sequence Operations (ocl2-rtf)

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

There is one error in Table A.6 in the semantics column for the operation "first". The index should be 1, not i.

Resolution:
Revised Text: In Table A.6, in the semantics column for the operation first, replace the index so that it is 1 instead of i.
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Issue 12474: Section: A.3.1.1 Syntax of Expressions (ocl2-rtf)

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

Definition A.29 (Syntax of Expressions), part iii, b ends with, "and e2 to en the arguments." Here the 2 is a subscript as it should be but the "n" in "en" should also be a subscript and isn't.

Resolution:
Revised Text: see pages 189 - 191 of ptc/2009-05-04
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex  to Framemaker conversion. The correct text is in the original annex ptc/03-10-14. .

Issue 12475: Section: A.3.1.1 Syntax of Expressions (ocl2-rtf)

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

Definition A.29 (Syntax of Expressions), part v, appears to have several problems: 1. The symbol used for generalization is not what has always been used previously, see the two previous symbols in Definition A.10 part ii and in section A.1.2.2 just after it. 2. the first expression after the word "then", namely "(e asType t�) ? Exprt�" lacks a comma after it to separate it from the following expression. 3. I'm puzzled by the restrictions that t and t' must be related one way on the other. The restriction isn't strong enough to keep (e asType t�) from being undefined and seems unneeded for isTypeOf and isKindOf. A note here about this might help the reader. It would sure help me.

Resolution: Disposition: See issue 12474 for disposition
Revised Text:
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Issue 12476: Section: A.3.1.1 Syntax of Expressions (Definition A.29) (ocl2-rtf)

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

Definition A.29 (Syntax of Expressions), part vi reads it part, "... v1 ? Vart1, v2 ? Vart2, and ...." The first comma is a subscript along with the "t1" before it, the second one, that follows the "t2" subscript, isn't. Neither should be.

Resolution:
Revised Text:
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex to Framemaker conversion. Mathematical symbols were often badly converted. The correct text is in the original from annex A of ptc/03-10-14. .


Disposition:	See issue 12474 for disposition

Issue 12477: Syntax of Expressions (second sentence after Definition A..29) (ocl2-rtf)

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

The second sentence after Definition A.29 is "For all t� < t: if e ? Exprt� then e ? Exprt� ." The last prime should be removed.

Resolution:
Revised Text:
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex to Framemaker conversion. Mathematical symbols were often badly converted. The correct text is in the original from annex A of ptc/03-10-14. .


Disposition:	See issue 12474 for disposition

Issue 12478: Section: A.2.6 Special Types (ocl2-rtf)

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

The third bullet ends, "... as ? is an instance of every type." I don't know if the ? stands for OclAny, which isn't a member of the collection classes and so unlikely, or if ? is meant rather than ?. So I think this is an error.

Resolution:
Revised Text: see pages195-196 of ptc/2009-05-04
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex to Framemaker conversion. Mathematical symbols were often badly converted. The correct text is in the original from annex A of ptc/03-10-14. .

Issue 12479: Section: A.2.6.1 Definition A.26 (Special Types) (ocl2-rtf)

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

At the very end if this section it says "I(undefined) = ?." Shouldn't that be "I(undefined) = {?}."? Definition A.14 says the semantics maps each type to a set.

Resolution:
Revised Text:
Actions taken:
May 14, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex to Framemaker conversion. Mathematical symbols were often badly converted. The correct text is in the original from annex A of ptc/03-10-14. .

Disposition:	See Issue 2478 for disposition

Issue 12484: Section 8.2.1 Type Conformance on page 37 (ocl2-rtf)

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

Section 8.2.1 Type Conformance on page 37 [1] Invalid conforms to all other types. context InvalidType inv: Classifier.allInstances()->forAll (c | self.conformsTo (c)) on page 38 [1] Void conforms to all other types. context VoidType inv: Classifier.allinstances()->forAll(c | self.conformsTo(c)) on page 37 [6] The Conforms operation on Types is anti-symmetric context Classifier inv: Classifier.allInstances()-> forAll(12,t2 | t1.conformsTo(t2) and t2.conformsTo(t1) implies t1 = t2) The first invariant yields Classifier.allInstances()->forAll (c | OclInvalid.conformsTo (c)) and thus OclInvalid.conformsTo (OclVoid) The second invariant yields Classifier.allInstances()->forAll (c | OclVoid.conformsTo (c)) and thus OclVoid.conformsTo (OclInvalid) Now the third invariant implies: OclInvalid = OclVoid

Resolution:
Revised Text: Update Section 8.2.1 Type Conformance as follows: InvalidType [1] OclInvalid conforms to all other types except OclVoid. context InvalidType inv: Classifier.allInstances()->forAll (c | not c.oclIsTypeOf(OclVoid) implies self.conformsTo (c)) VoidType [1] OclVoid conforms to all other types except OclInvalid. context VoidType inv: Classifier.allInstances()->forAll (c | not c.oclIsTypeOf(OclInvalid) implies self.conformsTo (c))
Actions taken:
May 15, 2008: received issue
October 16, 2009: closed issue

Discussion:

As in the proposed resolutions of Issues 10433 and 10434, OclVoid and OclInvalid cannot both be the bottom of a lattice-structured type system.  It is better that OclVoid and OclInvalid be defined as conforming to all other types excepting one another.

Issue 12485: Section 8.2 page 35 InvalidType (ocl2-rtf)

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

InvalidType represents a type that conforms to all types. The only instance of InvalidType is Invalid, which is further defined in the standard library. Furthermore Invalid has exactly one runtime instance called OclInvalid. should be replaced by InvalidType InvalidType represents a type that conforms to all types. The only instance of InvalidType is OclInvalid, which is further defined in the standard library. Furthermore OclInvalid has exactly one runtime instance called invalid. This would follow the naming conventions and be in line with the notation for VoidType, OclVoid, null.

Resolution: Disposition: See issue 12378 for disposition
Revised Text:
Actions taken:
May 15, 2008: received issue
October 16, 2009: closed issue

Discussion:

Disposition:	See issue 12378  for disposition

Issue 12486: Section: A.2.7 Type Hierarchy (ocl2-rtf)

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

The first two sentences of Definition A.27 (Type Hierarchy) seem to have errors in them. The relation "less than or equal" seems to be represented by an underscore in the first sentence. In the second sentence 2 is used where the "is an element of" symbol was intended, 0 is used where a prime mark is intended, and c simply follows t and t0 (t prime) rather than being a subscript as intended.

Resolution: Replace the text of Section A.2.7 Type Hierarchy by the following text:
Revised Text: see pages 198 - 199 of ptc/2009-05-04
Actions taken:
May 15, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex to Framemaker conversion. Mathematical symbols were often badly converted. The correct text is in the original from annex A of ptc/03-10-14. .

Issue 12487: Section: A.3.1.1 Syntax of Expressions (ocl2-rtf)

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

Definition A.29 (Syntax of Expressions)part iii, (b) ends, "...and e2 to en the arguments." The n in "en" should be a subscript but is not.

Resolution:
Revised Text:
Actions taken:
May 15, 2008: received issue
October 16, 2009: closed issue

Discussion:

Disposition:	See issue 12474 for disposition

Issue 12488: Section: A.3.1.2 Semantics of Expressions (ocl2-rtf)

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

Some problems with Definition A.30: 1. In the second sentence of Definition A.30 (Semantics of Expressions) it says, "I[[ e ]] : Env ? I(t)" but it seems instead that "I[[ e ]] : Exprt ? (Env ? I(t)). 2. It appears that r, which is not defined anywhere, is really supposed to be p. p, which is defined, only appears in part iv and it appears to be r there. 3. Also, it's confusing to use w in parts iii and iv since small omega (or script w maybe) is used previously. Further clarity would be added by putting empty parenthenes after omega in part iii to emphasize the fact that there are no arguments

Resolution:
Revised Text: see pages 201 - 204 of ptc/2009-05-04
Actions taken:
May 15, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex to Framemaker conversion. Mathematical symbols were often badly converted. The correct text is in the original from annex A of ptc/03-10-14. .

Issue 12489: Section: A.3.1.2 Semantics of Expressions, Definition A.30 part ii (ocl2-rtf)

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

Definition A.30, part ii says "I[[let v = e1 in e2]](r) = I[[e2]](s, �{v / I[[e1]](r)})." Maybe the problem is my ignorance of the meaning of the / in that expression as well as the meaning of the notation "�{...}". I would have expected instead something like, "... = I[[e2]](s, � U {v = I[[e1]](r)})."

Resolution: Disposition: See issue 12488 for disposition
Revised Text:
Actions taken:
May 15, 2008: received issue
October 16, 2009: closed issue

Issue 12490: Section: A.2.5.8 Sequence Operations (ocl2-rtf)

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

In the flattening expressions there are the expressions "C1 fg" and "Bag fg". These seem to stand for the creation of a new, empty collection and bag respectively. If these expressions are what was intended it would be nice to have a note explaining what they mean. I wasn't able to find any explanations or previous use of "fg".

Resolution: The "fg" (in both occurrences) must be replaced by "{}" (a pair of curly braces).
Revised Text: In Section A.2.5.9 Flattening of Collections, after Table A-7 replace occurrences of "fg" by "{}" (a pair of curly braces).
Actions taken:
May 15, 2008: received issue
October 16, 2009: closed issue

Issue 12491: Section: A.3.1.2 Semantics of Expressions (ocl2-rtf)

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

It would be nice to have a definition of �{x / y) in association with Definition A.30. Maybe it's defined elsewhere, but I don't see it. From what's written in this section, including the explanation of iteration on page 205 and 206, I get only a vague idea. P.S. So realizing now that this is not a typo, my revision request two previous to this (if I've counted correctly) should be ignored. That was the one about part ii of Definition A.30.

Resolution: The notation "\" is the standard notation for substitution (e.g., see Winskel's book on formal semantics). Thus, there seems to be no need to add an explanation in the standard. Disposition: Closed, no change
Revised Text:
Actions taken:
May 15, 2008: received issue
October 16, 2009: closed issue

Issue 12493: Section: A.3.2.2 Syntax and Semantics of Postconditions (ocl2-rtf)

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

In the paragraph before Definition A.32 you will find, "An environment p = (s, � is a pair ...." The closing paren. after � is missing

Resolution:
Revised Text: see pages 208 - 210 of ptc/2009-05-04
Actions taken:
May 15, 2008: received issue
October 16, 2009: closed issue

Discussion:

Problems were due to a semi-automatic Latex to Framemaker conversion. Mathematical symbols were often badly converted. The correct text is in the original from annex A of ptc/03-10-14. The parenthesis problem reported here is just one of the problems that are in this section.

Issue 12582: OCL 2.0 8.2 Collection Type packaging (ocl2-rtf)

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

[Pending a resolution of Issue 10946]


In order to use a collection type, it is is necessary to define that
type and provide some container for it. OCL provides no guidance on
what that container should be, or upon what the relative semantics of
A::Set(E) is with respect to B::Set(E).


QVT 1.0 has defined all CollectionType(ElementType) to be the same type
regardless of the accidental package used for their containment.


OCL should adopt the QVT definition (even if 10946 is adopted).

Resolution: Resolution of issue 9171 contains an statement saying that collection instances may be in different containers and still represent the same type. Disposition: See issue 9171 for disposition
Revised Text: In the preamble of Section 8.2, after sentence " Conceptually all these types do exist, but such a type should be (lazily) instantiated by a tool, whenever it is needed in an expression. " add the sentence: For convenience an instance representing a collection type or a tuple type may be replicated in different namespaces (such as in a top-level package or within the expression referencing it) , however they represent semantically the same type.
Actions taken:
July 19, 2008: received issue
October 16, 2009: closed issue

Discussion:

A sentence is needed to state that collection types can be replicated in different namespaces and still represent the same type. This is in line with 10946 resolution.

Issue 12943: OCL 2.0: CollectionType constraint for invalid elements is incorrect (ocl2-rtf)

Click here for this issue's archive.
Source: Zeligsoft, Inc. (Mr. Christian W. Damus, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

The second constraint on CollectionType in Section 8.2.2 does not make  
sense.  The instances of CollectionType are not collections, but the  
types of collections.  Thus, a collection type does not have elements  
to be iterated.  This constraint should be struck from Section 8.2.2:


[1] A collection cannot contain OclInvalid values.
        context CollectionType
        inv: self->forAll(not oclIsInvalid())


and replaced by a new invariant constraint in Section 11.7.1  
�Collection� (which currently has no well-formedness rules):


[1] A collection cannot contain OclInvalid values.
        context Collection
        inv: self->forAll(not oclIsInvalid())

Resolution: As OCL does not permit the invalid value in a collection (as opposed to the null value), it should be made explicit that the evaluation of collection literals containing invalid results in invalid. The CollectionType constraint in Section 8.2.2 attempts to express this, but is incorrect because it is defined on the wrong meta-level (on CollectionType instead of Collection).
Revised Text: Strike the second constraint on CollectionType in Section 8.2.2 �Well-formedness Rules for the Types Package� [1] A collection cannot contain OclInvalid values. context CollectionType inv: self->forAll(not oclIsInvalid()) Add an invariant constraint to Section 11.7.1 �Collection� [1] A collection cannot contain OclInvalid values. context Collection inv: self->forAll(not oclIsInvalid())
Actions taken:
October 9, 2008: received issue
October 16, 2009: closed issue

Discussion:

Issue 12944: Type of a type expression (ocl2-rtf)

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

In the TypeExp definition (within section 8.3) there is no indication of what is the 
type returned by a type expression. Is it the generic object representing all types 
(oclType) or the referred type itself? 
We guess it is the referred type itself, but this need to be explicitly stated.

Resolution: Disposition: See issue 9171 for disposition
Revised Text:
Actions taken:
October 10, 2008: received issue
October 16, 2009: closed issue

Issue 12945: Missing definition of of iterators for OrderedSets (ocl2-rtf)

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

Summary:Since the iterators are redefined for each concrete collection  type 
We would expect a "11.9.5 OrderedSet" section. 
Moreover, when defining nestedCollect for OrderedSet we should expect the type 
to be a Sequence (in constrast to  Set::nestedCollect which type is a Bag).

Resolution: The missing operations are added. Notice that the list of operations is the union of those supported by sequences and those supported by sets.
Revised Text: The missing operations are added. Notice that the list of operations is the union of those supported by sequences and those supported by sets. Revised Text: Add a new section "11.9.5 OrderedSet" with the following content: The standard iterator expressions with source of type OrderedSet(T) are: select (expression : OclExpression) : OrderedSet(T) The ordered set of the source ordered set for which body is true. source->select(iterator | body) = source->iterate(iterator; result : OrderedSet(T) = OrderedSet{} | if body then result->including(iterator) else result endif) select may have at most one iterator variable. reject (expression : OclExpression) : OrderedSet(T) The ordered set of the source ordered set for which body is false. source->reject(iterator | body) = source->select(iterator | not body) reject may have at most one iterator variable. collectNested (expression : OclExpression) : Sequence(T) The sequence of elements that results from applying body to every member of the source ordered set. source->collectNested(iterators | body) = source->iterate(iterators; result : Sequence(body.type) = Sequence{} | result->append(body ) ) collectNested may have at most one iterator variable. sortedBy (expression : OclExpression) : OrderedSet(T) Results in the ordered set containing all elements of the source collection. The element for which body has the lowest value comes first, and so on. The type of the body expression must have the < operation defined. The < operation must return a Boolean value and must be transitive (i.e., if a < b and b < c then a < c). source->sortedBy(iterator | body) = iterate( iterator ; result : OrderedSet(T) : OrderedSet {} | if result->isEmpty() then result.append(iterator) else let position : Integer = result->indexOf ( result->select (item | body (item) > body (iterator)) ->first() ) in result.insertAt(position, iterator) endif sortedBy may have at most one iterator variable
Actions taken:
October 10, 2008: received issue
October 16, 2009: closed issue

Discussion:

Issue 12946: The operation asSet, asSequence, asBag and asOrderedSet missing for OrderedSets (ocl2-rtf)

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

The operation asSet, asSequence, asBag and asOrderedSet are not defined for 
OrderedSets in 11.7.3. Also, since these operations are available in all collections 
we would expect their definition at Collection level.

Resolution: Disposition: See issue 4451 for disposition
Revised Text:
Actions taken:
October 10, 2008: received issue
October 16, 2009: closed issue

Issue 12947: Clarify the common supertype of Bag and Sequence (ocl2-rtf)

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

Summary: 
Does an OrderedSet conforms to a Set? Does an OrderedSet conforms to a Sequence? 
It seems that there is no automatic conformance between these concrete collection 
types (hence an explicit conversion need to be done when needed) 
However, for clarification, this should be stated in the definition of the respective concrete 
collection types to avoid OCL writers making wrong assumptions.

Resolution: Adding clarification sentences
Revised Text: In Section 11.6.3, add the sentence: An OrderedSet is not a subtype of Set, neither a subtype of Sequence. The common supertype of Sets and OrderedSets is Collection. In Section 11.6.5 add the sentence. A Sentence is not a subtype of Bag. The common supertype of Sentence and Bags is Collection.
Actions taken:
October 10, 2008: received issue
October 16, 2009: closed issue

Issue 12948: Making OclAny denote any object (ocl2-rtf)

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

Summary: In the actual OCL2 spec OclAny represents any object except collections. 
However this is unaligned with UML2 and MOF2 where such kind of type does not exist 
Instead in MOF we have the generic Object which represents any object including 
primitive and collection values. 
Also, looking at the list of operations defined for OclAny we see that there is no real 
justification for creating this special type. Operations like 'allInstances' and 'oclIsNew' are 
also invalid for primitive types and hence are not specifically invalid for collections. 
Making OclAny to represent any object (equivalent to MOF::Object) will simplify the stdlib 
and will be consistent with UML2 and MOF2.

Resolution: OclAny denotes now any object including collections. This makes the type system aligned with MOF.
Revised Text: (1) In Section 8.2, AnyType, replace the actual AnyType definition: AnyType is a special type that complies to all the types except the collection types. AnyType has a unique instance named OclAny. It is defined to allow defining generic operations that can be invoked in any object or primitive literal value. By the following: AnyType�is the metaclass of the special type OclAny, which is the type to which all other types conform. �OclAny is the sole instance of AnyType. �This metaclass allows defining the special property of being the generalization of all other Classifiers, including Classes, DataTypes and PrimitiveTypes. (2) In Section "8.2.1 Type Conformance", remove the second rule for Classifiers (All classifiers except collections conform to OclAny) (3) In Section "11.2.1 OclAny", replace the sentences "All types in the UML model and the primitive types in the OCL standard library complies with the type OclAny. Conceptually, OclAny behaves as a supertype for all the types except for the OCL pre-defined collection types." By "All types in the UML model and the primitive and collection types in the OCL standard library conforms to the type OclAny. Conceptually, OclAny behaves as a supertype for all the types."
Actions taken:
October 10, 2008: received issue
October 16, 2009: closed issue

Issue 12949: Incosistency between UnlimitedInteger and UnlimitedNatural (ocl2-rtf)

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

Summary: In Figure 8.6 we have UnlimitedNatural but in other parts of the spec there is 
a UnlimitedInteger definition.

Resolution:
Revised Text: In Section 11.4.5, replace all occurrences of UnlimitedInteger by UnilimitedNatural. Also replace UnlimitedIntegerType. By UnlimitedINaturalType.
Actions taken:
October 10, 2008: received issue
October 16, 2009: closed issue

Discussion:

The correct name is UnlimitedNatural. This error only occurs in Section 11.4.5.

Issue 12950: No way to represent type parameters in the standard library (ocl2-rtf)

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

Summary: The OCL metamodel does not provide means to encode type parameters 
in operations like the generic ones that are defined by Collection type in the standad library.

Resolution: Adding a TemplateParameterType. This promotes the solution to this problem as found in QVT.
Revised Text: (1) In Section 8.2, just before 8.2.1, add the definition: TemplateParameterType A TemplateParameterType is used to refer to generic types in parameterized definitions. It is used in the standard library to represent the parameterized collection operations. A template parameter type is usually named "T" (or "T2", "T3" and so on, when more than one type parameter is involved). The TemplateParameterType is a sub-class of Classifier. Attributes: specification : String An un-interpreted opaque definition of the template parameter type. Note: The definition should be placed in line with alphabetical order. (2) Update Figure 8.1 with the inclusion of the TemplateParameterType class. (3) In Section 13.3 Diagrams (Essential OCL), update the diagram (In this case, TemplateParameterType is a sub-class of Type).
Actions taken:
October 10, 2008: received issue
October 16, 2009: closed issue

Issue 12951: Use of MOF reflection in EssentialOCL should be clarified (ocl2-rtf)

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

Summary: There is no clear indication weather MOF reflection is available 
in EssentialOCL (except in the provided xmi, ecore files of essential ocl).

Resolution: The BasicOCL/EssentialOcl cannot merge EMOF reflection since we have conflict in metaclasses. The role of Object is played by AnyType. At M1 level, OCL has its own reflection mechanism. A clarification sentence is added.
Revised Text: In Section 13.2, after (4) numbered paragraph, add a new numbered paragraph with the following sentence: The EMOF Reflection capability is not merged to the metamodel. AnyType plays the role of Object. At instance level, reflection is provided by the oclIsKindOf(), oclIsTypeOf(), and oclType() operations
Actions taken:
October 10, 2008: received issue
October 16, 2009: closed issue

Issue 12953: Exact type of Set{} and missing Set(MyType){} literal definitions (ocl2-rtf)

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

Summary: 
It is not clear what is the concrete type of Set{}. Is it  Set(Object)??, Set(Void)?? 
Also it seems there is no way to explicitly define an empty collection with a given 
type for the elements.

Resolution: Discussion of this issue suggested a number of options: Option 1: The type of Set{} is Set(OclVoid) This does not work because Set{}->including(1) is an error since "1" or indeed anything other than null or invalid does not conform to OclVoid. Option 2: The type of Set{} is Set(OclAny) This does not work because acc : Set(Integer) = Set{}->including(1) is an error since Set(OclAny) is not compatible with Set(Integer). Option 3: The type of Set{} is a new built-in type EmptySet(ET) where ET is determined in some way. This does not work because given the RHS of acc : Set(Integer) = Set{}->including(1.0)- >including(Classifier)->excluding(1.0)->excluding(Classifier) it is difficult to see how ET could be determined more precisely than OclAny causing the same problem as Option 2. Option 4: The type of Set{} is Set(null) Since Set{} and Set(null) have no precise OCL 2.1 semantics there is some discretion in defining them, but eventually a dynamic type validation is needed for acc : Set(String) = Set(null){getInitialValue()}. The impact on evaluation could be mitigated by synthesis of an oclAsType() in the Abstract Syntax Tree, but it is not 18 possible to provide a static type for the CollectionLiteralExp. This option could work but requires revision of abstract syntax and evaluation specifications. Option 5: The type of Set{} is back-propagated For instance in acc : Set(Real) = Set{}->including(1)->including(-1) the type of Set{} is Set(Real) since that is the eventual result type. This involves unusual reverse semantics. Option 6: The type of Set{} is Set(T) with T chosen for well-formedness of the expression in which the Set{} is used. For instance in acc : Set(Real) = Set{}->including(1)->including(-1) the type of Set{} is initially Set(T) where T <= OclVoid. Propagation of the type to Set(T)::including(UnlimitedNatural) requires T <= UnlimitedNatural. Propagation to Set(T)::including(Integer) requires T <= Integer. Finally, propagation to the initializer requires Real <= T. Therefore any Real <= T <= Integer is well-formed. The lower bound, Set(Real), is preferred since it avoids many type conversions. It is also the same result as Option 5. Option 6 involves only additional forward static semantics, has no impact on evaluation, no impact on parsing, and gives the intuitively correct OCL 2.1 results. ----- In order to impose a user-specified element type and so get static type checking of user intent, a collection element type can be specified as: acc : Set(Integer) = Set(Integer){} It is difficult to parse this in OCL 2.1 because Set is not a reserved word and so lookahead is required to determine whether Set(someName) is the start of a StringLiteralExpCS or an OperationCallExpCS, with someName perhaps being a complicated nested type/value ambiguity. Issue 14357 introduces the concept of a restricted word preventing the unqualified use of Set as an operation name. The extension is then straightforward.
Revised Text: In 7.5.11 after A bag: Bag {1, 3, 4, 3, 5 } add The element type may be specified in parentheses. This ensures that the types of elements can be statically checked. Bag(Real) {1, 3, 4, 3, 5 } In 8.3.7 CollectionLiteralExp replace Note that the definition below implicitly states that empty collections have OclVoid as their elementType. by Note that the definition below defines only an upper bound on the elementType. The usage of the CollectionLiteralExp defines a lower bound. If the elementType is not explicitly specified, the elementType must be chosen to ensure the well-formedness of the elements of the CollectionLiteralExp and the usage of the CollectionLiteralExp. For instance in acc : Set(Real) = Set{1}->excluding(-1) Set{1} is well formed for any type Set(T) where T ? UnlimitedNatural. Well-formedness of the excluding operation call requires T ? Integer, and well-formedness of the initializer requires Real ? T. The overall expression is therefore only well-formed if Real ? T ? Integer. Either Set(Real) or Set(Integer) are wellformed. The most general type, Set(Real), is recommended since it minimizes type conversions and can often be easily deduced by considering the result type. In 8.3.7 CollectionLiteralExp replace inv: type.oclAsType (CollectionType).elementType = part->iterate (p; c : Classifier = OclVoid | c.commonSuperType (p.type)) by inv: let elementType : Type = part->iterate (p; c : Classifier = OclVoid | c.commonSuperType (p.type)) in elementType.conformsTo(type.oclAsType (CollectionType).elementType) In 9.3 CollectionLiteralExpCS replace CollectionLiteralExpCS ::= CollectionTypeIdentifierCS �{� CollectionLiteralPartsCS? �}� Abstract syntax mapping CollectionLiteralExpCS.ast : CollectionLiteralExp Synthesized attributes CollectionLiteralExpCS.ast.parts = CollectionLiteralPartsCS.ast CollectionLiteralExpCS.ast.kind = CollectionTypeIdentifierCS.ast Inherited attributes CollectionTypeIdentifierCS.env = CollectionLiteralExpCS.env CollectionLiteralPartsCS.env = CollectionLiteralExpCS.env Disambiguating rules [1] In a literal the collection type may not be Collection. CollectionTypeIdentifierCS.ast <> �Collection� by [A] CollectionLiteralExpCS ::= CollectionTypeIdentifierCS �{� CollectionLiteralPartsCS? �}� [B] CollectionLiteralExpCS ::= collectionTypeCS �{� CollectionLiteralPartsCS? �}� Abstract syntax mapping CollectionLiteralExpCS.ast : CollectionLiteralExp Synthesized attributes [A] CollectionLiteralExpCS.ast.parts = CollectionLiteralPartsCS.ast [A] CollectionLiteralExpCS.ast.kind = CollectionTypeIdentifierCS.ast [B] CollectionLiteralExpCS.ast.parts = CollectionLiteralPartsCS.ast [B] CollectionLiteralExpCS.ast.kind = collectionTypeCS.ast.kind [B] CollectionLiteralExpCS.ast.type = collectionTypeCS.ast Inherited attributes [A] CollectionLiteralPartsCS.env = CollectionLiteralExpCS.env [A] CollectionTypeIdentifierCS.env = CollectionLiteralExpCS.env [B] CollectionLiteralPartsCS.env = CollectionLiteralExpCS.env [B] collectionTypeCS.env = CollectionLiteralExpCS.env Disambiguating rules [A] [1] In a literal the collection type may not be Collection. CollectionTypeIdentifierCS.ast <> �Collection� [B] [1] In a literal the collection type may not be Collection. collectionTypeCS.ast <> CollectionType
Actions taken:
October 10, 2008: received issue
April 25, 2011: closed issue

Discussion:

Resolution of this issue requires some extra analysis

Disposition:	Deferred

Issue 13076: The concrete syntax given is extremely difficult to implement (ocl2-rtf)

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

The concrete syntax given is extremely difficult to implement, as documented in several places, including University of Dresden http://dresden-ocl.sourceforge.net/papers/ParserDesign.pdf Many languages have a syntax specified in a machine-readable form, (e.g. lex/yacc format). A standard, working, syntax for OCL would be very useful.

Resolution: Disposition: See issue 10439 for disposition
Revised Text:
Actions taken:
November 10, 2008: received issue
April 25, 2011: closed issue

Discussion:

Good suggestion. A lot of people has expressed the need for having an alternate BNF based way of providing the syntax. This could be done but requires some analysis to ensure it will be compatible with the way it is actually provided. 

Disposition:	Deferred

Issue 13077: The following collection operations would be useful for the HL7 GELLO project: (ocl2-rtf)

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

The HL7 GELLO project would find it useful to have additional collection operators in OCL. A method to define these in the underlying model would be good. Alternatively, we request the addition of the following operations:

 

max, min:          To determine the maximum or minimum value in a collection

 

firstN:   Returns a sequence with the first n elements of this sequence

 

lastN: Returns a sequence with the last n elements of this sequence

 

reverse: Returns a sequence in reverse order

 

join(namesOfCollections; namesOfProperties; booleanExpression; orderByExpression)

 

Where:

- namesOfCollections is a list of strings separated by commas, where each  

  string represents the name of a collection from where data is retrieved. 

- namesOfProperties is a list of strings separated by commas, where each 

  string is the full description of the properties from the objects in the

  collections we want to get in the result.  

- booleanExpression is a valid boolean expression containing the 

  conditions the elements from the collections defined in listOfCollections 

  must satisfy in order to be included in the result

- booleanExpression is a valid boolean expression containing the 

  conditions the elements from the collections defined in listOfCollections 

  must satisfy in order to be included in the result

 

average: Calculate the average value in a collection

 

stdev: Calculate the standard deviation of a collection

 

variance: Calculate the variance of a collection

 

median: Calculate the median of a collection

 

mode: Calculate the mode of a collection

Resolution:
Revised Text: (1) At the end of section 11.1 Introduction add the following sentence: The Standard Library may be extended with new types, new operations and new iterators. In particular new operations can be defined for collections. (2) In section 11.7.1 Collection, after "sum" operation definition add the following two definitions: max() : T The element with the maximum value of all elements in self. Elements must be of a type supporting the max operation. The max operation - supported by the elements - must take one parameter of type T and be both associative and commutative. Integer and Real fulfill this condition. post: result = self->iterate( elem; acc : T = self.first() | acc.max(elem) ) min() : T The element with the minimum value of all elements in self. Elements must be of a type supporting the min operation. The min operation - supported by the elements - must take one parameter of type T and be both associative and commutative. Integer and Real fulfill this condition. post: result = self->iterate( elem; acc : T = self.first() | acc.min(elem) ) (3) In section 11.7.3 OrderedSet, append the following operation definition: reverse () : OrderedSet(T) The set of elements with same elements but with the opposite order. post: result->size() = self->size() (4) In section 11.7.5 Sequence, append the following operation definition: reverse () : Sequence(T) The sequence containing the same elements but with the opposite order. post: result->size() = self->size()
Actions taken:
November 10, 2008: received issue
October 16, 2009: closed issue

Discussion:

In the OCL specification we found some statements that indicate that the standard library can be extended (example 11.8.1), not only with new operations but also with iterator expressions. However the mechanism for representing the standard library itself (as a M1 instance of the OCL metamodel) is unclear (a Package containing types which in turn contain operations?) and the extension mechanism for the standard library is also undefined (a pure replacement of the Package, or a new Package importing the StdLib package?).
Some other issues address specifically this problem, so the resolution of this issue will be formulated in a neutral way is respect to this representation issue: we confirm that new collection operations can be defined (adding a sentence) and we treat specifically the case of some generic operations that can be easily introduced: "reverse" as operation of "Sequence" and "OrderedSet", max, min as operations of Collection but with constraints on the type of parameters. 
We consider that average, stdev, variance, median and mode are too specific and can be defined as extensions. The proposed join functionality can be re-formulated as an iterator extending the standard library.

Issue 13535: doubts about the iterator variables (ocl2-rtf)

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

I have a few doubts about the iterator variables. Reading the specification I am not sure about, for each iterator, how many iterator variables can have. Looking at sections 7.6 and 11.9 my conclusion in the following: -select --> It has zero or one iterator variables. (0..1) -reject --> It has zero or one iterator variables.(0..1) -collect --> It has zero or one iterator variables.(0..1) -forAll --> There is no restriction about the number of iterator variables. (0..*) -exists --> Unlike forAll, in section 7.6 there is no text saying anything about the number of variables. But in section 11.9 it seems that it is the same case that forAll. (0..*) -iterate --> It has one iterator variable. -collectNested --> It has zero or one iterator variables.(0..1) -one --> It has zero or one iterator variables.(0..1) -any --> It has zero or one iterator variables.(0..1) -isUnique -->It has zero or one iterator variables.(0..1) Is my conclusion correct in everything? or in wich parts am I confused? How can the most of the iterators be defined by the iterate iterator if iterate iterator can have only one variable iterator? I think the iterate iterator should not have restrictions about the number of iterator variables (0..*).

Resolution:
Revised Text: (1) In Section 7.6.4, add the following sentence at the end of the section. "Similarly to forAll expression an exists expression may declare multiple iterators". (2) In Section 11.9.1 Collection, in IsUnique part, replace occurrences of 'iterators' by 'iterator'. The same for Collect part. (3) In Section 11.9.2 Set, in collectNested, replace occurrences of 'iterators' by 'iterator'. (4) In Section 11.9.3 Bag, in collectNested, replace occurrences of 'iterators' by 'iterator'. (5) In Section 11.9.4 Sequence, in collectNested, replace occurrences of 'iterators' by 'iterator'.
Actions taken:
February 20, 2009: received issue
October 16, 2009: closed issue

Discussion:

The assumption of the reporter concerning the number of iterators in the syntax is correct.
The number of iterators is in fact explicily defined in Section 11.9. By the way, for the last question of the reporter, there is no issue at all since according to the abstract syntax the association end iterator is already declared as multivalued (see LoopExp::iterator [*] in Figure 8.2).
We believe anyway that it is useful to add a sentence in Section 7 stating that 'exists' operator can potentially have multiple iterators since there is no example of this.
Also some minor typo fixing is needed in  11.9.

Issue 13536: type of the iterator variable is expected or not? (ocl2-rtf)

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

I wrote an issue similar than this one but not equal so, the body could seem equal but it is not the case. I have a few doubts about the iterator variables. Reading the specification I am not sure about, for each iterator, if the type of the iterator variable is expected or not. For example: collection->select( v : Type | boolean-expression-with-v ) collection->select( v | boolean-expression-with-v ) Looking at sections 7.6 and 11.9 my conclusion is the following: -select --> It is NOT obligatory to write the type of the iterator variable. It appears in section 7.6. -reject --> It is NOT obligatory to write the type of the iterator variable. It appears in section 7.6. -collect --> It is NOT obligatory to write the type of the iterator variable. It appears in section 7.6. -forAll --> It is NOT obligatory to write the type of the iterator variable. It appears in section 7.6. -exists --> It is NOT obligatory to write the type of the iterator variable. It appears in section 7.6. -iterate --> In section 7.6 it seems that in both, for the iterator variable and for the accumulator variable, it is obligatory to write the type. -collectNested --> It is NOT obligatory to write the type of the iterator variable. It is a similar case than the collect. -one --> It is NOT obligatory to write the type of the iterator variable. -any --> It is NOT obligatory to write the type of the iterator variable. -isUnique -->It is NOT obligatory to write the type of the iterator variable. Is my conclusion correct in everything? or in which parts am I confused? I think that both, iterator variable and accumulator variable of the iterate iterator should have their types optional. In other words, to write the type of the iterator variable or the type of the accumulator variable should not be obligatory.

Resolution: It is clear from the various examples in Section 7 that the type declaration of the iterator is optional in collection operations. By default VariableDeclarationCS is defined so that the type of the variable declared is optional. Disposition: Close, no change
Revised Text:
Actions taken:
February 20, 2009: received issue
October 16, 2009: closed issue

Discussion:

It is clear from the various examples in Section 7 that the type declaration of the iterator is optional in collection operations. By default VariableDeclarationCS is defined so that the type of the variable declared is optional.

Disposition:	Close, no change

Issue 13537: have tuple fields and let variables to have the declaration of their types explicity? (ocl2-rtf)

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

have tuple fields and let variables to have the declaration of their types explicity?

Resolution:
Revised Text: In Section 7.4.3, at the end of the section add the sentence: "A variable declaration inside a let must have a declared type and an initial value".
Actions taken:
February 20, 2009: received issue
October 16, 2009: closed issue

Discussion:

By default a VariableDeclarationCS has the type declarator optional unless it is explicitly stated that it should be present. It is mandatory for Let (see disambiguation rules of LetExpCS) but not mandatory for tuples.
To avoid that people ask the question again for let expression, we add a sentence in 7.4.3.

Issue 13915: Role 'collectionTypes' should be 'collectionType' (ocl2-rtf)

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

In Section 8.2.2, in Classifier well-formedness rules, 'collectionTypes' is used instead 
of 'collectionType'. This is not correct since in OCL, by convention, when not provided explicitly 
the name of an opposite role takes the name of the target class with first letter lowerized.

Resolution:
Revised Text: In Section 8.2.2, (top of page 39), Classifier well-formedness rule, replace: [1]For each classifier at most one of each of the different collection types exist. context Classifier inv: collectionTypes->select(oclIsTypeOf(CollectionType))->size() <= 1 inv: collectionTypes->select(oclIsTypeOf(BagType ))->size() <= 1 inv: collectionTypes->select(oclIsTypeOf(SequenceType ))->size() <= 1 inv: collectionTypes->select(oclIsTypeOf(SetType ))->size() <= 1 by: [1]For each classifier at most one of each of the different collection types exist. context Classifier inv: collectionType->select(oclIsTypeOf(OrderedSetType))->size() <= 1 inv: collectionType->select(oclIsTypeOf(BagType))->size() <= 1 inv: collectionType->select(oclIsTypeOf(SequenceType))->size() <= 1 inv: collectionType->select(oclIsTypeOf(SetType))->size() <= 1
Actions taken:
May 5, 2009: received issue
October 16, 2009: closed issue

Issue 13944: [OCL-2.1 RTF] Transitive closure operator (ocl2-rtf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

Specification: Object Constraint Language, formal/06-05-01

Section: 7.6 Collection Operations

 

Summary:

 

The concept of transitive closure is very useful for specifying well-formedness constraints on binary relations.

For a binary relation r:A->A and elements x,y,z in A, r(x,y) is true when r relates x to y and r is transitive whenever for any x,y,z in A, r(x,y) and r(y,z) imply r(x,z). The transitive closure of a binary relation r:A->A is the smallest relation, ^r:A->A, that contains r and is transitive. 

 

In the UML specification, the definition of Classifier::allParents() : Classifier[*] as �all the direct and indirect ancestors of a generalized Classifier� could be equivalently paraphrased as the transitive closure of the Classifier::parents() : Classifier[*] relation.

 

Specifying the notion of transitive closure for the OCL specification can be problematic as this notion refers to a meta-property not expressible in first order logic (i.e., the smallest relation satisfying a given property). However, the notion of transitive closure can be specified in the context of a particular API for evaluating OCL iterator expressions such as that of the Eclipse OCL implementation of the OCL2.0 specification:

 

http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.ocl.doc/references/overview/OCLOverview.html

 

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.mdt/org.eclipse.ocl/plugins/org.eclipse.ocl/src/org/eclipse/ocl/internal/evaluation/IterationTemplateClosure.java?root=Modeling_Project&view=markup

 

A synopsis of the algorithm for computing the transitive closure as an OCL iterator expression is available here:

 

http://dev.eclipse.org/newslists/news.eclipse.modeling.mdt.ocl/msg01390.html

Resolution:
Revised Text: Add an additional section before 7.6.5 7.6.5 Closure Operation The iterators described in the preceding sections return results from the elements of a collection. The closure supports returning results from the elements of a collection, the elements of the elements of a collection, the elements of the elements of the elements of a collection, and so forth. This can be useful for iterating over a transitive relationship such as a UML generalization. The closure operation uses the same syntax as the select and reject iterators and is written as one of source->closure( v : Type | expression-with-v ) source->closure( v | expression-with-v ) source->closure( expression ) The returned collection of the closure iteration is an accumulation of the source collection, and the collections resulting from the recursive invocation of expression-with-v in which v is associated exactly once with each distinct element of the returned collection. The iteration terminates when expression-with-v returns empty collections or collections containing only already accumulated elements. The collection type of the result collection is the unique form (Set or OrderedSet) of the original source collection. If the source collection is ordered, the result is in depth first preorder. The result satisfies the postcondition: post: let sourceAndResult : Set(Type) = source->asSet()->union(result) in sourceAndResult = sourceAndResult->collect(expression) For a simple parent-children relationship and known parents parents->closure(children) computes the set of parents.children, parents.children.children, parents.children.children.children etc. In the opposite direction self->asOrderedSet()->closure(mother) computes the maternal line. For a more complex relationship such as UML Classifier generalization aClassifier.generalization()->closure(general.generalization).general()->including(aClassifier) computes the set comprising aClassifier and all its generalizations. The closure recurses over the Generalizations to compute the transitive set of all Generalizations. The generalized classifier is collected from each of these before including the originating aClassifier in the result. As with all other iterators, self remains unchanged throughout the recursion, and an implicit source attempts to resolve features against iterators. At the end of 7.8 Resolving Properties add A closure iteration may introduce an implicit iterator-variable at each level of recursion and so multiple iterator-variable candidates for consideration as the implicit self. Since all candidates have the same static type, it is only the least deeply nested candidate, with respect to the iteration body, that need be considered as the implicit iterator-variable for a closure. In 8.3.7 IteratorExp add IteratorExp closure [1] There is exactly one iterator. context IteratorExp inv: name = 'closure' implies iterator->size() = 1 [2] The collection type for an OrderedSet or a Sequence source type is OrderedSet. For any other source the collection type is Set. context IteratorExp inv: name = 'closure' implies if source.type.oclIsKindOf(SequenceType) or source.type.oclIsKindOf(OrderedSetType) then type.oclIsKindOf(OrderedSetType) else type.oclIsKindOf(SetType) endif [3] The source element type is the same as type of the body elements or element. context IteratorExp inv: name = 'closure' implies source.type.oclAsType(CollectionType).elementType = if body.type.oclIsKindOf(CollectionType) then body.type.oclAsType(CollectionType).elementType else body.type endif [4] The element type is the same as the source element type. context IteratorExp inv: name = 'closure' implies type.oclAsType(CollectionType).elementType = source.type.oclAsType(CollectionType).elementType In 11.9.1 add closure The closure of applying body transitively to every distinct element of the source collection. source->closure(iterator | body) = anonRecurse(source, Result{}) where: anonRecurse is an invocation-site-specific helper function synthesized by lexical substitution of iterator, body, add and Result in: context OclAny def: anonRecurse(anonSources : Collection(T), anonInit : Result(T)) : Result(T) = anonSources->iterate(iterator : T; anonAcc : Result(T) = anonInit | if anonAcc->includes(iterator) then anonAcc else let anonBody : OclAny = body in let anonResults : Result(T) = anonAcc->add(iterator) in if anonBody.oclIsKindOf(CollectionType) then anonRecurse(anonBody.oclAsType(Collection(T)), anonResults) else anonRecurse(anonBody.oclAsType(T)->asSet(), anonResults) endif endif) where: T is the element type of the source collection. Result is 'OrderedSet' if the source collection is ordered, 'Set' otherwise. add is 'append' if the source collection is ordered, 'including' otherwise. The anonymous variables 'anonRecurse', 'anonAcc', 'anonInit', 'anonResults' and 'anonSources' are named for exposition purposes; they do not form part of the evaluation environment for body.
Actions taken:
May 31, 2009: received issue
April 25, 2011: closed issue

Discussion:

The omission of a closure iterator has been noted by many OCL users. The suggestion is
practical, but since it is a transitive closure the use of the name closure as in the
referenced implementation could be misleading. Conversely the use of a clearer name
such as transitiveClosure() is a bit verbose. Since closure() has already started to be used
and its usage is clearly associated with a context object rather than a global scope,
insisting on the longer name seems unnecessarily pedantic.
A closure iterator is specified below generalising the referenced Eclipse MDT/OCL
implementation to operate on an OrderedSet as well as a Set.
[Design note. An attempt to extract a more generic recurse() building block proved
fruitless. A more general recurse might for instance support transitiveExists,
transitiveForAll etc. It was not clear that, for instance a Bag of multiple encounters was
of any practical use, and the Bag could anyway be generated by an iteration over the
transitiveClosure. Similarly an elaboration to allow a user function of the encounters
requires two bodies and multiple iterate results. Once again it is easier to provide the
simple transitiveClosure and then invoke the user function on the result. Any enhanced
efficiency from the combined operation could still be obtained by an OCL 'compiler' that
optimises a transitiveClosure(...)->forAll(...).]

Issue 14094: Erroneous operation names 'isOclType' and 'asOclType' (ocl2-rtf)

Click here for this issue's archive.
Source: Open Canarias, SL (Mr. E. Victor Sanchez, vsanchez(at)opencanarias.com)
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text: In Section 10 replace all references to asOclType by oclAsType In Section 10 replace all references to isOclType by oclIsTypeOf
Actions taken:
July 25, 2009: received issue
April 25, 2011: closed issue

Discussion:

These typos all occur in Section 10.

Issue 14196: Missing specification of UnlimitedNatural (ocl2-rtf)

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

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

Resolution: see pages 24 - 35 of OMG document ptc/2010-12-01
Revised Text:
Actions taken:
August 22, 2009: received issue
April 25, 2011: closed issue

Discussion:

[The use of e comes from Issue 14197; a much more comprehensive response to Issue 12349 of
the missing distinction between ? as invalid and e as null.]

Issue 14197: OCL 2.0, 2.1 inconsistent definition of null and invalid (ocl2-rtf)

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

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


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

Resolution:
Revised Text: In 7.4.10 replace Undefined Values Some expressions will, when evaluated, have an undefined value. For instance, typecasting with oclAsType() to a type that the object does not support or getting the ->first() element of an empty collection will result in undefined. In general, an expression where one of the parts is undefined will itself be undefined. by 7.4.11 Invalid Values Some expressions will, when evaluated, have an invalid value. For instance, typecasting with oclAsType() to a type that the object does not support or getting the ->first() element of an empty collection will result in invalid. In general, an expression where one of the parts is null or invalid will itself be invalid. In 7.4.10 replace Finally, there is an explicit operation for testing if the value of an expression is undefined. oclIsUndefined() is an operation on OclAny that results in True if its argument is undefined and False otherwise. by Finally, there is an explicit operation for testing if the value of an expression is undefined. oclIsUndefined() is an operation on OclAny that results in True if its argument is null or invalid and False otherwise. In 7.7.2 last sentence replace If message.hasReturned() is false, then message.result() will be undefined. by If message.hasReturned() is false, then message.result() will be invalid. In 8.2 VoidType replace VoidType represents a type that conforms to all types. by VoidType is the metaclass of the OclVoid type that conforms to all types except the OclInvalid type. In 8.2 VoidType replace Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections. by Note that in contrast with invalid, null is a valid value and as such can be owned by collections. In 8.2.1 InvalidType replace [1] Invalid conforms to all other types except OclVoid. context InvalidType inv: Classifier.allInstances()->forAll (c | not c.oclIsTypeOf(OclVoid) implies self.conformsTo (c)) by [1] OclInvalid conforms to all other types. context InvalidType inv: Classifier.allInstances()->forAll (c | self.conformsTo (c)) In 8.2.1 VoidType replace [1] Void conforms to all other types except OclInvalid. by [1] OclVoid conforms to all other types except OclInvalid. In 9.3 VariableDeclarationCS replace -- The value OclUndefined is used when no type has been given in the concrete syntax. -- Production rules that use this need to check on this type. VariableDeclarationCS.ast.type = if typeCS->notEmpty() then typeCS.ast else OclUndefined endif by -- The value null is used when no type has been given in the concrete syntax. -- Production rules that use this need to check on this type. VariableDeclarationCS.ast.type = if typeCS->notEmpty() then typeCS.ast else null endif In 9.3 OclMessageExpCS replace in OclMessageExpCS.ast.calledOperation = if operation->isEmpty() then OclUndefined else = operation endif OclMessageExpCS.ast.sentSignal = if signal->isEmpty() then OclUndefined else signal endif by in OclMessageExpCS.ast.calledOperation = if operation->isEmpty() then invalid else = operation endif OclMessageExpCS.ast.sentSignal = if signal->isEmpty() then invalid else signal endif In 9.4.3 final clause replace post: if self.namespace->notEmpty() -- this namespace has an owning namespace then result.parent = self.namespace.getEnvironmentWithParents() else result.parent = OclUndefined endif by post: if self.namespace->notEmpty() -- this namespace has an owning namespace then result.parent = self.namespace.getEnvironmentWithParents() else result.parent = invalid endif In 11.2.3 OclVoid replace The type OclVoid is a type that conforms to all other types except OclInvalid. It has one single instance, identified as null, that corresponds with the UML LiteralNull value specification. Any property call applied on null results in OclInvalid, except for the operation oclIsUndefined(). Any property call applied on null results in OclInvalid, except for the operation oclIsUndefined() and oclIsInvalid(). by The type OclVoid is a type that conforms to all other types except OclInvalid. It has one single instance, identified as null, that corresponds with the UML LiteralNull value specification. Any property call applied on null results in invalid, except for the oclIsUndefined(), oclIsInvalid(), =(OclAny) and <>(OclAny) operations. In 11.2.4 OclInvalid replace The type OclInvalid is a type that conforms to all other types except OclVoid. It has one single instance, identified as invalid. Any property call applied on invalid results in OclInvalid, except for the operations oclIsUndefined() and oclIsInvalid(). by The type OclInvalid is a type that conforms to all other types. It has one single instance, identified as invalid. Any property call applied on invalid results in invalid, except for the oclIsUndefined() and oclIsInvalid() operations. In 11.2.5 oclIsUndefined replace Evaluates to true if the self is equal to OclInvalid or equal to null. by Evaluates to true if the self is equal to invalid or equal to null. In 11.2.6 result replace Otherwise the undefined value is returned. by Otherwise the invalid value is returned. Change 11.2.5 Operations and Well-formedness Rules OclAny ... OclVoid= ... 11.2.6 OclMessage to 11.3 Operations and Well-formedness Rules 11.3.1 OclAny ... 11.3.2 OclVoid ... 11.3.3 OclMessage Move from 11.2.5 OclVoid = (object : OclAny) : Boolean Redefines the OclAny operation, returning true if object is null. post: result = object.oclIsTypeOf(OclVoid) to 11.3.2 OclVoid = (object : OclAny) : Boolean Redefines the OclAny operation, returning true if object is null. post: result = object.oclIsTypeOf(OclVoid) Remove from 11.2.5 OclInvalid = (object : OclAny) : Boolean Redefines the OclAny operation, returning true if object is invalid. post: result = object.oclIsTypeOf(OclInvalid) In 11.5.1 Real / replace Evaluates to OclInvalid if r is equal to zero. by Evaluates to invalid if r is equal to zero. In 11.5.2 Integer / replace Evaluates to OclInvalid if r is equal to zero. by Evaluates to invalid if r is equal to zero. In 11.7.1 Collection flatten replace [1] A collection cannot contain OclInvalid values. by [1] A collection cannot contain invalid values. In 12.12 paragraph 5 replace If more than one classifier is found, the operation returns OclUndefined. by If more than one classifier is found, the operation returns invalid. In A.1.1.1 replace All type domains include an invalid and a null value that allows one to operate respectively with unknown and �null� values. by All type domains include ?, an invalid value, and e, a null value, that allows one to operate respectively with invalid and undefined values. In A.1.1.2 Definition A.1 replace The main difference between classes and object types is that the interpretation of the latter includes a special undefined value. by The main difference between classes and object types is that the interpretation of the latter includes a special undefined value and a special invalid value. (OCL 2.0 typo) In A.1.1.5 Definition A.4 replace (sa) = <? c, c> by (sa) = <c, c> (OCL 2.0 typo) In A.1.1.6 Definition A.7 replace three uses of in the bottom line of the parents: definition by unicode 227A ? OCL 2.0 typo) Following A.1.1.6 Definition A.7 replace in the bottom line of the parents: definition by unicode 227A ? (OCL 2.0 typo) Following A.1.1.6 Definition A.8 point 3 replace by unicode 22C2 ? (OCL 2.0 typo) In A.1.1.7 Definition A.9 replace one use of and one use of by unicode 227A ? and M (OCL 2.0 typo) Following A.1.1.7 Definition A.9 point v. replace one use of by unicode 227A ? (OCL 2.0 typo) In A.1.2.1 remove (OCL 2.0 typo) In A.1.2.1 Definition A.10 restore the last equation to The domain of a class c � CLASS is defined as ICLASS (c') = ?{oid(c') | c' � CLASS ^ c' ? c} (OCL 2.0 typo) In A.1.2.2 restore the equation to " c1,c2 � CLASS : c1 ? c2 ? I(c1) ? I(c2) . (OCL 2.0 typo) In A.1.2.3 Definition A.11 restore the last equation to Ias � IASSOC(as). In A.2.1 Definition A.14 replace � I(Integer) = Z ? {?} � I(Real) = R ? {?} � I(Boolean) = { true, false } ? {?} � I(String) = A* ? {?} by � I(OclInvalid) = {?} � I(OclVoid) = {e,?} � I(Integer) = Z ? {e,?} � I(Real) = R ? {e,?} � I(Boolean) = { true, false } ? {e,?} � I(String) = A* ? {e,?} � I(UnlimitedNatural) = N ? {8,e,?} Following A.2.1 Definition A.14 replace Each domain also contains a special undefined value that is motivated in the next section. by Each domain also contains two special values e and ?. e coresponds to the null value, and ?, pronounced bottom, corresponds to the invalid value. These are motivated in the next section. In A.2.1.1 replace Each domain of a basic type t contains a special value ?. This value represents an undefined value that is useful for two purposes: 1. An undefined value may, for example, be assigned to an attribute of an object. ... 2. An undefined value can signal an error in the evaluation of an expression. ... The problems with partial functions can be eliminated by including an undefined value ? into the domains of types. ... ... Hence, an undefined argument value causes an undefined operation result. ... by Each domain of a basic type t contains two special values e and ?. e represents an null or undefined value and ? an invalid value. These are useful for the following purposes: 1. An undefined or null value may, for example, be assigned to an attribute of an object. ... 2. An invalid value can signal an error in the evaluation of an expression. ... The problems with partial functions can be eliminated by including the invalid value ? into the domains of types. ... ... Hence, an invalid or null argument value causes an invalid operation result. ... Following A.2.1.4 Definition A.16 replace I ?+??i1 , i2?={i1 + i2 if i1?? and i2?? ? otherwise by I ?+??i1 , i2?={i1 + i2 if i1?? and i1?e and i1?8 and i2?? and i2?e and i2?8 ? otherwise (NB. unlimited 8 is part of the resolution of the missing UnlimitedNatural specification). Replace A2.1.4 Table A.2 b1 b2 b1 and b2 b1 or b2 b1 xor b2 b1 implies b2 not b2 FALS E FALS E FALSE FALSE FALSE TRUE TRUE FALS E TRUE FALSE TRUE TRUE TRUE TRUE TRUE FALS E FALSE TRUE TRUE FALSE FALSE TRUE TRUE TRUE TRUE FALSE TRUE FALSE FALS E ? FALSE ? ? TRUE TRUE TRUE ? ? TRUE ? ? FALSE ? FALS E FAUX ? ? ? ? ? TRUE ? TRUE ? VRAI ? ? ? ? ? ? ? ? by b1 b2 b1 and b2 b1 or b2 b1 xor b2 b1 implies b2 not b2 FALSE FALS E FALSE FALSE FALSE TRUE TRUE FALSE TRUE FALSE TRUE TRUE TRUE TRUE TRUE FALS E FALSE TRUE TRUE FALSE FALSE TRUE TRUE TRUE TRUE FALSE TRUE FALSE FALSE ? or e FALSE ? ? TRUE TRUE TRUE ? or e ? TRUE ? ? FALSE ? or e FALS E FALSE ? ? ? ? ? or e TRUE ? TRUE ? TRUE ? ? or e ? or e ? ? ? ? ? (Only change is introduction of "or e" to the first two columns.) In A.2.2 replace I ?=t ??v1 , v2?={true if v1=v2, and v1?? and v2?? ? if v1=? or v2=? false otherwise by I ?=t ??v1 , v2?={true if v1=v2 and v1?? and v1?e and v1?8 and v2?? and v2?e and v2?8 true if v1=8 and v2=8 true if v1=e and v2=e ? if v1=? or v2=? false otherwise In A.2.2 replace It is also useful to have an operation that allows one to check whether an arbitrary value is well defined or undefined. This can be done with the operations isDefined t : t ? Boolean and isUndefinedt : t ? Boolean for any type t � T. The semantics of these operations is given for any v � I(t) by: I(isDefinedt)(v) = (v ? ? ) I(isUndefinedt )(v) = (v = ?) by It is also useful to have an operation that allows one to check whether an arbitrary value is invalid or undefined. This can be done with the operations oclIsInvalidt : t ? Boolean and oclIsUndefinedt : t ? Boolean for any type t � T. The semantics of these operations is given for any v � I(t) by: I(oclIsInvalidt)(v) = (v = ?) I(oclIsUndefinedt)(v) = (v = ?) ? (v = e) In A.2.3 Definition A.18 replace I(t) = literals(t) ? {?}. by I(t) = literals(t) ? {e,?}. In A.2.4 Definition A.20 replace I(t) = ICLASS(c) ? {?}. by I(t) = ICLASS(c) ? {e,?}. In A.2.4 Following Definition A.20 replace The undefined value that is only available with the type by The undefined null value that is only available with the type In A.2.4 Following Definition A.20 replace Otherwise, the result is the undefined value. by Otherwise, the result is the invalid value. In A.2.4.3 Following Definition A.21 replace The attempt to access an attribute of a non-existent object results in an undefined value. by The attempt to access an attribute of a non-existent object results in the invalid value. (OCL 2.0 typo) In A.2.4.5 restore the first equation to M = (CLASS, ATTc, OPc, ASSOC, associates, roles, multiplicities, ?). In A.2.5.4 last paragraph replace A collection value therefore may contain undefined values while still being well defined. by A collection value therefore may contain undefined null values while still being well defined. (OCL 2.0 typo) In A.2.5.5 following Table A.3 restore the first equation to Set(t) X t ? Integer In A.2.5.5 following I(count) replace A set may contain the undefined value so that the result of count is 1 if the undefined value is passed as the second argument, for example, count({?}, ?) = 1 and count({1}, ?) = 0. by A set may contain the undefined null value so that the result of count is 1 if the null value is passed as the second argument, for example, count({e}, e) = 1 and count({1}, e) = 0. In A.2.6 replace � OclVoid is the subtype of all other types. The only value of this type is the undefined value. Notice that there is no problem with cyclic domain definitions as ? is an instance of every type. by � OclVoid is the subtype of all types other than OclVoid and OclInvalid. The only value of this type is null, the undefined value. Notice that there is no problem with cyclic domain definitions as e is an instance of every type other than OclInvalid. � OclInvalid is the subtype of all other types. The only value of this type is invalid, the invalid value. Notice that there is no problem with cyclic domain definitions as ? is an instance of every type. In A.2.6.1 replace The set of special types is TS = {OclAny, OclVoid}. Let ^ T be the set of basic, enumeration, and object types ^ T = TB U TE U TC . The domain of OclAny is given as I(OclAny) = (UteT I(t)) U {?}. The domain of OclVoid is I(OclVoid) = {?}. by The set of special types is TS = {OclAny, OclVoid, OclInvalid}. Let T^ be the set of basic, enumeration, and object types T^ = TB U TE U TC . The domain of OclAny is given as I(OclAny) = (UteT I(t)) U {e,?}. The domain of OclVoid is I(OclVoid) = {e,?}. The domain of OclInvalid is I(OclInvalid) = {?}. In A.2.6.1 replace For OclVoid, the constant operation undefined : ? OclVoid results in the undefined value ?. The semantics is given by I(undefined) = ?. by For OclVoid and OclInvalid, the constant operation oclIsUndefined : ? Boolean results in the true value, and for OclInvalid, the constant operation oclIsInvalid : ? Boolean results in the true value. The semantics is given by I(OclVoid) = {e,?} and I(OclInvalid) = ?. In A.2.7 add ?. OclInvalid is a subtype of OclVoid. In A.2.7 replace 4. OclVoid is subtype of all other types. by 4. OclVoid is subtype of all types other than OclVoid and OclInvalid. In A.2.7 Definition A.27 add ?. OclInvalid = OclVoid. (OCL 2.0 typo) In A.2.7 Definition A.27 restore viii to viii. If classOf(t�c) ? classOf(tc) then t�c = tc. In A.3.1.2 above the if then else example replace An undefined condition makes the whole expression undefined. Note that when an expression in one of the alternative branches is undefined, by A null or invalid condition makes the whole expression invalid. Note that when an expression in one of the alternative branches is null or invalid, In A.3.1.2 after the if then else example replace The result of a cast expression (vi) using asType is the value of the expression, if the value lies within the domain of the specified target type, otherwise it is undefined. ... Note that these type cast and test expressions also work with undefined values since every value � including an undefined one � has a welldefined type. by The result of a cast expression (vi) using asType is the value of the expression, if the value lies within the domain of the specified target type, otherwise it is invalid. ... Note that these type cast and test expressions also work with null or invalid values since every value � including a null or invalid one � has a welldefined type. In A.3.1.5 last sentence replace Invariants with undefined result invalidate a system state. by Invariants with null or invalid result invalidate a system state. In A.3.2.1 three bullets from the end replace Hence, a reference to the previous value of attribute c is undefined. by Hence, a reference to the previous value of attribute c is invalid. In A.3.2.2 Definition A.32 second bullet replace Output parameters are undefined on entry: kind(p) = out implies �pre(p) = ?. by Output parameters are null on entry: kind(p) = out implies �pre(p) = e. Disposition: Resolved OMG Issue No: 14199 Title: Inaccurate well-formedness constraints for IteratorExp Source: THALES (Dr. Edward Willink, ed.willink@thalesgroup.com ed@willink.me.uk) Summary: The well-formedness constraints for IteratorExp are confusing, incomplete and sometimes wrong. For instance it is specified in words that for 8.3.7 IteratorExp [1] the iterator of forAll is Boolean. The subsequent constraint is correct; it is the iteration type not iterator that is Boolean. 8.3.7 IteratorExp[2] uses a non-existent property collectionType and selects the first of a number of body type returns. This seems to confuse dynamic and static behaviours.. 8.3.7 IteratorExp[4] uses boolean rather than Boolean and tests only for the name and not the meta class. The only one iterator allowed constraint is missing. There are no constraints for any, collectNested, one, sortedBy. The presentation in Section 8.3.5 is unhelpful through bundling the various iterator semantics under a single heading. Multiple headings such as IteratorExp forAll would be more readable for the full set of iterators.. Discussion: The revised text below resolves these issues. Revised Text: In 8.3.7 replace IteratorExp [1] If the iterator is �forAll,� �isUnique,� or �exists� the type of the iterator must be Boolean.
Actions taken:
August 22, 2009: received issue
April 25, 2011: closed issue

Discussion:

The resolution of Issue 6611 is wrong. OclAny=(object : OclAny) should not be
overloaded for OclInvalid.
The resolution violates the principle that invalid results should propagate arithmetically
unless explicitly tested using oclIsInvalid() or oclIsUndefined(). The danger of this is
clear from the following example:
let expr1 : Boolean = eval1() in
let expr2 : Boolean = eval2() in
expr1 = expr2
If both eval1() and eval2() fail and return invalid, the overall result subject to the Issue
6611 resolution is true. The result must be invalid to propagate invalid.
The resolutions of Issue 10433, 10434, 12378, 12484, 12485 are wrong. OclInvalid
should remain conformant to OclVoid.
None of the resolutions address the massive conflict between Section 8 and Section 11.
While neither section is close to self consistent, Section 8 strongly suggests that
OclInvalid is the instance of Invalid which is the instance of InvalidType, while Section
11 almost mandates that invalid is the instance of OclInvalid which is the instance of
InvalidType.
The resolution of Issue 12349 is locally unhelpful through referring to invalid as
unknown and totally inadequate to address the issue of two bottoms throughout the
remaining text.
There is probably little practical difference between the alternative conformance choices
for OclVoid and OclInvalid, however the text should be consistent.
The original 2.0 Appendix A is sensibly interpreted with bottom (?) equated to invalid.
It is just necessary to introduce and equate a nearly-bottom (e) as null and align all the
text accordingly.

Issue 14199: OCL 2.0, 2.1 Inaccurate well-formedness constraints for IteratorExp (ocl2-rtf)

The well-formedness constraints for IteratorExp are confusing, incomplete and sometimes wrong.

Resolution: The revised text below resolves these issues
Revised Text: see pages 53 - 57 of OMG document ptc/2010-12-01
Actions taken:
August 22, 2009: received issue
April 25, 2011: closed issue

Issue 14222: OCL 2.1 Inconsistent implementation of Issue 6532 and contradictory resolution of Issues 7341 and 10437 (ocl2-rtf)

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

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


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


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

Resolution: Issue 7341 is correct.; invalid should be returned by oclAsType when the type does not conform. Issue 10437 is wrong. The 10437 revised text also incorrectly uses t rather than T. Issue 6532 specified an 'instance of Classifier' return for oclAsType. The convenience document has not been updated.
Revised Text: In Section 11.2.5 as revised by Issue 10437 replace Evaluates to self, where self is of the type identified by t. The type t may be any classifier defined in the UML model; if the actual type of self at evaluation time does not conform to t, then the oclAsType operation evaluates to null. by Evaluates to self, where self is of the type identified by T. The type T may be any classifier defined in the UML model; if the actual type of self at evaluation time does not conform to T, then the oclAsType operation evaluates to invalid. In Section 7.5.9 as revised by Issue 6532 replace oclAsType (t : Classifier) : instance of OclType by oclAsType (t : Classifier) : instance of Classifier
Actions taken:
August 26, 2009: received issue
April 25, 2011: closed issue

Issue 14224: Inconsistent lookup for underscored symbols (ocl2-rtf)

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

Description:


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


Should be


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

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

Resolution: Discussion: Issue 14357 introduces a new underscore-prefix string syntax (_'self') to access awkward spellings. This solves the problem of accessing either _'self' or _'_self'.
Revised Text:
Actions taken:
August 27, 2009: received issue
April 25, 2011: closed issue

Issue 14236: OCL 2.1 Incomplete resolution 9913 InvalidLiteralExpCS and NullLiteralExpCS (ocl2-rtf)

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

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


Suggest:


Add to PrimitiveLiteralExpCS


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


and


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


(not forgetting UnlimitedNaturalLiteralExpCS

Resolution: Yes; resolution 9913 is incomplete
Revised Text: In 9.3 PrimitiveLiteralExpCS add (noting that [E] for UnlimitedNaturalExpCS is added by Issue 14196) [F] PrimitiveLiteralExpCS ::= NullLiteralExpCS [G] PrimitiveLiteralExpCS ::= InvalidLiteralExpCS and [F] PrimitiveLiteralExpCS.ast = NullLiteralExpCS.ast [G] PrimitiveLiteralExpCS.ast = InvalidLiteralExpCS.ast
Actions taken:
August 29, 2009: received issue
April 25, 2011: closed issue

Issue 14357: OCL 2.1 Resolution of missing Concrete Syntaxes and Reserved Words (ocl2-rtf)

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


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


Define the concrete syntax of RealLiteralExpCS and IntegerLiteralExpCS.


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

Resolution:
Revised Text: At the end of 7.4 add Multiple adjacent strings are concatenated allowing a long string to be specified on multiple lines. 'This is a ' 'concatenated ''string' -- 'This is a concatenated string' Unicode characters are used within single quoted sequences, with the following backslash based escape sequences used to define backslash and other characters. \b -- backspace \t -- horizontal tab \n -- linefeed \f -- form feed \r -- carriage return \" -- double quote \' -- single quote \\ -- backslash \xhh -- #x00 to #xFF \uhhhh -- #x0000 to #xFFFF where h is a hex digit: 0 to 9, A to F or a to f. Reserved words such as true and arbitrary awkward spellings may be used as names by enclosing the name in underscore-prefixed single quotes. self._'if' = _'tabbed\tvariable'._'spaced operation'() In 7.4.8 replace is conceptually equal to the expression: a.+(b) by is equivalent to the expression: a._'+'(b) In the first paragraph of Section 9.3 replace As a convention to the concrete syntax, conflicting properties or conflicting class names can be aliased using the �_� (underscore) prefix. Inside an OCL expression that is written with the concrete syntax, when a property name or a class name is found to start with a �_�, firstly the symbol is lookup in the metamodel. If not found, the same symbol with the �_� skipped is tried. by In the concrete syntax, names that are reserved words or include punctuation characters can be used by enclosing the required name in underscore-prefixed single quotes. _'and' _'>=' [In OCL 2.0 and 2.1 a reserved word could be used as a name after prefixing it with an underscore. _and The subsequent symbol lookup would look first for the spelling with an underscore in the meta-model and if that was not found would attempt a further lookup after removing the underscore. This behaviour was indeterminate, could not access names that existed both with and without prefixes, and did not support punctuation characters. The simple underscore prefix is therefore deprecated in OCL 2.3 and will be removed in OCL 3.0.] In 9.3 simpleNameCS replace The exact syntax of a String is undefined in UML 1.4, and remains undefined in OCL 2.0. The reason for this is internationalization. simpleNameCS ::= <String> Abstract syntax mapping simpleNameGr.ast : String Synthesized attributes simpleNameGr.ast = <String> Inherited attributes -- none Disambiguating rules -- none by The abstract syntax of a simpleNameCS String is undefined in UML 2.3, and so is undefined in OCL 2.3. The reason for this is internationalization. The concrete syntax of a simpleNameCS String supports a Unicode letter-prefixed identifier (form [A]). Reserved words and names involving awkward characters such as punctuation may be specified by prefixing a String Literal with an '_' (form [B] and [C]). [A] simpleNameCS ::= NameStartChar NameChar* [B] simpleNameCS ::= '_' #x27 StringChar* #x27 [C] simpleNameCS[1] ::= simpleNameCS[2] WhiteSpaceChar* #x27 StringChar* #x27 The identifier form starts with a Unicode letter: NameStartChar ::= [A-Z] | "_" | "$" | [a-z] | [#xC0-#xD6] | [#xD8-#xF6] | [#xF8-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF] and may continue with a Unicode letter or digit. NameChar ::= NameStartChar | [0-9] The StringChar form is defined under StringLiteralExpCS. Example simpleNameCS values are: String i3 a?et? MAX_VALUE isLetterOrDigit _'true' _'>=' _'\'' Abstract syntax mapping simpleNameCS.ast : String Synthesized attributes [A] simpleNameCS.ast = <CodePoints of NameStartChar NameChar*> [B] simpleNameCS.ast = <CodePoints of StringChar*> [C] simpleNameCS[1].ast = simpleNameCS[2] + <CodePoints of StringChar*> Inherited attributes -- none Disambiguating rules [1] [A] the character, if any, following the last NameChar is not a NameChar. [2] [A] simpleNameCS.ast is not a reserved word [3] [B] No whitespace is permitted between the '_' and the first NameChar. [4] [C] simpleNameCS[2] is a simpleNameCS [B] or [C]. In 9.3 IntegerLiteralExpCS replace This rule represents integer literal expressions. IntegerLiteralExpCS ::= <String> ... Synthesized attributes IntegerLiteralExpCS.ast.integerSymbol = <String>.toInteger() by This rule represents integer literal expressions. The lexical representation of an integer is a sequence of at least one of the decimal digit characters, without a leading zero; except that a single leading zero character is required for the zero value. IntegerLiteralExpCS ::= <Integer Lexical Representation> ... Synthesized attributes IntegerLiteralExpCS.ast.integerSymbol = <Integer Value> In 9.3 RealLiteralExpCS replace This rule represents real literal expressions. RealLiteralExpCS ::= <String> ... Synthesized attributes RealLiteralExpCS.ast.realSymbol = <String>.toReal() by This rule represents real literal expressions. A real literal consists of an integer part, a fractional part and an exponent part. The exponent part consists of either the letter 'e' or 'E', followed optionally by a '+' or '-' letter followed by an exponent integer part. Each integer part consists of a sequence of at least one of the decimal digit characters. The fractional part consists of the letter '.' followed by a sequence of at least one of the decimal digit characters. Either the fraction part or the exponent part may be missing but not both. RealLiteralExpCS ::= <Real Lexical Representation> ... Synthesized attributes RealLiteralExpCS.ast.realSymbol = <Real Value> In 9.3 StringLiteralExpCS replace This rule represents string literal expressions. StringLiteralExpCS ::= �<String> � ... Synthesized attributes StringLiteralExpCS.ast.symbol = <String> by This rule represents string literal expressions. The concrete syntax comprises a sequence of zero or more characters or escape sequences surrounded by single quote characters. The [B] form with adjacent strings allows a long string literal to be split into fragments or to be written across multiple lines. [A] StringLiteralExpCS ::= #x27 StringChar* #x27 [B] StringLiteralExpCS[1] ::= StringLiteralExpCS[2] WhiteSpaceChar* #x27 StringChar* #x27 where StringChar ::= Char | EscapeSequence WhiteSpaceChar ::= #x09 | #x0a | #x0c | #x0d | #x20 Char ::= [#x20-#x26] | [#x28-#x5B] | [#x5D-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] EscapeSequence ::= '\' 'b' -- #x08: backspace BS | '\' 't' -- #x09: horizontal tab HT | '\' 'n' -- #x0a: linefeed LF | '\' 'f' -- #x0c: form feed FF | '\' 'r' -- #x0d: carriage return CR | '\' '"' -- #x22: double quote " | '\' ''' -- #x27: single quote ' | '\' '\' -- #x5c: backslash \ | '\' 'x' Hex Hex -- #x00 to #xFF | '\' 'u' Hex Hex Hex Hex -- #x0000 to #xFFFF Hex ::= [0-9] | [A-F] | [a-f] Synthesized attributes [A] StringLiteralExpCS.ast.symbol = <CodePoints of StringChar*> [B] StringLiteralExpCS.ast.symbol = StringLiteralExpCS[2] + <CodePoints of StringChar*> In 9.3 OperationalCallExpCS remove [3] [C] The name of the referred Operation cannot be an operator. Set{�+�,�-�,�*�,�/�,�and�,�or�,�xor�,�=�,�<=�,�>=�,�<�,�>�}->excludes(simpleNameCS.ast) At the end of 9.4.1 add In OCL 2.0 and 2.1 a reserved word could be used as a name after prefixing it with an underscore. Therefore, for compatibility, a lookup of simpleNameCS[A] name with a leading underscore may need to be looked up twice. The symbol is first looked up in the meta-model with the underscore prefix, and if no value is found, the symbol is looked up gain without the underscore prefix. A double lookup is not required for a simpleNameCS[B] or [C] name (an underscore-prefixed singly quoted string). The second lookup after removing the underscore prefix is deprecated in OCL 2.3 and will be discontinued in OCL 3.0. Tool implementors should provide a warning message for this deprecated usage.
Actions taken:
September 10, 2009: received issue
April 25, 2011: closed issue

Discussion:

See Issue 14583 for a resolution of reserved words and definition of
reservedKeywordCS.
Numbers
A valid integer literal should have no leading zeroes to avoid confusion with
languages that use leading zeroes to indicate octal.
A valid integer (or real) literal should have no leading sign; a unary minus may be
used to create negative values. If a leading minus is part of a number, there is a
problem parsing "5-4" after tokenising as UnlimitedNatural(5) Integer(-4) rather
than UnlimitedNatural(5) Letter(-) UnlimitedNatural(4).
A valid real literal should not have a leading or trailing dot to avoid confusion with
a dot or dot dot operator. e.g. "1..2" should be a collection range rather than "1."
and ".2". Prohibiting the edge dots avoids the ambiguity.
63
Strings
OCL 2.1 defines a string as a character string surrounded by single quotes, but
defines no mechanism for defining a single quote. It is unclear how non-printable
characters such as new-lines should be interpreted within strings, or how nonprintable
characters can be specified in the concrete syntax without causing
problems with text editors and other tools that provide special treatment for nonprintable
characters.
QVT 1.0 Operational Mappings defines a number of Java-inspired extensions,
although it applies Unicode escapes in the Concrete Syntax mapping rather than
the character serialisation. QVTo also defines concatenation of adjacent strings.
Adoption of Java-like escape sequences solves the problem of awkward
characters, although support for octal sequences seems unnecessary in modern
languages; the QVTo specification of octal sequences is flawed ('\111" has three
valid meanings).
Concatenation of adjacent strings is useful.
Introduction of \ as an escape character changes the semantics of '\' which in
OCL 2.0 and 2.1 was a valid string defining a single backslash character,
although many practical OCL 2.0 tools may have anticipated this specification of
backslash sequences.
Identifiers
UML places no constraints on identifier spellings. OCL 2.1 in 9.3 simpleNameCS
echoes this lack of constraint, but fails to identify how the arbitrary Abstract
Syntax can be realised in the Concrete Syntax.
Punctuation should not ever be a valid name in the Concrete Syntax. 9.3
OperationCallExpCS disambiguating rule 3 specifically prohibits the 'conceptual'
example in 7.4.8.
A valid Concrete Syntax name should use a Unicode variant of a letter then
letter-or-digit identifier.
An arbitrary Abstract Syntax name should be expressible by enclosing the
correspondingly arbitrary character sequence in some form of quotes, using
Java-like escaping definitions for awkward characters. The 'conceptual' example
in 7.4.8 should therefore be valid using a quoted form.
64
OCL 2.1 uses single quotes, and although OCL 2.1 does not define any
semantics for double quotes, derived languages uch as QVTo do. It is therefore
appropriate to use the existing underscore prefix for reserved words to prefix a
singly quoted string and so convert the string literal to an identifier. This
accommodates any spelling and since the need for conversion is rare the
clumsiness of three characters is acceptable.
9.3 OperationCallExpCS disambiguating rule 3 should therefore prohibit only
unquoted punctuation and reserved words. a.+(b) or a.and(b) is invalid, but
a._'+'(b) or a._'and'(b) is valid. The prohibition is therefore on the reserved
spelling rather than the use of the referenced operation.
A similar escaping mechanism should apply to awkward characters as defined
for single quoted strings, so that the \= operation can be invoked as a._'\\='(b).
Since the underscore-prefixed single quotes supports any awkward characters,
the OCL 2.0 and 2.1 underscore identifier prefix is redundant. In view of the
inadequacies highlighted in 14224 and the need to avoid the underscore prefix
syntax applying within _'_self', it is appropriate to deprecate the old underscore
prefix with a view to removing it in OCL 3.0.

Issue 14582: OCL 2.1 7.4.7 Inconsistent Operator Associativity and Precedence (ocl2-rtf)

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

Issue 11098 resolved the missing precedence of let-in as lowest. This requires "2 * let a:Integer=1 in a + 1" to be interpreted as "(2 * (let a:Integer=1 in a)) + 1" making use of a non-trivial let body surprising and needlessly complicated. The problem with the open-ended right hand side can be resolved by assigning let-in the highest atomic expression precedence and defining its resolution as right-associative. The above example then has the obvious meaning "2 * (let a:Integer=1 in (a + 1))".

Issue 6544 introduces ^ and ^^ at higher precedence than . and ->. However since these operators can only return left hand arguments for each other, there is no need to assign these to different levels.

if-then-else-endif has an intermediate precedence in OCL 2.1. Since this term has keywords at start and end, the term is equivalent to an atomic expression. In so far as precedence is meaningful it is a high precedence.

Parentheses should be bulletted at high precedence.

Non commutative operators such as / have no defined order of evaluation leaving the value of "8 / 4 / 2" undefined. Binary operators should be specified as left-associative; i.e "(8 / 4) / 2".

Section 9.3.2 duplicates 7.4.7.

Resolution:
Revised Text: In 7.4.7 replace � message-expression operators: "^" and "^^" � dot and arrow operations: �.� and �->� by � call expressions: "^","^^", �.� and �->� In 7.4.7 remove � �if-then-else-endif� and � �let-in� then add � literal and variable expressions, �(� and �)�, �if-then-else-endif� � �let-in� above � @pre In 7.4.7 replace Parentheses �(� and �)� can be used to change precedence. by � �in� All infix operators are left associative, equal precedence operators are evaluated left to right. A let expression is both high precedence and low precedence; high on the left so that a let expression behaves as an atomic value in operations, low on the right so that the in-expression can be an arbitrary expression. "a + let ... in a + let ... in a + a" is "a + (let ... in (a + (let ... in (a + a))))". Parentheses �(� and �)� can be used to change precedence and associativity. Remove Section 9.3.2
Actions taken:
October 27, 2009: received issue
April 25, 2011: closed issue

Discussion:

A non-duplicate replacement for 9.3.2 appears as a practical grammar provided
in the resolution to Issue 10439.
right-associativity is perhaps not the correct word for the hybrid behaviour of letin
that is very high precedence on the left for "let" but very low precedence on the
right for "in" to allow the let body to be an arbitrary expression.

Issue 14583: OCL 2.1 7.4.9 true, self, Bag and String are not reserved words (ocl2-rtf)

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

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


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

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

Resolution:
Revised Text: In 7.4.9 replace That means that the keywords cannot occur anywhere in an OCL expression as the name of a package, a type, or a property. by That means that the keywords cannot occur as a name. A reserved word may be used as the name of a package, a type, a feature, a variable or a constraint by enclosing the word in underscore-prefixed single quotes. Add to 7.4.9 retaining alphabetical order false invalid null self true At the end of 7.4.9 add The following words are restricted. A restricted word can only be used as a name when preceded by a "::". A restricted word may also be used by enclosing the word in underscore-prefixed single quotes. Bag Boolean Collection Integer OclAny OclInvalid OclMessage OclVoid OrderedSet Real Sequence Set String Tuple UnlimitedNatural Note that operation names such as iterate, forAll, and oclType, are not reserved or restricted. In 9.3 VariableExpCS replace A variable expression is just a name that refers to a variable. VariableExpCS ::= simpleNameCS ... VariableExpCS.ast.referredVariable = env.lookup(simpleNameCS.ast).referredElement.oclAsType(VariableDeclaration) ... [1] simpleName must be a name of a visible VariableDeclaration in the current environment env.lookup (simpleNameCS.ast).referredElement.oclIsKindOf (VariableDeclaration) by A variable expression is just a name that refers to a variable or self. [A] VariableExpCS ::= simpleNameCS [B] VariableExpCS ::= 'self' ... [A] VariableExpCS.ast.referredVariable = env.lookup(simpleNameCS.ast).referredElement.oclAsType(VariableDeclaration) [B] VariableExpCS.ast.referredVariable = env.lookup('self').referredElement.oclAsType(VariableDeclaration) ... [1] [A] simpleNameCS must be a name of a visible VariableDeclaration in the current environment env.lookup (simpleNameCS.ast).referredElement.oclIsKindOf (VariableDeclaration) In 9.3 add restrictedKeywordCS This production rule represents any name that is not a reserved keyword. [A] restrictedKeywordCS ::= CollectionTypeIdentifierCS [B] restrictedKeywordCS ::= primitiveTypeCS [C] restrictedKeywordCS ::= oclTypeCS [D] restrictedKeywordCS ::= 'Tuple' Abstract syntax mapping restrictedKeywordCS.ast : String Synthesized attributes [A] restrictedKeywordCS.ast = CollectionTypeIdentifierCS.ast.name [B] restrictedKeywordCS.ast = primitiveTypeCS.ast.name [C] restrictedKeywordCS.ast = oclTypeCS.ast.name [D] restrictedKeywordCS.ast = 'Tuple' Inherited attributes -- none Disambiguating rules -- none In 9.3 add unreservedSimpleNameCS This production rule represents any name that is not a reserved keyword. [A] unreservedSimpleNameCS ::= simpleNameCS [B] unreservedSimpleNameCS ::= restrictedKeywordCS Abstract syntax mapping unreservedSimpleNameCS.ast : String Synthesized attributes [A] unreservedSimpleNameCS.ast = simpleNameCS.ast [B] unreservedSimpleNameCS.ast = restrictedKeywordCS.ast Inherited attributes -- none Disambiguating rules -- none In 9.3 pathNameCS replace pathNameCS ::= simpleNameCS (�::� pathNameCS )? ... pathNameCS.ast = Sequence{simpleNameCS.ast}->union(pathNameCS.ast) by [A] pathNameCS ::= simpleNameCS [B] pathNameCS ::= pathNameCS �::� unreservedSimpleNameCS ... [A] pathNameCS.ast = Sequence{simpleNameCS .ast} [B] pathNameCS.ast = pathNameCS.ast->append(unreservedSimpleNameCS.ast) In 9.3 add primitiveTypeCS This production rule denotes a primitive type. Abstract syntax mapping [A] primitiveTypeCS ::= 'Boolean' [B] primitiveTypeCS ::= 'Integer' [C] primitiveTypeCS ::= 'Real' [D] primitiveTypeCS ::= 'String' [E] primitiveTypeCS ::= 'UnlimitedNatural' Synthesized attributes [A] primitiveTypeCS.ast = Boolean [B] primitiveTypeCS.ast = Integer [C] primitiveTypeCS.ast = Real [D] primitiveTypeCS.ast = String [E] primitiveTypeCS.ast = UnlimitedNatural Inherited attributes -- none Disambiguating rules -- none oclTypeCS This production rule denotes a built-in OCL type. Abstract syntax mapping [A] oclTypeCS ::= 'OclAny' [B] oclTypeCS ::= 'OclInvalid' [C] oclTypeCS ::= 'OclMessage' [D] oclTypeCS ::= 'OclVoid' Synthesized attributes [A] oclTypeCS.ast = OclAny [B] oclTypeCS.ast = OclInvalid [C] oclTypeCS.ast = OclMessage [D] oclTypeCS.ast = OclVoid Inherited attributes -- none Disambiguating rules -- none In 9.3 TypeCS replace A typename is either a Classifier, or a collection of some type. by A typename is either a reserved type, or a Classifier, or a collection of some element type, or a tuple of some element types. In 9.3 TypeCS add [D] typeCS ::= primitiveTypeCS [E] typeCS ::= oclTypeCS ... [D] typeCS.ast = primitiveTypeCS.ast [E] typeCS.ast = oclTypeCS.ast In 13.2 add 3: The following operations do not form part of Essential OCL @pre ^^ ^ 4. The following names are not reserved or restricted in Essential OCL OclMessage body context def derive endpackage init inv package post pre static
Actions taken:
October 27, 2009: received issue
April 25, 2011: closed issue

Discussion:

and, else, endif, if, implies, in, let, not, or, then, xor
These are defined as reserved words in OCL 2.1.
No change; these words should be reserved for Essential OCL.
body, context, def, derive, endpackage, init, inv, package, post, pre, static
These are defined as reserved words in OCL 2.1. There is no need for these to
be reserved words in Essential OCL and consequently in derived languages such
as QVT.
Change; these words to be reserved for Complete OCL only.
false, invalid, null, self, true
These are not defined as reserved words in OCL 2.1 although the grammar
clearly uses them in reserved ways. This is very unusual. For instance true, false,
self/this are reserved in Java/C++.
If literal expression keywords are not reserved, a syntax mechanism to defeat the
occlusion by an implicit source property is required, allowing a reference to
perhaps ::true.
It is possible to define a grammar in which all ambiguous usage favours these
words, so that self::true comprises non-reserved names; very strange. Better to
reserve the names and simplify tooling and readability.
Change; these words should be reserved for Essential OCL.
Boolean, Integer, Real, String, UnlimitedNatural, OclAny, OclInvalid,
OclMessage, OclVoid
These are not defined as reserved words in OCL 2.1 although the grammar
again uses them in reserved ways. This is very unusual. For instance
boolean/bool, int, double, void are reserved in Java/C++.
It seems very undesirable that a nested environment should be able to occlude
resolution of a primitive type name and very confusing that such a name should
be used as a property name. Therefore the primitive type names should be
reserved and therefore always visible rather than selectively visible from a root
environment. If occlusion is permitted, a syntax mechanism to defeat the
occlusion would be required, allowing a reference to perhaps ::Integer.
It is possible to define a grammar in which all ambiguous usage favours these
words, so that Integer::String comprises non-reserved names; very strange.
However My::String seems reasonable and clear. This can be accommodated by
a restricted keyword concept; a restricted keyword may only be used following
a ::.
Change; Boolean, Integer, Real, String, UnlimitedNatural, OclAny, OclInvalid,
OclVoid to be restricted for Essential OCL.
Change; OclMessage to be restricted for Complete OCL only.
Bag, Collection, OrderedSet, Sequence, Set, Tuple
These are not defined as reserved words in OCL 2.1 although the grammar
again uses them in reserved ways. This is unusual. For instance class, struct,
union are reserved in Java/C.
The non-reserved status of the collection type names currently causes only minor
parsing difficulties. Problems are avoidable because the () clause is
unambiguous for type names and the {} clause is unambiguous for literals.
However if Issue 12953 is resolved to allow the collection literal syntax to be
enhanced to allow specification of an element type, such as Bag(String){}, it
becomes difficult for a parser to distinguish the prefix from an implicit source
operation call. Better to restrict the names and simplify tooling and readability.
Change; Bag, Collection, OrderedSet, Sequence, Set, Tuple to be restricted for
Essential OCL.
iterate, forAll, oclIsNew, oclIsInState etc
These are not defined as reserved words in OCL 2.1, although the grammar
again appears to use them in reserved ways.
The apparently reserved usage is very dependent on exact signatures and so
non-reserved usage is also permitted. These words are OCL Standard Library
features rather than types and consequently much more prone to extension in
future specifications.
No change; the grammar should accommodate non-reserved behaviour.
Reserved word corrolaries : primitive type names
In OCL 2.1, primitive type names are not distinct from simpleNameCS and so a
pathNameCS covers a primitive type name. Once primitive type names are
reserved it is necessary first to introduce primitiveTypeCS and oclTypeCS, and
then to use it.
primitiveTypeCS ::= 'Boolean'
primitiveTypeCS ::= 'Integer'
primitiveTypeCS ::= 'Real'
primitiveTypeCS ::= 'String'
primitiveTypeCS ::= 'UnlimitedNatural'
oclTypeCS ::= 'OclAny'
oclTypeCS ::= 'OclInvalid'
oclTypeCS ::= 'OclMessage'
oclTypeCS ::= 'OclVoid'
typeCS ::= primitiveTypeCS
typeCS ::= oclTypeCS
Reserved word corrolaries : self
In OCL 2.1, self is not distinct from a simpleNameCS. This is not true once self is
reserved. It therefore necessary to add
VariableExpCS ::= 'self'
Restricted word corrolaries
Support for restricted keywords needs a definition of restrictedKeywordCS and a
reference to it.
restrictedKeywordCS ::= CollectionTypeIdentifierCS
restrictedKeywordCS ::= primitiveTypeCS
restrictedKeywordCS ::= oclTypeCS
restrictedKeywordCS ::= 'Tuple'
unreservedSimpleNameCS ::= simpleNameCS
unreservedSimpleNameCS ::= restrictedKeywordCS
pathNameCS ::= simpleNameCS
pathNameCS ::= pathNameCS '::' unreservedSimpleNameCS

Issue 14584: OCL 2.1 9.3 Inferred TupleLiteralExp part type (ocl2-rtf)

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

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


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


However neither 8.3.7 nor 9.3 specifies this inference.


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

Resolution: The synthesized attributes for VariableDeclarationCS should infer when possible.
Revised Text: In Section 9.3 VariableDeclarationCS Synthesized attributes replace (accommodating Issue 14197's resolution of OclUndefined as invalid). VariableDeclarationCS.ast.type = if typeCS->notEmpty() then typeCS.ast else OclUndefined endif by VariableDeclarationCS.ast.type = if typeCS->notEmpty() then typeCS.ast else if VariableDeclarationCS.ast.initExpression.empty() then VariableDeclarationCS.ast.initExpression.type else null endif endif
Actions taken:
October 27, 2009: received issue
April 25, 2011: closed issue

Issue 14585: OCL 2.1 9.3 Missing TypeLiteralExpCS (ocl2-rtf)

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

The expression


'a'.oclAsType(String)


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


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


Syntactically:


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


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


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

Resolution: In 9.3 LiteralExpCS add [E] LiteralExpCS ::= TypeLiteralExpCS and [E] LiteralExpCS.ast = TypeLiteralExpCS.ast and [E] TypeLiteralExpCS.env = LiteralExpCS.env In 9.3 add TypeLiteralExpCS This production rule references a type name. Abstract syntax mapping TypeLiteralExpCS ::= typeCS Synthesized attributes TypeLiteralExpCS.ast = typeCS.ast Inherited attributes typeCS.env = TypeLiteralExpCS.env Disambiguating rules -- none
Revised Text:
Actions taken:
October 28, 2009: received issue
April 25, 2011: closed issue

Discussion:

A TypeLiteralExpCS whose value is a typeCS is required.
LiteralExpCS ::= TypeLiteralExpCS
TypeLiteralExpCS ::= typeCS
This allows any type, albeit with a parsing ambiguity for pathNameCS. This can
be resolved by flattening typeCS and excluding the pathNameCS.
This extension allows Set{'a'}.oclAsType(Set(OclAny)) to be parsed.

Issue 14586: OCL 2.1 12.2.5 named-self classifierContextDeclCS (ocl2-rtf)

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

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


context c : Company inv:
   c.numberOfEmployees > 50

Resolution: In 12.12.2 classifierContextDeclCS replace This production rule represents a context declaration for expressions that can be coupled to classifiers. classifierContextDeclCS ::= �context� pathNameCS invOrDefCS by This production rule represents a context declaration for expressions that can be coupled to classifiers. The variable declaration to the classifier context is 'self' for the A form and explicitly specified for the B form. [A] classifierContextDeclCS ::= �context� pathNameCS invOrDefCS [B] classifierContextDeclCS ::= �context� simpleNameCS ':' pathNameCS invOrDefCS
Revised Text:
Actions taken:
October 28, 2009: received issue
April 25, 2011: closed issue

Issue 14587: OCL 2.1 12.2.3 Incomplete resolution of Issue 9796 for attrOrAssocContextCS (ocl2-rtf)

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

When Issue 9796 updated terminology to use PropertyCallExpCS, attrOrAssocContextCS should have been updated to propertyContextCS.

Resolution: In 12.12.2 contextDeclarationCS replace [A] contextDeclarationCS ::= attrOrAssocContextCS by [A] contextDeclarationCS ::= propertyContextDeclCS Replace 12.12.3 attrOrAssocContextCS This production rule represents a context declaration for expressions that can be coupled to an attribute or association end. The path name refers to the �owner� of the attribute or association end, the simple name refers to its name, the type states its type. attrOrAssocContextCS ::= �context� pathNameCS �::� simpleName�:� typeCS initOrDerValueCS by 12.12.3 propertyContextDeclCS This production rule represents a context declaration for expressions that can be coupled to a property. The path name refers to the �owner� of the property, the simple name refers to its name, the type states its type. propertyContextDeclCS ::= �context� pathNameCS �::� simpleName�:� typeCS initOrDerValueCS
Revised Text:
Actions taken:
October 28, 2009: received issue
April 25, 2011: closed issue

Issue 14881: Undefined operation tail() (ocl2-rtf)

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

subclause [4]


It reads:  names->tail()


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

Rationale: tail() is not an operation of Sequence

Resolution:
Revised Text: In Section 9.4.1 [4] replace names->tail() by names->subSequence(2, names->size())
Actions taken:
December 19, 2009: received issue
April 25, 2011: closed issue

Discussion:

Since there is no head() operation, it is not obvious that a tail() operation is merited.

Issue 14882: Undefined operation tail() (ocl2-rtf)

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

(Related to Issue 7539)


 It reads:  isOclKind


 It should read: oclIsKindOf

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

Resolution:
Revised Text: In Section 9 and 10 replace three references to isOclKind by oclIsKind Verify that neither �isOcl� nor �asOcl� survive anywhere other than Annex A.
Actions taken:
December 19, 2009: received issue
April 25, 2011: closed issue

Discussion:

Continuing on from the Issue 14094 resolution: This typo occurs once in Section 9.4.1
and twice in Section 10.

Issue 14883: Undefined operation tail() on p 130 (ocl2-rtf)

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

Related to Issue 7539)


 It reads:  isOclKind


 It should read: oclIsKindOf

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

Resolution: This typo is addressed by Issue 14882 Disposition: Merged
Revised Text:
Actions taken:
December 19, 2009: received issue
April 25, 2011: closed issue

Issue 15005: OCL 2.1 8.3.8 OclInvalid::allInstances (ocl2-rtf)

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

8.3.8 states that in regard to allInstances


"returns all instances of the classifier and the classifiers specializing it. May only be used for classifiers that have a finite
number of instances. This is the case, for example, for user defined classes because instances need to be created explicitly,
and for enumerations, the standard Boolean type, and other special types such as OclVoid and OclInvalid."


While it is true that OclInvalid has exactly one instance, the corresponding return of Set{invalid} is not well-formed.


Therefore the invocation OclInvalid.allInstances() must return invalid.


Suggest:


Replace "and OclInvalid" by ". But not for OclInvalid, for which the return is invalid"

Resolution:
Revised Text: In 8.2.2 replace Well-formedness Rules for the Types Package by Operations and Well-formedness Rules for the Types Package In 8.2.2 add BooleanType allInstances() : Set(Boolean) Returns Set{true,false}. In 8.2.2 add InvalidType allInstances() : Set(OclInvalid) Returns invalid, since the notional return of Set{invalid} is not well-formed. In 8.2.2 add VoidType allInstances() : Set(OclVoid) Returns Set{null}. In the last paragraph of 8.3.8 Classifier replace and other special types such as OclVoid and OclInvalid. by and other special types such as OclVoid.
Actions taken:
January 25, 2010: received issue
April 25, 2011: closed issue

Discussion:

As summarised, the consistent return of Set{invalid} is not well-formed so the actual
return must be invalid, which the text should indicate.
Migration of allInstances to Classifier by Issue 6532 has left it undefined for non-
Classifiers

Issue 15134: String.equalsIgnoreCase(String) should result in Boolean (ocl2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Len Charest, nobody)
Nature: Revision
Severity: Significant
Summary:

OCL 2.2 defines equalsIgnoreCase as returning an Integer. Given that the operation determines equivalence of two Strings, I would expect it to return Boolean: either the strings are equivalent (true) or they are not (false).

Resolution:
Revised Text: In 11.5.1 Real replace equalsIgnoreCase(s : String) : Integer Queries whether s and self are equivalent under case-insensitive collation in the locale of self. by equalsIgnoreCase(s : String) : Boolean Queries whether s and self are equivalent under case-insensitive collation. post: result = (self.toUpperCase() = s.toUpperCase())
Actions taken:
March 17, 2010: received issue
April 25, 2011: closed issue

Discussion:

The OCL 2.2 definition provides no indication as to what the Integer return might signify,
the definition is therefore useless.
Presumably the intent is to provide similar functionality to Java's
java.lang.String.equalsIgnoreCase(String) : Boolean.

Issue 15222: OCL 2.2 11.7.1 Why must + be associative for Collection::sum() (ocl2-rtf)

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

Collection::sum() requires that its T::+() is commutative and associative.


Associativity is necessary for predictable results.


However what if it isn't?


Is there an obligation on the OCL runtime to detect non-associativity and return invalid?
- probably not possible.


Is there a permission on the OCL runtime to detect non-associativity and return invalid?
- difficult to ensure implementation portability


Is there just an informal caution to users that non-associativity may lead to unpredictable results?


Suggest: reword to permit an implementation to return invalid and caution users about unpredictable results.

Resolution:
Revised Text: At the end of 11.6.1 Collection, sum() : T insert If the + operation is not both associative and commutative, the sum expression is not well-formed, which may result in unpredictable results during evaluation. If an implementation is able to detect a lack of associativity or commutativity, the implementation may bypass the evaluation and return an invalid result.
Actions taken:
April 23, 2010: received issue
April 25, 2011: closed issue

Discussion:

No. Both associativity and commutativity are necessary for predictable results on
arbitrary collections. (Issue 15223 relaxes both for ordered collections.)
Yes. It does not seem reasonable to require an implementation to detect a lack of
associativity or commutativity, so reword to permit and warn as suggested.

Issue 15223: OCL 2.2 11.7.1 Why must + be commutative for Collection::sum() (ocl2-rtf)

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

Collection::sum() requires that its T::+() is commutative and associative.


Associativity is necessary for predictable results.


Commutativity is not necessary, most trivially for String::+ for which sum() could usefully
concatenate an OrderedSet.


Suggest: remove the requirement for commutativity.

Resolution:
Revised Text: In 11.6.3 OrderedSet and 11.6.5 Sequence add sum() : T Redefines the Collection operation to remove the requirement for the + operation to be associative and/or commutative, since the order of evaluation is well-defined by the iteration over an ordered collection.
Actions taken:
April 23, 2010: received issue
April 25, 2011: closed issue

Discussion:

Yes. Introduction of String::+() as a shorthand for String::concat() makes the
suggestion a natural extension, but only for OrderedCollections.
No. Neither associativity nor commutativity is necessary for OrderedCollections

Issue 15224: OCL 2.2 11.5.3 What is a locale? (ocl2-rtf)

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

The new toUpperCase, toLowerCase and equalsIgnoreCase refer to case conversion if appropriate to the locale without ever defining what a locale is or defining the preconditions for appropriateness.


These methods closely resemble Java Library methods, perhaps they should reference rather than duplicate the Java specification.


The Java toUpperCase method provides locale-dependent and local-independent variants.


Is it right for OCL to make it difficult to achieve predictable results under a Turkish locale?


It seems that the OCL standard library must provide access to the Locale and provide both Java's toUpperCase variants.

Resolution:
Revised Text: At the end of 11.1 add Certain String operations depend on the prevailing locale to ensure that Strings are collated and characters are caseconverted in an appropriate fashion. A locale is defined as a concatenation of up to three character sequences separated by underscores, with the first sequence identifying the language and the second sequence identifying the country. The third sequence is empty but may encode an implementation-specific variant. Trailing empty strings and separators may be omitted. The character sequences for languages are defined by ISO 639. The character sequences for countries are defined by ISO 3166. 'fr_CA' therefore identifies the locale for the French language in the Canada country. Comparison of strings and consequently the collation order of Collection::sortedBy() conforms to the Unicode Collation algorithm defined by Unicode Technical Standard#10. The locale is 'en_us' by default but may be configured by a property constraint on OclAny::oclLocale. The prevailing locale is defined by the prevailing value of oclLocale within the current environment; it may therefore be changed temporarily by using a Let expression. let oclLocale : String = 'fr_CA' in aString.toUpperCase() At the end of 11.2.5 add oclLocale : String Defines the default locale for local-dependent library operations such as String::toUpperCase(). In 11.4.3 String add < (s : String) : Boolean True if self is less than s, using the locale defined by looking up oclLocale in the current environment. > (s : String) : Boolean True if self is greater than s, using the locale defined by looking up oclLocale in the current environment. post: result = not (self <= s) <= (s : String) : Boolean True if self is less than or equal to s, using the locale defined by looking up oclLocale in the current environment. post: result = ((self = s) or (self < s)) >= (s : String) : Boolean True if self is greater than or equal to s, using the locale defined by looking up oclLocale in the current environment. post: result = ((self = s) or (self > s)) In 11.4.3 String toUpperCase() replace if appropriate to the locale by using the locale defined by looking up oclLocale in the current environment. In 11.4.3 String toLowerCase() replace if appropriate to the locale by using the locale defined by looking up oclLocale in the current environment.
Actions taken:
April 23, 2010: received issue
April 25, 2011: closed issue

Discussion:

Introduction of a Locale class into the OCL Standard Library to allow a Locale to
be passed as an additional argument to all locale-dependent functions is a rather
heavyweight solution to this problem.
It seems much simpler to define OclAny::oclLocale as the default locale, with
oclLocale in the current context as the prevailing locale so that users may
temporarily change locale using a let expression.
(Issue 15134 corrects the 'locale' reference in equalsIgnoreCase).

Issue 15235: OCL 2.2 UML Alignment of association names (ocl2-rtf)

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

In accordance with Nicolas Rouquette's observations in the discussion on "15233 -- OCL 2.2 Correction to Issue 9796 for AssociationEndCall":

The problem with OCL 2.2, Fig 7.1 are: 
- give a name to the association end near Bank, e.g. 'bankAccount'
- fix the multiplicity of: Person::bankAccount from 0..1 to * -- i.e., a person can have zero or more bank accounts!
- fix the multiplicity of Bank::customer from 0..* to 0..1 -- i.e., there is zero or one customer for a given 'accountNumber' value.
- give a name to the association itself, e.g., BankAccount, or, if you want to use the UML notation convention, A_customer_bankAccount

and

The OCL examples for Figure 7.2, currently: 


context Person inv: self.employeeRanking[bosses]->sum() > 0 
context Person inv: self.employeeRanking[employees]->sum() > 0 
context Person inv: self.employeeRanking->sum() > 0 -- INVALID! 
context Person inv: self.job[employer] 


should be fixed to:


context Person inv: self.EmployeeRanking[bosses]->sum() > 0 
context Person inv: self.EmployeeRanking[employees]->sum() > 0 
context Person inv: self.EmployeeRanking->sum() > 0 -- INVALID! 
context Person inv: self.Job[employer] 


That is, 'EmployeeRanking' is the name of the association shown in Fig 7.2
That figure does not have anything called 'employeeRanking' and it is misleading to suggest that in OCL the name of the association could be written with a lowercase initial letter when the name of the association itself has an initial capital letter. Since lexical names are case-sensitive in both UML and OCL, case-sensitivity should be respected to avoid creating confusion and potential ambiguity with other names that are lexically different only by their upper/lower case letter.

and


In particular, the text in clause 7.5.4 about using the name of an association class with a lowercase initial letter should be removed.
That is, change the following, currently:


To specify navigation to association classes (Job and Marriage in the example), OCL uses a dot and the name of the association class starting with a lowercase character: 


context Person inv: self.job 


The sub-expression self.job evaluates to a Set of all the jobs a person has with the companies that are his/her employer. In the case of an association class, there is no explicit rolename in the class diagram. The name job used in this navigation is the name of the association class starting with a lowercase character, similar to the way described in the sub clause �Missing AssociationEnd names� above. 


to:


To specify navigation to association classes (Job and Marriage in the example), OCL uses a dot and the name of the association class:


context Person inv: self.Job 


The sub-expression self.Job evaluates to a Set of all the jobs a person has with the companies that are his/her employer. In the case of an association class, there is no explicit rolename in the class diagram. The name Job used in this navigation is the name of the association class.

Resolution:
Revised Text: In Figure 7.1 add bankAccount as the opposite role name of Bank.customer. change the multiplicity of Person.bankAccount from 0..1 to 0..*. change the multiplicity of Bank.customer from 0..* to 0..1. add CustomerAccount as the name of the Bank..Person association. In 7.5.3 replace Missing AssociationEnd names When the name of an association-end is missing at one of the ends of an association, the name of the type at the association end starting with a lowercase character is used as the rolename. If this results in an ambiguity, the rolename is mandatory. This is, for example, the case with unnamed rolenames in reflexive associations. If the rolename is ambiguous, then it cannot be used in OCL. Qualifying association ends with association names In cases the association that is being navigated has a non empty name, it is possible to qualify the accessed role name with the name of the association. This notation can be used to solve ambiguities as in the example below: A1 and A2 are two associations both linking classes C1 and C2 and each with ends c1 and c2. If a C1 is aC1 access, aC1.c2 will not be valid since it is ambiguous, whereas aC1.A1::c2 or aC1.A2::c2 will be valid. by Missing Association names The association name is never missing. If no explicit name is available, an implicit name is constructed in accordance with the UML style guide. Associations that are not explicitly named, are given names that are constructed according to the following production rule: �A_� <association-end-name1> �_� <association-end-name2> where <association-end-name1> is the name of one association end and lexically precedes <association-end-name2> which is the name of the other association end. Missing Association End names The name of an association-end is never missing. If no explicit name is available an implicit name is taken from the name of the class to which the end is attached. Note to tool vendors; this is a non-normative change from OCL 2.2, where the UML style guidance of converting the first letter of the implicit name to lowercase was endorsed. The normative text has never defined how implicit names are obtained. Tool vendors may wish to provide backward/forward compatibility warnings for this change. This may result in an ambiguity between an implicit association end name and another explicit name, unless only one of the association ends is navigable. The ambiguous name cannot be used in OCL. aPerson.role -- ambiguous Qualifying association ends with association names An association end name may be qualified with its association name or its source classifier name to resolve an ambiguity. aPerson.Person::role -- still ambiguous aPerson.A_person_role::role -- some Parts, using implicit Person to Part association name aPerson.A_owner_role::role -- a Role, using implicit Person to Role association name In 7.5.4 first paragraph delete starting with a lowercase character: In 7.5.4 first example replace self.job by self.Job In 7.5.4 second paragraph replace self.job by self.Job and job by Job and delete starting with a lowercase character, similar to the way described in the sub clause �Missing AssociationEnd names� above. In 7.5.4 second, third and fourth examples replace self.employeeRanking by self.EmployeeRanking In 7.5.4 fourth, fifth and sixth paragraphs replace employeeRanking by EmployeeRanking In 7.5.4 fifth example replace self.job by self.Job In 7.5.15 third example replace two occurrences of c.job by c.Job
Actions taken:
April 30, 2010: received issue
April 25, 2011: closed issue

Discussion:

The summary summarises a thread discussion.
Introduction of the new names in Figure 7.1 is not absolutely necessary, but it
may prove helpful in discussions and related examples.
CustomerAccount seems better than BankAccount since there is no possibility of
111
misinterpretation as a case conversion with respect to another name.
The multiplicities in Figure 7.1 are surprising, but not actually wrong. The
suggested replacements are better, although they do not accommodate a joint
account.
While aligning association names with UML, it seems appropriate to make the
corresponding association end name alignment clearer.

Issue 15270: Definition for symmetric difference is wrong (ocl2-rtf)

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

symmetricDifference: is defined as (S1 u S2) - (S1 u S2), but this always yields the empty set. I believe the intended writing is (S1 u S2) - (S1 n S2).

Resolution:
Revised Text: Throughout Annex A change ? to whichever of. ? or n is used in Annex A of 03-10-14.
Actions taken:
June 1, 2010: received issue
April 25, 2011: closed issue

Discussion:

Absolutely.
This is another corruption resulting from the migration of the Latex Annex A of 03-10-14
(which is correct) to FrameMaker.
Looking at Table A.4 suggests that all n have been converted to ?. The entire Annex
must therefore be checked for every occurrence of ?.

Issue 15527: toLowerCase referred to as toLower (similarly for toUpperCase) (ocl2-rtf)

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

In A.2.1.2 Operations on p193, toLowerCase is referred to as toLower "case translations are possible with toUpper and toLower" and again in Table A.1

Also toUpperCase is referred to as toUpper in the same places

Resolution:
Revised Text: In Section A.2.1.2 change are possible with toUpper and toLower to are possible with toUpperCase and toLowerCase In Table A.1 change ToUpper to toUpperCase In Table A.1 change toLower to toLowerCase
Actions taken:

Discussion:

Issue 15528: toLowerCase() declared as returning Integer (ocl2-rtf)

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

In section "11.4.3 String" on p145 toLowerCase() is declared as returning Integer, correct type is String

Resolution:
Revised Text: In Section 11.4.3 change toLowerCase : Integer to toLowerCase : String
Actions taken:
September 14, 2010: received issue
September 14, 2010: received issue
April 25, 2011: closed issue
April 25, 2011: closed issue

Issue 15761: OCL 2.3 Ballotted: Retracting resolutions for Issue 10439/13076 (ocl2-rtf)

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

I am no longer happy with my resolution of 10439/13076 which provides a 
very high resolution LALR grammar. This is inefficient to emulate with 
LL and cannot provide the flexibility of configurable precedence. It 
will also be very difficult to accommodate a template parameter parse 
with similarly high precision. I now favour a low precision syntactic 
parse augmented by high precision disambiguation/semantic checks.

If the high precision LALR grammar may need retraction, it seems 
undesirable to put it into 2.3 only to remove it in 2.4.

Suggest retract the resolutions for OCL 2.3 and rewrite for OCL 2.4 once 
UML-alignment of templates has been accommodated

Resolution:
Revised Text: Do not apply the text revisions in the resolution of Issue 10439. Issues 10439 and 13076 remain Deferred.
Actions taken:
October 9, 2010: received issue
April 25, 2011: closed issue

Discussion:

As suggested, exclude the LALR grammar from OCL 2.3, deferring resolution of issues
10439 and 13076 until UML-alignment issues such as templates (Issue 15425) have been
accommodated in a practical grammar.

Issue 16122: US PAS Ballot Comment 2 (ocl2-rtf) References (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

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

Informal references to UML 1.4.1 and UML 1.5 are included as part of explanatory text in the OCL 2.2 spec which refers to UML 1.x to explain differences of this new version of OCL.. The ISO/IEC 10151 (UML 1.4.1) needs to be added as an informative reference, for use in these explanations. 
Change:
�
3 Normative References
The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
� UML 2.0 Superstructure Specification
� UML 2.0 Infrastructure Specification
� MOF 2.0 Core Specification
� UNICODE 5.1 Standard: http://www.unicode.org/versions/Unicode5.1.0/
�
To :
�
3 References
3.1 Normative References
The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
� UML 2.2 Superstructure Specification <omg spec Ref URL>
� UML 2.2 Infrastructure Specification <omg spec Ref URL>
� MOF 2.0 Core Specification <omg spec Ref URL>
� UNICODE 5.1 Standard: http://www.unicode.org/versions/Unicode5.1.0/
3.2 Informative References
The following specifications are referenced in informative text:
� ISO/IEC 19501:2005 Information technology � Open Distributed Processing -- Unified Modeling Language (UML) Version 1.4.2 , also <omg Spec Ref URL>
�

Change all uses of the informal UML 1.x references in the text From:
�
UML 1.x� or �UML 1.4.x�
�
To:
�
ISO/IEC 19501:2005
�

Resolution:
Revised Text: The following updates will be applied: (0) In Section 1 change: This specification defines the Object Constraint Language (OCL), version 2.3. OCL version 2.3 is the version of OCL that is aligned with UML 2.3 and MOF 2.0. By This specification defines the Object Constraint Language (OCL), version 2.3.1. OCL version 2.3.1 is the latest version of OCL that is aligned with UML 2.3 and MOF 2.0. (1) In Section 3, change: � 3 Normative References The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. � UML 2.0 Superstructure Specification � UML 2.0 Infrastructure Specification � MOF 2.0 Core Specification � UNICODE 5.1 Standard: http://www.unicode.org/versions/Unicode5.1.0/ � To : � 3.1 Normative References The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. � UML 2.3 Superstructure Specification: http://www.omg.org/spec/UML/2.3/Superstructure/PDF/ � UML 2.3 Infrastructure Specification: http://www.omg.org/spec/UML/2.3/Infrastructure/PDF/ � MOF 2.0 Core Specification: http://www.omg.org/spec/MOF/2.0/PDF/ � ISO/IEC 10646:2003 Information technology -- Universal Multiple-Octet Coded Character Set (UCS) � UNICODE 5.1 Standard: http://www.unicode.org/versions/Unicode5.1.0/ � Unicode Technical Standard#10: http://www.unicode.org/reports/tr10/ � ISO 639 Codes for the representation of names of languages � ISO 3166 Codes for the representation of names of countries and their subdivisions 3.2 Informative References The following specifications are referenced in informative text: � ISO/IEC 19501:2005 Information technology - Open Distributed Processing -- Unified Modeling Language (UML) Version 1.4.2 � (2) In Section 7.3.3 Invariants, replace text: �In the following example the name of the constraint is enoughEmployees. �In the UML 1.4 metamodel, this name is a (meta-)attribute of the metaclass Constraint that is inherited from ModelElement.� By: �In the following example the name of the constraint is enoughEmployees.� (3) In Section 7.5.12 Collections of Collections, replace the paragraph: �In UML 1.4 a collection in OCL was always flattened (i.e., a collection could never contain other collections as elements). This restriction is relieved in UML 2.0. OCL allows elements of collections to be collections themselves. The OCL Standard Library includes specific flattened operations for collections. These can be used to flatten collections of collections explicitly.� By � OCL allows elements of collections to be collections themselves. The OCL Standard Library includes specific flattened operations for collections. These can be used to flatten collections of collections explicitly� (4) At the end of Section 9.1 replace sentence: �The disambiguating rules are written in OCL, and use some metaclasses and additional operations from the UML 1.4 semantics� by �The disambiguating rules are written in OCL, and use some metaclasses and additional operations from UML�. (5) In Section 10.2.1, in foot note of �StaticValue� clause, replace sentence: �As StaticValue is the counterpart of the DataType concept in the abstract syntax, the name DataValue would be preferable. Because this name is used in the UML 1.4 specification to denote a model of a data value, the name StaticValue is used here� By �StaticValue is the counterpart of the DataType concept in the abstract syntax, the name DataValue would be preferable. StaticValue is used for historical reasons concerning past versions of UML. � (6) In Section 10.4.2, in clause OclMessageExpEval , rule [5] replace sentence �Note that the Parameter type is defined in the UML 1.4 foundation package� by �Note that the Parameter type is defined in the UML metamodel� (7) In Section 12.1 Introduction, replace sentence: �In principle, everywhere in the UML specification where the term expression is used, an OCL expression can be used. In UML 1.4 OCL expressions could be used (e.g., for invariants, preconditions, and postconditions)� by � n principle, everywhere in the UML specification where the term expression is used, an OCL expression can be used.(e.g., for invariants, preconditions, and postconditions). (8) In Section A.2.6 Special Types replace the sentence �The exception has been introduced in UML1.3 because it considerably simplifies the type system [CKM+99]� by �The exception has been introduced in UML because it considerably simplifies the type system [CKM+99]� (9) In Section 6.2 replace sentence: �The OCL Language Description clause gives an informal description of OCL in the style that has been used in the UML versions 1.1 through 1.4.� By �The OCL Language Description clause gives an informal description of OCL� (10) In Section 6.2 replace sentence: �Clause 8 (�Abstract Syntax�) describes the abstract syntax of OCL using a MOF 2.0 compliant metamodel. This is the same approach as used in the UML, v1.4 and other UML 2.0 specifications. The metamodel is MOF 2.0 compliant in the sense that it only uses constructs that are defined in the MOF 2.0.� by �Clause 8 (�Abstract Syntax�) describes the abstract syntax of OCL using a MOF compliant metamodel . This is the same approach as used in UML specifications. The metamodel is MOF compliant in the sense that it only uses constructs that are defined in the MOF.� (11) In Section 12.2 replace � In UML (1.4) the Expression � � By �In UML the Expression ...�
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

Comment:
References to UML and MOF need to be updated to most recent versions.
Unnecessary references to UML 1.4 need to be removed or replaced by more neutral
references (�UML� instead of �UML 1.4�). This concerns at least 6 locations in the spec,
like in Section 7.3.3 Invariants and in Section 7.5.12 Collection of Collections.

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

The nature of the relationship between this specification and the OCL in UML 1.4 should be clarified in an informative manner.
UML 1.4.1 needs to remain in force, because many UML models in many standards throughout the world are specified using UML 1.x notation, which is not backwards compatible with the notation in UML 2.x. 
Replace:
�
This specification replaces the specification of OCL given in UML 1.4.1 and UML 1.5.
�
With:
�
This specification replaces the specification of OCL given in OCL 2.0.
The version of OCL specified in ISO/IEC 19501:2005 is intended for use in models based on UML 1.4.1 and UML 1.5. However, use of the OCL specified by ISO/IEC 19501:2005 is not prescribed by this specification.
The version of OCL specified in this International Standard is not directly applicable to models based on ISO/IEC 19501:2005. �

Resolution:
Revised Text: In Section 6.1 replace: � This specification replaces the specification of OCL given in OCL 2.2. � With: � This specification replaces the specification of OCL given in OCL 2.2. The version of OCL specified in ISO/IEC 19501:2005 is intended for use in models based on UML 1.4.2 and UML 1.5. However, use of the OCL specified by ISO/IEC 19501:2005 is not prescribed by this specification. The version of OCL specified in this International Standard is not directly applicable to models based on ISO/IEC 19501:2005. �
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Issue 16124: Japan PAS Ballot Comment 1 (ocl2-rtf) (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: As the text above the table 2.1 explains, said template table is intended to be filled by OCL Tool implementors. Disposition: Closed
Revised Text:
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Resolved as Issue 16122. See US 1, Added 10646 as ref for Unicode. Will Fix at BRM to most appropriate formal references, either ISO or OMG spec refs Disposition: See issue 16122 for disposition
Revised Text:
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: The condition is an extra rule which must be satisfied in order to say that the type in the first column conforms to the type in the second column. An extra sentence to explain that will be provided. Besides, the UnlimitedNatural condition looks like an explanation rather than a condition. So this explanation will be rather located below the table.
Revised Text: In section 7.4.5, the paragraph just above the Table 7.4: Replace: The type conformance rules for the types from the OCL Standard Library are listed in Table 7.4. By: The type conformance rules for the types from the OCL Standard Library are listed in Table 7.4, where the third column specifies an additional condition which must be satisfied by the involved types to verify the type conformance rule. In section 7.4.5, after the paragraph just below the Table 7.4 Add: Although UnlimitedNatural conforms to Integer, '*' is an invalid Integer, so that the evaluation of the expression '1 + *' results in invalid.
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

See comment JP 7 in ��_JISC.doc�  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Initial Comment: Make clear which �latter� implies.
Revised Text: Change In Section 10.3.2 OperationCallExpEval P127: �type. The latter will be specified in 10.4 � to �type, as specified in clause 10.4 �
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

See comment JP 8 in ��_JISC.doc�  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

See comment JP 10 in ��_JISC.doc�  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip In OCL 2.3, 7.4.9 section, there is a statement which clarifies how this kind of operation
names should be treated: "Note that operation names such as iterate, forAll, and oclType,
are not reserved or restricted."
Therefore, �forAll�, �exists�, �any�, etc are not keywords.
Disposition: Closed

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Closed as Fixed by OCL 2.3 Disposition: Closed
Revised Text:
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

See comment JP 11 in ��_JISC.doc�  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip

Issue 16136: Issue nnnn: Japan PAS Ballot Comment 13 (ocl2-rtf) - Section 8.3.1 OclExpression (l16, p44) (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Typo. contaxt, change to context

Resolution: Initial Comment: contaxt->context Comment: Close as Fixed by OCL 2.3 Disposition: Closed
Revised Text:
Actions taken:
January 11, 2012: closed issue

Discussion:

See comment JP 21 in ��_JISC.doc�  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Initial comment: Replace this with [1]. Comment: Close as Fixed by OCL 2.3 Disposition: Closed
Revised Text:
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

See comment JP 21 in ��_JISC.doc�  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Initial comment: Replace this with simpleNameCS. Comment: Close as Fixed by OCL 2.3 Disposition: Closed
Revised Text:
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

See comment JP 21 in ��_JISC.doc�  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip

Issue 16141: Japan PAS Ballot Comment 18 (ocl2-rtf) (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Initial Comment: For instance, replace �[2] [A] BooleanLiteralExpCS ::= �true� [3] [B] BooleanLiteralExpCS ::= �false�� with �[A] BooleanLiteralExpCS ::= �true� [B] BooleanLiteralExpCS ::= �false��. Apply the same type of modifications to all identified clauses. Comment: Close as Fixed by OCL 2.3
Revised Text:
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

See comment JP 21 in ��_JISC.doc�  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip

Issue 16142: Issue from PAS Ballot comment for ISO/IEC DIS 19507 Section 9.3.29 OperationCallExpCS (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Initial Comment/Suggestion: Replace that part with the list below this table (Listing#1).
Revised Text: In Section 9.3.35 OperationCallExpCS, increase the indentation for line starting �SetType.allInstances�
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

See comment JP 21 in ��_JISC.doc�  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Initial Comment/Suggestion: Modify the text as appropriate. Comment: The explicit academic referenced may remain in the informative bibliography but should not remain in the core document of the specification
Revised Text: (1) In 8.3.4, remove �See [Kleppe2000] for a complete description and motivation of this type of expression, also called �action clause.� (2) In OclMessageExpVal clause, replace �As explained in [Kleppe2000] the only demand..� by �The only demand ..� .. (3) In Section 10, remove the sentence: I�t explains the semantics of OCL in a manner based on the report Unification of Static and Dynamic Semantics for UML [Kleppe2001], which in its turn is based on the MML report [Clark2000].�
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

See comment JP 23 in ��_JISC.doc�  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Initial Comment: Complete the quote like the following. �The Expressions Package� �The Types Package� Comment: Close as Fixed by OCL 2.3 Disposition: Closed
Revised Text:
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

See comment JP 24 in ��_JISC.doc�  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: IIn section 10.2.1, the TupleValue description states the following: �In the metamodel, this is shown as an association from TupleValue to NameValueBinding.� Therefore the text, diagram and association description are consistent. Disposition: Closed
Revised Text:
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

See comment JP 27 in ��_JISC.doc�  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: �The value that is bound to the name parameter in the latest snapshot� implies the use of the LocalSnapshot's bindings (NameValueBinding). Perhaps, including the word �bindings� may avoid confusions
Revised Text: In section 10.2.3, ObjectValue[1]: Replace: The operation getCurrentValueOf results in the value that is bound to the name parameter in the latest snapshot in the history of an object value. By: The operation getCurrentValueOf results in the value that is bound to the name parameter in the bindings of the latest snapshot in the history of an object value.
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

See comment JP 28 in ��_JISC.doc�  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Initial suggestion: Split the paragraph into two. Fist one should be just about summary of Figure 10.6, and the second one should introduce Figure 10.7with associated elements.
Revised Text: In Section 10.3, after Figure 10.6 change paragraph �Figure 10.6 shows the core part of the Evaluations package. The basic elements in the package are the classes OclEvaluation, PropertyCallExpEval, and VariableExpEval. An OclEvaluation always has a result value, and a name space that binds names to values. In Figure 10.7 the various subtypes of model propertycall evaluation are defined. � to �Figure 10.6 shows the core part of the Evaluations package. In Figure 10.7 the various subtypes of OclExpEval are defined. An OclExpEval always has a result value, and a name space that binds names to values.�
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

See comment JP 30 in ��_JISC.doc�  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

OperationCallExp. This heading should read �OperationCallExpEval.�. Modify the heading as appropriate.

Resolution: Suggested action: Modify the heading as appropriate.
Revised Text: In Section 10.3.1 change the heading �OperationCallExp� to �OperationCallExpEval�.
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

See comment JP 31 in ��_JISC.doc�  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

�ASCII or Unicode� is confusing. Use the same UML description

Resolution: Initial Comment/Suggestion: Use the same UML description Comment : Resolved by using uml infrastructure 13.2.4 definition for string type:
Revised Text: In Section 11.4.3 String, change �which can be both ASCII or Unicode � to �A string is a sequence of characters in some suitable character set used to display information about the model. Character sets may include non-Roman alphabets and characters.
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

See comment JP 33 in ��_JISC.doc�  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip

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

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: The unique difference, that the first diagram misses the CollectionKind.Collection Enumeration literal. Remove the first diagram.
Revised Text: In section 13.3, figure 13.27, there are two diagrams. Remove the first one.
Actions taken:
April 20, 2011: received issue
January 11, 2012: closed issue

Discussion:

See comment JP 34 in ��_JISC.doc�  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip