Issues for OCL 2.2 Revision Task Force mailing list

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

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

Issue 8917: allInstances
Issue 8918: Navigating across non navigable associations
Issue 8922: Section 8.3.9 of the final Adopted Version of the OCL 2.0 Spec
Issue 8937: Notation for accessing class operations is inconsistent
Issue 8982: Circular imports
Issue 9171: Introduction and oclType()
Issue 9404: inability to uniquely reference association ends
Issue 9405: Wrong subtyping of PropertyCallExp and NavigationCallExp
Issue 9796: Section: 7.3.4
Issue 9913: Section: 8.3.5
Issue 9914: Section: 7.5.9
Issue 9915: Using "def"
Issue 10344: Section: 7.4.9
Issue 10346: Section: 7.8
Issue 10430: Section 7.6.3
Issue 10431: Section 9.2.2
Issue 10432: Section "IteratorExpCS"
Issue 10433: 11.2.3
Issue 10434: 11.2.4 (OclInvalid) - similar criticism as 11.2.3
Issue 10435: 11.8.1
Issue 10436: 11.2.5
Issue 10437: 11.2.5 (02)
Issue 10438: 11.7.1
Issue 10782: Naming of Constraints in OCL
Issue 10825: ownership of association ends does not matter for traversal in OCL
Issue 10921: TypeType
Issue 10946: Collection element type serialization
Issue 10969: Usage of initialization and derivation constraints on the same property
Issue 11085: 8.2.2 Well-formedness Rules for the Types Package
Issue 11086: missing closing parethesis inthese two expressions
Issue 11097: Dynamic typing with allInstances()
Issue 11098: Section: 7.4.7, 7.4.9, 9.3.2
Issue 12378: Section 8.2 InvalidType
Issue 12419: CollectionType and CollectionKind
Issue 12438: last line on page 28
Issue 12439: Section: A/1.1.1 Types
Issue 12440: Section: A/1.1.5 Associations
Issue 12441: Section: A/1.1.5 Associations -- missing word
Issue 12442: Section: A/1.1.5 Associations
Issue 12443: Section: A/1.1.6 Generalization
Issue 12444: Section: A/1.1.6 Generalization - editorial issues
Issue 12445: Section: A/1.2.1 Objects
Issue 12446: Section: A/1.2.4 System State
Issue 12447: Section: A/2.2 Common Operations on All Types
Issue 12448: section 7.4.6 (p. 12)
Issue 12449: no explanations about how to manipulate optional and multivalued attributes
Issue 12450: The Tuple constructor is problematic
Issue 12451: OrderedSet collection
Issue 12454: The constraint [1] on the TupleLiteralPart metaclass is overconstrained
Issue 12457: Section: A/2.3 Enumeration Types
Issue 12458: Section: A/2.3 Enumeration Types -- editorial
Issue 12459: Section: Definition A.23 (Semantics of Navigation Operations)
Issue 12460: Section: A.2.5.2 Definition A.24 (Type Expressions)
Issue 12461: Section: A.2.5.5 Collection Operations
Issue 12464: Section: A/2.5.5 Collection Operations - just before table A.3
Issue 12469: A.2.5.5 Collection Operations
Issue 12470: There are two instances of missing and misplaced parentheses
Issue 12471: Section: A.2.5.6 Set Operations
Issue 12472: Section: A.2.5.6 Set Operations Table A.4
Issue 12473: Section: A.2.5.8 Sequence Operations
Issue 12474: Section: A.3.1.1 Syntax of Expressions
Issue 12475: Section: A.3.1.1 Syntax of Expressions
Issue 12476: Section: A.3.1.1 Syntax of Expressions (Definition A.29)
Issue 12477: Syntax of Expressions (second sentence after Definition A..29)
Issue 12478: Section: A.2.6 Special Types
Issue 12479: Section: A.2.6.1 Definition A.26 (Special Types)
Issue 12484: Section 8.2.1 Type Conformance on page 37
Issue 12485: Section 8.2 page 35 InvalidType
Issue 12486: Section: A.2.7 Type Hierarchy
Issue 12487: Section: A.3.1.1 Syntax of Expressions
Issue 12488: Section: A.3.1.2 Semantics of Expressions
Issue 12489: Section: A.3.1.2 Semantics of Expressions, Definition A.30 part ii
Issue 12490: Section: A.2.5.8 Sequence Operations
Issue 12491: Section: A.3.1.2 Semantics of Expressions
Issue 12493: Section: A.3.2.2 Syntax and Semantics of Postconditions
Issue 12582: OCL 2.0 8.2 Collection Type packaging
Issue 12943: OCL 2.0: CollectionType constraint for invalid elements is incorrect
Issue 12944: Type of a type expression
Issue 12945: Missing definition of of iterators for OrderedSets
Issue 12946: The operation asSet, asSequence, asBag and asOrderedSet missing for OrderedSets
Issue 12947: Clarify the common supertype of Bag and Sequence
Issue 12948: Making OclAny denote any object
Issue 12949: Incosistency between UnlimitedInteger and UnlimitedNatural
Issue 12950: No way to represent type parameters in the standard library
Issue 12951: Use of MOF reflection in EssentialOCL should be clarified
Issue 13077: The following collection operations would be useful for the HL7 GELLO project:
Issue 13535: doubts about the iterator variables
Issue 13536: type of the iterator variable is expected or not?
Issue 13537: have tuple fields and let variables to have the declaration of their types explicity?
Issue 13915: Role 'collectionTypes' should be 'collectionType'

Issue 8917: allInstances (ocl2-rtf)

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.

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)).

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> 

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

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"(?).

A simple duplication of issue 8902


Disposition:	See Issue 8902 for disposition

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. 

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).

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.

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	

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)

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

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
 

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.

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."

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

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.

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

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. 

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). 

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

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

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.

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

'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.

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.

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.	

"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) ?

"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. 

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.

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

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

"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."

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.

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

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.

"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"

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.

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.

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

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?

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

 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.

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.

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.

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

Disposition:	Closed, no change

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.

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

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

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.

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.

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.

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.

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

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)

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

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))

Correct, two parenthesis are missing.

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.

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

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

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.

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

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

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.

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

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>);

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.

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

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. 

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 ...."

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

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.

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.

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')

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.

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.

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.

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.

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.

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 ...."

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. 

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

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 ... ?

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

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.

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

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.

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.

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 ) 

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

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."

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)".

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..

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.

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 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.

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.

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.

Disposition:	See Issue 12463 for disposition

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.

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)"

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).

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).

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.

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

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.

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

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.

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.

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

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

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

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.

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. .

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.

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

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

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.

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.

Disposition:	See issue 12378  for disposition

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.

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. .

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. 

Disposition:	See issue 12474 for disposition

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

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. .

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)})." 

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".

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.

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

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.

[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).

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.

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())

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. 

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). 

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. 

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. 

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. 

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

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

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. 

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

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

 

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.

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..*).

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.

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.

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

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

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.

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.