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

No Data Available

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

issue withdrawn by submitter

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.

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)

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

Summary: Use of simple quotes in place of double quotes should be allowed,
Specially in situations where the string contains double quotes (to avoid explicit
use of escaping characters).

The freedom to use single or double quotes risks causing confusion for novices as well as being helpful. OCL is the basis for extended languages which may have their own usage for double quotes, so extending OCL into this syntax area seems unwise.
Disposition: Closed, no change

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 missing operations are added. Notice that the list of operations is the union of those supported by sequences and those supported by sets.

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.

Disposition: See issue 9171 for disposition

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

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.

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.

Adding a TemplateParameterType. This promotes the solution to this problem as found in QVT.

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

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

No Data Available

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.

OclAny denotes now any object including collections. This makes the type system aligned with MOF.

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

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

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.

Adding clarification sentences

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.

Disposition: See issue 4451 for disposition

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.

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

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

No Data Available

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

s->allInstances() |Set(Set(???)) |Set

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.

No Data Available

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

>forAll(i | self.ownedAttribute.at.cmpSlots( referredOperation.ownedParameter.asProperty()

>forAll(i | self.ownedAttribute.asOrderedSet().at.cmpSlots( referredSignal.ownedAttribute.asOrderedSet()>at)

No Data Available

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.

No Data Available

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.

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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.

No Data Available

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.

No Data Available

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?

No Data Available

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)

No Data Available

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

No Data Available

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

No Data Available

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.

No Data Available

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.

No Data Available

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

No Data Available

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

No Data Available

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.

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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.

Disposition: See issue 10439 for disposition

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

No Data Available

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

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

No Data Available

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.

No Data Available

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

No Data Available

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

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.

No Data Available

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

No Data Available

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.

No Data Available

In Definition A.10 Object Identifiers, part ii, you have the domain of a class c defined as: ICLASS(c') = U

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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.

No Data Available

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.

No Data Available

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

No Data Available

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

The "fg" (in both occurrences) must be replaced by "{}" (a pair of curly braces).

Definition A.30, part ii says "I[[let v = e1 in e2]](r) = I[[e2]](s, ß

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

)."

Disposition: See issue 12488 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

No Data Available

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.

No Data Available

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.

Replace the text of Section A.2.7 Type Hierarchy by the following text:

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.

No Data Available

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.

No Data Available

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.

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.

No Data Available

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.

No Data Available

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

No Data Available

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

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.

No Data Available

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

No Data Available

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 )

No Data Available

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.

No Data Available

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

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

No Data Available

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

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.

Disposition: See Issue 12463 for disposition

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

No Data Available

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.

No Data Available

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.

No Data Available

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

No Data Available

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.

No Data Available

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.

No Data Available

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.

No Data Available

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

>forAll(n | datalist>at.ex = datalist@pre->at.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.

No Data Available

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

No Data Available

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

No Data Available

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)

No Data Available

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.

No Data Available

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

No Data Available

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.

No Data Available

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

yes

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

yes

The example of Set

is more of an example of an ordered set as is Set

. The example of a Sequence

does not exhibit any apparent order although a Sequence is defined as an ordered Bag. It might be wise to alter these examples to: Set

, Set ['strawberry','apple','orange'} and Sequence

Yes. But reverse the sequence to clarify that the ordering may not be the obvious one. Also correct the punctuation.

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

yes

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

’isOclType’ was fixed in OCL 2.3.
Disposition: Closed, no change

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

’asOclType’ was fixed in OCL 2.3.
Disposition: Closed, no change

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

yes

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

’isOclType’ and ’asOclType’ were fixed in OCL 2.3.
Yes. value rather than name

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

The italics are fixed in OCL 2.3.
Subtyping is resolved by Issue 15780.
Disposition: See issue 15780 for disposition

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

The paragraph containing the typo was removed in OCL 2.3.
In the context of Section 7, Operation is a property so there is a combination in the example..
Disposition: Closed, no change

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

UML 2.5 introduces Real. UnlimiteralNatural has been in UML for a long time.
Disposition: Closed, no change

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

’isOclType’ and ’asOclType’ were fixed in OCL 2.3.
Disposition: Closed, no change

Description: Syntax for the above constructions is extremely ambiguous and it might involve backtracking.
Rationale: According to OCL specification

• self.f(x, y)
• Set {1,2,3}

  ->select(x, y| x+y = 3)

• Set {1,2,3,4,5,6}

  ->iterate(x; acc:Integer=0 | acc + x)
  describe an operation call, an iterator, and an iterate expression.
  In order to make the distinction between an iterator call and an operation call we need in this case a three token lookahead, starting from x. The problem gets even more complicated if we consider that an argument for an operation call can be an expression.
  In order to solve this problem, which is a potential source of problems for the implementation (error-prone, inefficiency aso), we think that these OCL constructs should contain some extra syntax markers. There are several choices:

• change the comma marker from iterator calls to something else, maybe a semicolon
• add a syntax marker to an iterator name
• do not allow the default types
  The above choices will allow to a deterministic parser to deal with the enumerated problems more efficiently. I do not agree with textual language in which variables are given a default type according to the context in which they are used, especially if these languages are design for industrial use. The same problems were in previous versions of C standard, which allowed implicit type int for variables in constructions like
  x;
  Now, the latest C standard states that variables with default type are not allowed.

The exposition of the OCL grammar is poor. In OCL 2.3 the status of iterator names was clarified as not-reserved words which makes the naive parsing approach outlined above more challenging. Instead it is necessary to pursue a syntactic parse and then resolve semantics in a tree walk. The 'problems' have not prevented OCL tool being built.
Users would not be well-served by a major resyntaxing to introduce new punctuation.
Disposition: Closed, no change

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

The exposition of the OCL grammar is poor, but it is possible to resolve context pursuing a left to right analysis of an expression. It is also possible to perform a syntactic parse and then resolve semantics in a tree walk.The 'problems' have not prevented OCL tool being built.
Users would not be well-served by a major resyntaxing to introduce new operators that required the user to have greater understanding of the metamodels.
Disposition: Closed, no change

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

The suggested syntax comes from QVTo.
Non-trivial OCL expressions can be difficult to read. Introducing shorthand notations compromises readability. At present OCL has "." and "->" shorthands that cause significant difficulties. Introducing more does not seem appropriate for the standard language.
It is not clear that introduction of another [..] syntax can avoid conflicts with the already challenging conflicts for association qualifiers and array indexes.
Disposition: Closed, no change

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

The suggested syntax comes from QVTo.
Non-trivial OCL expressions can be difficult to read. Introducing shorthand notations compromises readability. At present OCL has "." and "->" shorthands that cause significant difficulties. Introducing more does not seem appropriate for the standard language.
oclIsKindOf and oclIsTypeOf are already a source of confusion; oclIsTypeOf should rarely be used but is the more obvious name to new users, so providing a shorthand for oclIsTypeOf is unnecessary.
The # syntax has no terminator so the shorthand needs an ambiguity resolution for a.#B.c()
The suggested usage seems to conflict with the intuition of those familiar with unary prefixes of assembler languages or even OCL 1.x enumeration literals.
If an improvement is to be made, something like
(a as B).c()
would contribute to rather than hamper readibility.
Disposition: Closed, no change

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

The typos are corrected in the overlapping Issue 15254.
Disposition: See issue 15254 for disposition

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

) then "DANGEROUS"
else "OK" endif endif endif …

OCL 2.3 relaxed a VariableDeclarationCS to permit the typeCS to be omitted and deduced from the initializer.
Disposition: Closed, no change

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

It is not true that there is no way:
mylist->collect(iterator | if condition then thenExp else elseExp endif)
which has two more tokens than the suggestion but avoids introducing a "?" syntax irregularity.
Disposition: Closed, no change

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

The suggested syntax comes from QVTo.
Non-trivial OCL expressions can be difficult to read. Introducing shorthand notations compromises readability. At present OCL has "." and "->" shorthands that cause significant difficulties. Introducing more does not seem appropriate for the standard language.
Disposition: Closed, no change

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

Stereotype support is certainly required, but I think much of the trouble is inadequate tooling. The examples can be realised by:
self.ownedElement->select(oclIsKindOf(Class)).oclAsType(Class) ->select(extension_EJBEntity <> null)
self.ownedElement->select(oclIsKindOf(Class)).oclAsType(Class) ->select(extension_EJBEntity.oclIsTypeOf(EJBEntity))
The clumsy ->select(oclIsKindOf(Class)).oclAsType(Class) 'idiom' is resolved by the selectByKind library operation from Issue 18829 to give
self.ownedElement->selectByKind(Class)->select(extension_EJBEntity <> null)
self.ownedElement->selectByKind(Class)->select(extension_EJBEntity.oclIsTypeOf(EJBEntity))
Given that UML specified the magic "extension_" and "base_" prefixes, it seems best to encourage rather than obscure them.
Disposition: Closed, no change

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

It is not really clear what this is issue is about.
Perhaps the suggestion is to allow users to write x.isKindOf(Y) rather than x.oclIsKindOf(Y).
There is a small benefit but also a confusion between alternate syntaxes and a need to change syntaxes to avoid confusion occasionally. Confusion is best avoided.
Disposition: Closed, no change