7.4.6 states: If the actual type of the object, at evaluation time, is not
a subtype of the type to which it is re-typed, then the result of oclAsType is invalid.

7.5.8 states: self.oclAsType(A).p1 – accesses the p1 property defined in A - this is incompatible with the no-class-change-to-A so A::p1 is not available for null.

But the normative 11.3.2 states: oclAsType(type : Classifier) : T
Evaluates to self.

The OCL 2.4 contribution to 11.3.2 was a typo. It should be "evaluates to invalid".

Languages such as Groovy have found it helpful to intrioduce the safe navigation operator ?: so that navigation over null yields null rather than a problem (invalid in OCL).

In OCL it could be a pure syntax sugar:

(x?.y) = (if x == null then null else x.y endif)

or perhaps an additional PropertyCallExp operator

Issue 15836 suggests that a negative CollectionRanbge should be invalid even after considering the Sequence

->forAll idiom.

The idiom clearly requires that a negative range gives an empty range.

OCL 9.4.5 gives no recommendation on how to handle the multiple out capability of UML.

Suggest that the mapping of a UML operation with out or inout parameters to an OCL operation do the following:

remove all 'out' parameters from the OCL parameter list so that the OCL parameter list contains only 'in' and 'inout' parameters with 'read-only' behavior

change the return type to a Tuple whose part-names and types are determined by the conventional 'result' and the 'out' and 'inout' parameters.

It is also desirable to relax the upper multiplicity bound to allow multiple bodyExpressions in Complete OCL, one bodyExpression per returning parameter.

OCL 12.10 awaits alignment with the UML 2.0 metamodel.

Consequently, the relationship between a result-valued OCL bodyExpression and a Boolean-valued UML bodyCondition is unspecified. A common pragmatic resolution has been to equate the two and ignore the Boolean-valued requirement of a UML Constraint.

In order to accommodate prevailing practice and also support UML's multiple out/inouts, suggest:

Reinterpret the grammar

prePostOrBodyDeclCS ::= ‘body’ (simpleNameCS)? ‘:’ OclExpressionCS

such that

the simpleNameCS is the name of the return parameter with 'result' as the anonymous default

OclExpressionCS is a result-valued bodyExpression if OclExpressionCS does not reference the simpleNameCS or its defgault.
OclExpressionCS is a Boolean-valued bodyCondition if the return parameter is referenced.

[Allow multiple body declarations.]

Thus

"body: ..." is a shortform of "body result: ..." which is a shortform for "body result: result = ..."

and

body: ...
body A: ...
body B: ...

could be the specification of a UML operation

f(out a : A, inout b : B, in c : C) : Z

In order for a UML model to import some Complete OCL for use in the model's constraints, a Complete OCL document must be a (derived) Package. Any tool can therefore import Complete OCL using its conventional metamodel import syntax; just needs per-tool support.

Complete OCL documents must not conflict. For instance if MM imports COD1 for its own purposes and then your usage imports MM (and COD1) and also COD2, the declarations in COD2 may not introduce anything that requires re-analysis of the OCL expressions in MM or COD1; the only change to MM+COD1 execution may arise through additional derived virtual functions.

Avoiding conflicts requires some strong WFRs.

Once conflicts are avoided, Complete OCL documents can be pre-compiled and loaded in compiled form.

In 11.6.2: "It [Set] contains elements without duplicates."

What is a duplicate?

In 10.2.2.13 SetTypeValue
"All elements belonging to a set value have unique values.
self.element->isUnique(e : Element | e.value)"

>From 11.9.1.3 isUnique, the basis of comparison is <>:
forAll (x, y | (x.iter <> y.iter) implies (x.value <> y.value))

But what is the Element::value to which "<>" is applied. It is far from clear that the semantics of the Element in Section 10 which is completely unrelated to MOF::Element leads to the obvious answer.

Suggest adding the obvious WFR.

context Set
inv: forAll(x | self->count = 1)

(count is already defined using "=")

[And chnage 11.9.1.3 isUnique to use this much more readable formulation.]

A.5.1.5 suggests that an invariant may be specified for many contexts. The Complete OCL syntax does not support this.

Many users like to write grandiose truths:

context X
inv: X.allInstances()->...

These do not use the context and so naively increase the complexity from O(N) to O(N*N).

Suggest allowing such constraints to be context-less constraints provided by the Package rather than a spurious Classifier.

The OCL expression syntax is difficult to extend for other purposes. The @pre postcondition operator, and the ^,^,? tokens are examples of extension of the core syntax.

Perhaps @pre could be generalized as an instance of an @token

suffix which could be parsed as an AnnotationExp for tooling to ignore but support extension for.

Can more arbitrary punctuation such as ^,^,?,#,% be generalized?

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

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

Typo. contaxt, change to context

Initial Comment: contaxt->context
Comment: Close as Fixed by OCL 2.3
Disposition: Closed

In the resolution to issue 14447 and 18407 in SysML 1.4 ballot 4, the metamodel figure is out of synch with the element descriptions, in particular for the source and target properties. The resolution to 18407 doesn't have revised text explaining when sourceContext and targetContext are needed.

Modify the metamodels figures to align with the element description for
DirectedRelationshipPropertyPath, and replace references to source and target
classifiers to source and target contexts. Explain when they are needed.

Nearly a year ago we put the UML OCL through Eclipse OCL and were able to eliminate 'all' (many hundreds of) syntactic errors and many semantic errors. Not all semantic errors, because Eclipse OCL is steadily adding stronger WFRs. Since then the authors have been using Eclipse OCL in the guise of IBM RSA and the errors have stayed away. Final checks of the UML 2.5 candidate UML.xmi identified only one semantic error.

Your report is marginal as a semantic error; perhaps a warning would be appropriate for the useless compare. I suspect an inadequacy in the Eclipse OCL determination of the application OCLAny::= specialization.

Realistically UML 2.5 paves the way for the start of a virtuous circle as feedback identifies the outright functional errors that occur when validating real models and the much harder inadequacies where the constraints are too weak.

issue already raised in the UML 2.6 RTF

At the top of the page, there is a formula to define the equal operator. The formula begins with I(=t). That t should be subscripted as we see in the sentence that precedes the formula.

The original report against OCL 2.3 A.2.2 has migrated to A.4.2 in OCL 2.3.1.

In the table A.1 (Schema for operations on basic types), the operations

are defined as applicable to

.
While the result is certainly Boolean, the parameters can't be Boolean in general, unless UML defined such operators for Booleans. According to section 11.5.4, there is no definition for the operators. Then Boolean should be removed in the set.

No Data Available

Whereas there are some infix operator definitions in later document, this list of infix operators isn’t described sufficient. For example, there is ‘>’ definition on 7.6.1. However, ‘>’ is not included in this list. Additionally, ‘=’ is defined on 11.6.1, 11.6.2, 11.6.4, 11.6.5. However, there isn’t ‘=’ on this list. By the way. ‘=’ is not defined for Integer, and Real. Is that no problem? Furthermore, “implies” definition could not be found. Add infix operator sufficiently. And, clarify the operator definition.

Not much of a title.
Section 7.5.8 is not normative so it is not necessary to enumerate every infix operator.
None of the logical operators, and, or, xor, implies are listed.
The "->" and "." tokens occur between their arguments and so could be regarded as infix, however navigation operators are not normally regarded as infix operators and so listing them would be more confusing than omitting them.
In most languages, "=" is not an infix operator, however in OCL it is, so omitting it when all other operators with punctuation spelling are listed is indeed a bit confusing.
(The punctuation of the list is dreadful.)
Issue 15009 introduces a missing section on "->" and "." operators.
Issue 14918 revises the definition of OclAny::= to be sensible for DataTypes.
implies is defined in 11.5.4

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

Initial Comment: Make clear which “latter” implies.

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

Initial Comment:
Complete the quote like the following.
’The Expressions Package’
’The Types Package’
Comment: Close as Fixed by OCL 2.3
Disposition: Closed

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

Initial Comment/Suggestion: Modify the text as appropriate.
Comment: The explicit academic referenced may remain in the informative bibliography but
should not remain in the core document of the specification

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

Initial Comment:
For instance, replace
“[2] [A] BooleanLiteralExpCS ::= ‘true’
[3] [B] BooleanLiteralExpCS ::= ‘false’”
with
“[A] BooleanLiteralExpCS ::= ‘true’
[B] BooleanLiteralExpCS ::= ‘false’”.
Apply the same type of modifications to all identified clauses.
Comment: Close as Fixed by OCL 2.3

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

Initial comment: Replace this with simpleNameCS.
Comment: Close as Fixed by OCL 2.3
Disposition: Closed

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

The condition is an extra rule which must be satisfied in order to say that the type in the first
column conforms to the type in the second column. An extra sentence to explain that will be
provided. Besides, the UnlimitedNatural condition looks like an explanation rather than a
condition. So this explanation will be rather located below the table.

There are same element names in both OCL and UML. Those are confusing. I wonder whether those are UML elements or OCL elements. Besides, it seems there is no clear distinction between UML/OCL (upper case letter) term and general term (lower case letter), since these are used in mixture.

• It is confusing to distinguish OCL “Constraint” from UML “Constraint” in the text. Furthermore, there are some “constraint” s (in a lower case letter). The lower case letter/upper case letters for “constraint” are mixed.
  OCL “Constraint” should be distinguishable from UML “Constrain”.

Not much of a title.
There are many element names that are the reused in UML; presumably class names were meant. I think that these are all distinct and not confusing to me. No convincing example is given. The example of a Constraint is where UML and OCL overlap so it is obviously the same class.
Spelling is separately raised as Issue 16126 so there is no need to address it here as well.
Disposition: Closed, no change

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

Initial Comment/Suggestion: Replace that part with the list below this table (Listing#1).

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

No Data Available

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

Initial comment: Replace this with [1].
Comment: Close as Fixed by OCL 2.3
Disposition: Closed

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

Closed as Fixed by OCL 2.3
Disposition: Closed

In the 3rd item of the definition A.12 (System State), the paragraph before the formula ends by :
"whereas the function i(l) projects all but the ith component):"

The function is exactly the same as the first function in the same sentence. It appears that a prime symbol is missing in the function. Indeed, a prime symbol appears in the formula.

The overline operator got lost when the Latex was FrameMakered

The symbol ≺ is used in this page. According to Unicode definition, this symbol represents a mathematical symbol whose definition is "precedes". Here is the reference of that definition :
http://unicode.org/cldr/utility/character.jsp?a=227A

I'm not a mathematician and I don't know precisely what this symbol means for mathematicians, even if I searched in many books and on the Internet. However, I find very confusing to use a symbol that means "precedes" to means "is the child of".

There is another symbol ≻ which means 'succeeds' that would be less confusing in the sense of "C1 succeeds C2" to means that C1 is the child of C2.

As I'm not mathematician, I may be completely wrong and I would greatly appreciate a sound reference where this symbol is defined formally.

The current operator has not been significantly changed by the Latex to FrameMaker conversion and so corresponds to an informed academic choice.
The requested change is less-informed and subjective.
Disposition: Closed, no change

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

The unique difference, that the first diagram misses the CollectionKind.Collection
Enumeration literal. Remove the first diagram.

“ASCII or Unicode” is confusing. Use the same UML description

Initial Comment/Suggestion: Use the same UML description
Comment : Resolved by using uml infrastructure 13.2.4 definition for string type:

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

“The value that is bound to the name parameter in the latest snapshot” implies the use of
the LocalSnapshot's bindings (NameValueBinding). Perhaps, including the word
“bindings” may avoid confusions

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

IIn section 10.2.1, the TupleValue description states the following:
“In the metamodel, this is shown as an association from TupleValue to NameValueBinding.”
Therefore the text, diagram and association description are consistent.
Disposition: Closed

I want to signal that the use of the word "meta" is confusing. Here is an example on page 47.

TypeExp
A TypeExp is an expression used to refer to an existing meta type within an expression.

According to Merriam-Webster, "meta" is usually a prefix that could be added at the beginning of a word. This particle should be merged to the main word (like in metabasis) or attached using an hyphen (like meta-analysis).

In consequence, we should read "metatype" which seems to hold the correct meaning. It is coherent with metaclass, for example. By the way, "metatype" is used at many places in the document.

In some contexts and in the familiar language, you can use "meta" as a diminutive for something when its meaning is obvious. For example, "the meta is broken" when you mean the metacarpus. In a specification document and in a context where we have to differentiate many metaconcepts, it doesn't have its place.

It is seen at many places in this document and may be other. In this one, we see "meta model" and "meta-model", while the word "metamodel" should be and is effectively used.

yes

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

Initial suggestion:
Split the paragraph into two. Fist one should be just about summary of Figure 10.6, and the second one
should introduce Figure 10.7with associated elements.

On page 153 oclIsInState(statespec : OclState) is used to check if an object is in a specified state. But in Section 7.5.9 on page 22 oclInState(statespec : OclState) is used for this purpose and examples are given.

There is one more occurrence of oclIsInState on page 47 of Section 8.3.1, but this is talking about the abstract syntax, therefore it could be valid. But I think definitely not for the concrete syntax of the OCL.

Strangely enough the Eclipse Interactive OCL Console implements oclIsInState() and not oclInState().

I would appreciate a clarification which statement to use very much!

If it was a popularity contest, oclInState would win because there are many occurences in Clause 7, but Clause 7 is not normative.
Excluding clause 7, oclIsInState has two occurences to oclInState's one. More importantly, the definition in 11.3.1 is oclIsInState.
Stylistically, all other ocl-prefixed methods returning boolean are oclIs...
Let's go for oclIsInState

The term “OMG 4-layered architecture” may need to be explained or used with proper references. Modify the text as appropriate.

Not much of a title.
Anyone familiar with modeling should really know who the OMG is and what a 4-layered architecture is.
However it is surprisingly difficult to find any primary OMG references. MOF for instance refers to "a ‘Four layered metamodel architecture’ which is referred to in various OMG specifications" so maybe MOF will get some adverse comments from PAS too.

OperationCallExp. This heading should read “OperationCallExpEval.”. Modify the heading as appropriate.

Suggested action: Modify the heading as appropriate.

The last formula in the definition A.12 has unbalanced parenthesis.
The first parenthesis after the = sign seems in excess.

No Data Available

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

No Data Available

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

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

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

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

No Data Available

Nature of problem:

Informal references to UML 1.4.1 and UML 1.5 are included
as part ofexplanatory text in the OCL 2.2 spec which refers
to UML 1.x to explain differences of this new version of
OCL.. The ISO/IEC 10151 (UML 1.4.1) needs to be added as
an informative reference, for use in these explanations.

UML 1.4.1 needs to remain in force, because so many UML
models in may standards throughout the world are specified
using UML 1.x notation, which is not backwards compatible
with the new notation in UML 2.x.

Given the normative content of OCL 2.3 (after RTF
completes) is aligned technically with UML 2.4 and MOF 2.4,
its normative references should be updated before
publication of the RTF output, so that the OMG spec cross
references will remain appropriate..

The references, and their uses in the OCL 2.3spec, need to
be updated to reflect these latest UML/MOF versions.

In addition, the Output of the OCL 2.3 RTF should be
labeled as OCL 2.4, to avoid clarify the technical
alignment of OMG’s latest versions of UML and MOF.

Proposed Changes:

Change version in title to OCL 2.4.

Change all self references in the text from “OCL version
2.2” to “this OMG Specification”.

Change all references from UML 2.0 and MOF 2.0 to UML 2.4
and MOF 2.4.

In Section 1 ­ Scope Clause:

Change:
“
This specification defines the Object Constraint Language
(OCL), version 2.3. OCL version 2.3 is the version of OCL
that is aligned with UML 2.3 and MOF 2.0.
“
to
“
This specification defines the Object Constraint Language
(OCL), version 2.4. OCL version 2.4 is the version of OCL
that is aligned with UML 2.4 and MOF 2.4.
“

Section 3 ­ Normative References

Change:
“
3 Normative References
The following normative documents contain provisions which,
through reference in this text, constitute provisions of
this specification. For dated references, subsequent
amendments to, or revisions of, any of these publications
do not apply.
• UML 2.0 Superstructure Specification
• UML 2.0 Infrastructure Specification
• MOF 2.0 Core Specification
• UNICODE 5.1 Standard:
http://www.unicode.org/versions/Unicode5.1.0/
«
To :
«
3 References
3.1 Normative References
The following normative documents contain provisions which,
through reference in this text, constitute provisions of
this specification. For dated references, subsequent
amendments to, or revisions of, any of these publications
do not apply.
• UML 2.4 Superstructure Specification <omg spec Ref URL>
• UML 2.4 Infrastructure Specification <omg spec Ref URL>
• MOF 2.4 Core Specification <omg spec Ref URL>
• UNICODE 5.1 Standard:
http://www.unicode.org/versions/Unicode5.1.0/
3.2 Informative References
The following specification is reference in explanatory
text, which describes differences between this
specification and the version of OCL included in the
existing standard. Its provisions do not constitute
provisions of this specification.
• ISO/IEC 19501:2005 Information technology – Open
Distributed Processing – Unified Modeling Language (UML)
Version 1.4.2 , also <omg Spec Ref URL>
“

Change all uses of the reference in the text
From
“
UML 1.x” or “UML 1.4.x”
“
To:
“
ISO/IEC 19501:2005
“

In Section 6.1 “Changes to Adopted OMG Specifications”

Replace:
“
This specification replaces the specification of OCL given
in UML 1.4.1 and UML 1.5.
“
With:
“
This specification replaces the specification of OCL given
in OCL 2.2.

The version of OCL specified in ISO/IEC 19505:2005 is
intended for use in models based on UML 1.4.1 and UML 1.5.
However, use of the OCL specified by ISO/IEC 19505:2005 is
not prescribed by this specification.

Although this issue was raised in conjunction with the First OCL 2.4 RTF that led to OCL 2.3.1, it seems appropriate to use this issue resolve all the 'boilerplate' changes for OCL 2.4.
Some of the changes outlined above occurred in OCL 2.3.1 and so need only a refresh for OCL 2.4.
The change of all OCL 2.2 references to this specification is not applicable since all references to OCL 2.2 and 2.3 intentionally refer to transitions in specified functionality.
MOF 2.0 references occur only in the boilerplate and so have been enumerated.
There are many UML 2.0 references associated with the TBD alignment with the UML 2.0 metamodel. These are very unfortunate but deserve to stay as the TBDs that they remain.

The OMG OCL 2 Revision Task force has resolved a set of defect and clarification issues against the text in DIS 19507. (Preliminary Report http://doc.omg.org/ptc/10-12-01.pdf , Change Barred Spec http://doc.omg.org/ptc/10-11-41.pdf) It is important that the corrections resolving these defects be reflected in the published ISO/IEC Standard for OCL. The editing group for OCL 2 (DIS 19607) should consider all changes against the text of OCL 2.2, resulting from RTF defect resolutions in the latest minor revision to OCL 2, approved by the OMG PTC by the time of the ballot resolution.

This is a philosophical statement without any identifiable issues. Many related issues were raised so presumably no action is necessary here.
Disposition: Closed, no change

Since you are working on the StateMachines chapter, it may be worth considering after the first submission adding an explanation about oclIsInState().
This query operation is unfortunately mispelled as oclInState(), see: http://www.omg.org/issues/ocl2-rtf.open.html#Issue15257
This query operation is confusingly listed as a predefined property and explained as an operation in OCL2.2, clause 7.5.9:

7.5.9 Predefined properties on All Objects
There are several properties that apply to all objects, and are predefined in OCL. These are:
oclIsTypeOf (t : Classifier) : Boolean
oclIsKindOf (t : Classifier) : Boolean
oclInState (s : OclState) : Boolean
oclIsNew () : Boolean
oclAsType (t : Classifier) : instance of OclType

....
The operation oclInState(s) results in true if the object is in the state s. Possible states for the operation oclInState(s) are all states of the statemachine that defines the classifier's behavior. For nested states the statenames can be combined using the double colon “::”.

I'm not sure that this correspondence on the UML RTF was really intended to be an OCL issue.
The specific oclIsInState typo is resolved by Issue 16260.
The more general discussion is appropriate for UML.
Disposition: See issue 16260 for disposition

The descriptions of CollectionRange are generally vague leaving the end inclusivities unclear.

It is only the CollectionRangeEval::getRange that provides a solid definition of well-formedness
for e.g. Sequence

as equal to Sequence

.

Unfortunately the specification is undecided about Sequence

is invalid, perhaps it should be
made useful instead, by defining .. as operating in the direction of the last wrt the first so
Sequence

= Set

.

The generalization to allow down-counts can lead to nasty surprises for e.g. Sequence

when x is empty. So just make it clear that Sequence

is invalid

Click here for this issue's archive.
Nature: Issue from PAS Ballot comment for ISO/IEC DIS 19507
Severity:
Summary:

See comment JP 5 in “…_JISC.doc” file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip
Resolution:

Not much of a title.
Not much of a summary.
The referenced document jumps straight from JP4 to JP6, so no action possible.
Even if JP6 was meant rather than JP5 then we can dismiss as a duplicate of Issue 16129.
Disposition: Closed, no change

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

Resolved as Issue 16122. See US 1, Added 10646 as ref for Unicode. Will Fix at BRM to
most appropriate formal references, either ISO or OMG spec refs
Disposition: See issue 16122 for disposition

Regarding ptc/10-11-42 and pas/10-08-02,
It seems to be typo.

In ptc/10-11-42, 11.6.5, and
in pas/10-08-02, 11.5.5

Threre is
"A Sentence is not a subtype of Bag. The common supertype of Sentence and Bags is Collection."
^^^^^^^ ^^^^^^^^

These two "Sentence"s seem to be typo.

Substitute "Sequence" for "Sentence".

Yes. Bags is also a typo and the English can be improved

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

As the text above the table 2.1 explains, said template table is intended to be filled by OCL Tool
implementors.
Disposition: Closed

A very common 'idiom' in OCL expressions is

sources->select(oclIsKindOf(T))>collect(oclAsType(T))>asSet()

to select the sub-set of type T.

This involves four library calls and requires T to be typed twice.

In practice

sources->select(oclIsKindOf(T)).oclAsType(T)

may save one operation call at the expense of the wrong collection type.

Suggest introduce

sources->selectByKind(T)
sources->selectByType(T)

to simplify this oclIsKindOf/oclIsTypeOf usage.

This is clearly useful:
Acceleo (but not MOFM2T) provides "filter".
The Dresden OCL team in http://gres.uoc.edu/OCL2011/pubs/ocl2011_submission_3.pdf suggest "selectByType" and note that QVTo provides "collectselect"
"filter" is nice and short but fails to fulfill the expectation that the argument should be some general predicate not an unmentioned type.
oclIsKindOf and oclIsTypeOf are already there and so unless they are to be changed, additions should be compatible and re-inforce the "KindOf"/"TypeOf" distinction..
There are two distinct algorithms: exact type and polymorphic type so
selectByType and selectByKind are consistent.
selectByType clearly can include/exclude OclVoid at will.
selectByKind probably doesn't want to include null elements even though null conforms to everything, so QVTo's collectselect exclusion is worth emulating.
There seems no need to introduce rejectByKind and rejectByType too, since there is no associated type conversion; reject will do.
The correct declarations should be:
selectByKind(TT)(type : Metaclass(TT)) : Collection(TT);
selectByType(TT)(type : Metaclass(TT)) : Collection(TT);
These use an operation template type TT to model the type relationship between the returned Collection element type and the metatype provided as the operation argument. Unfortunately we cannot use this until OCL '2.5' aligns with UML templates and introduces templated Metaclasses.

The accumulator in the definition of Collection::min and Collection::max is initialized as self.first().

post: result = self->iterate( elem; acc : T = self.first() | acc.min(elem) )

post: result = self->iterate( elem; acc : T = self.first() | acc.max(elem) )

The accumulator should be initialized as self.asSequence()->first(), because Collection::first() is undefined.

Nearly right.
self is of course a Collection, so needs to be self->asSequence()>first(), or just self>any(true).

Section 11.9.1.4 states that "there must be at least one element fulfilling body, otherwise the result of this IteratorExp is null." And defines

source->any(iterator|body) = source->select(iterator | body)>asSequence()>first()

However

let seq:Sequence<T>=source->select(body)->asSequence()
in source->any(body)=seq->at(1)

>From section 11.7.5

context Sequence::first() : T
post: result = self->at(1)

context Sequence::at(i : Integer) : T
pre : i >= 1 and i <= self->size()

If there is no element fulfilling body, then seq is empty and the precondition of Sequence::at does not hold because 1 > seq->size().

Related to: Issue 18125 [OCL 2.4]

The 'equivalent' OCL of
source->select(iterator | body)>asSequence()>first()
returns invalid if no elements are selected, rather than null as the words say.
As identified in Issue 18125, null could also be a valid value, so the words are clearly wrong.

"The returned collection of the closure iteration is an accumulation of the source, and the collections resulting from ..."

incorrectly includes the source. The algorithm in 11.9.1 correctly includes the source only if the source is reached by some traversal from the source.

No. The algorithm in 11.9.1 only adds the source to the result if the source was not already present. Since the anonRecurse starts with an empty result all sources are accumulated.
Just need to polish the words to avoid similar misunderstandings in the future

There is a contradiction between invalid conform to anything and invalid always propagates for e.g.

Sequence{}->first().oclIsKindOf(Class)

oclIsKindOf uses the invalid input to return true.

Invalid propagation should dominate giving invalid.

This requires OclInvalid::oclIsKindOf, oclIsTypeOf, oclType, oclAsType overloads to explicitly return invalid.

(A) It is clearly correct that OclVoid/OclInvalid conform to anything so that null/invalid can be used anywhere.
(B) It is also clearly correct for navigation on null and invalid to be invalid so that bad results propagate.
The above are not contradictory. The contradiction arises through the introduction of the oclIsInvalid() and oclIsUndefined() operations that may be used on null or invalid, despite (B).
It would appear that oclIsInvalid() and oclIsUndefined() must be privileged to violate the strictness of (B). If so, are oclIsKindOf, oclIsTypeOf, oclType, oclAsType etc. also privileged?
The specification can be clarified by making all oclXXX() operations privileged so that they can be used on null and invalid and defining their OclVoid and OclInvalid overloads explicitly.
The affected text can be clarified to eliminate the accidental omission of operation calls for null and invalid.
The affected text covers the DataType equality issue so the resolution of Issue 14918 is included

post: (result = self) and result.oclIsTypeOf( t )

requires oclAsType to change the type of self.

The constraint should be:

post: (result = self) and result.oclIsKindOf(t)

[Review all usage of oclIsType() since it's nearly always wrong to use oclIsType rather than oclIsKindOf.]

Should indeed be oclIsKindOf and the argument should be 'type' as in the signature.
Reviewing other oclIsTypeOf uses identifies just one clear error in 8.2.1 since CollectionType has derived SetType and other types. Other usages seem to be either ok but inelegant since the type is a leaf type, or deliberate constraints for an invariant

The any() iteration is specified to return null in the event that no match is found. However null could also be the return of a successful match of null. e.g

Sequence

->any(s | s = null)

Suggest: change the match-not-found return to invalid.

The resolution of Issue 18504 solves this too.
Disposition: See issue 18504 for disposition

In http://www.linkedin.com/redirect?url=http%3A%2F%2Fwww%2Ebrucker%2Ech%2Fprojects%2Fhol-ocl%2FFeatherweight-OCL%2Foutline%2Epdf&urlhash=vacm&_t=tracking_anet Burkhart Wol ff argues that lopgical consistency requires that not(not(X)) is X.

OCL 2.3.x does not satisfy this for 'null'.

Similary null and true = null not invalid ...

Issue 14197 for OCL 2.3 rationalized the vague equivalences between undefined and null/invalid.
In OCL 2.0, it was left for the implementer to determine how "not null" and "not invalid" were computed given the specification that "not undefined = undefined".
In OCL 2.3, we have clarity: "not null = invalid" and "not invalid = invalid". However this leads to the identified inconsistency that "not not X = X" is not true for all X (not not null = invalid).
The clarification of "not undefined" should have partitioned the two cases for "not undefined = undefined" so that "not null = null" and "not invalid = invalid"
Similarly other logical operations involving null but not invalid should yield null rather than invalid results. "null and true = null", "null or false = null", "null xor false = null".
We should extend this to the forAll and exists iterations that are defined as iterated and/or. Making the exists/forAll returns clear highlights that many iterator returns are only partially specified; these need expanding.
Introduction of null highlights a redundancy in the non-standard implies postcondition: (not self) or (self and b) rather than the standard (not self) or b. The standard gives the consistent result "null implies true = true" whereas the current non-standard postcondition gives null. The non-standard postcondition is already wrong for invalid.
The If expression specification words omit consideration of a non-valid condition; a null or invalid condition is of course invalid.
For arithmetic operations there is an apparently free choice between two alternate consistent logics in which "1 + null = null" or "1 + null = invalid".
"1 + null = null" is plausible if "null" denotes "don't know"; an object/value that exists but with unspecified value.
"1 + null = invalid" is plausible if "null" denotes "missing"; the absence of an object/value.
However UML provides the interpretation of "null" as "missing". UML-alignment of OCL therefore requires OCL to take the "1 + null = invalid" alternative, which is what the Issue 14197 clarification specified. So no change required for arithmetic operations.

The navigation from Association Classes does not conform to UML 2.4.1 because of 7.3.4 AssociationClass on page 44 UML Superstructure Specification, v2.4.1. the kind of navigation allowed by OCL is not allowed by UML, i.e. the navigation from the association class to the ends of the association is explicitly not allowed by UML but allowed by OCL. I see here a contradiction. I checked UML 2.1.2 from 2007 and in that UML this navigation from the association class the ends of the association was still allowed. I think that OCL 2.3.1 is not compatible with UML 2.4.2 from this point of view. Please tell me if this opinion is correct. If this contradiction that I remarked really exists than what to expect from the future: OCL or UML point of view?

The apparent prohibition in UML 2.4.1 is not present in UML 2.5 Beta.
The problem is a misunderstanding. OCL expressions are resolved at 'modeling-time' against the model and so are not restricted by visibility or any practical limitations that may occur at run-time.
Disposition: Closed, no change

ISO 639 has been replaced by a six-part series. The new reference should be: ISO 639 (all parts)
ISO 3166 has been replaced by a three part series. The new reference should be: ISO 3166 (all parts)
ISO 10646 is new and this reference should be: ISO 10646:2011, Information technology - Universal Coded Character Set (UCS)

yes

The description of String::indexOf() states "No string is a substring of the empty string.".

This modifies the axiom that every string is a substring of itself. It would appear that the empty string has got confused with null.

An extension of the library with startsWith and endsWith operations would require the modified axiom to be accommodated making corner cases equivalently strange.

This modified axiom is not observed by other String libraries such as the java.lang.String.

Suggest: Replace the text:

"The empty string is considered to be a substring of every string but the empty string, at index 1. No string is a substring of the empty string."

by

"The empty string is a substring of every string at index 1 (and also at all other indexes)."

yes

Issue 14197 finally resolved the semantiscs of OclInvalid, but the end result was that there is no OclInvalid section in 11.3. Add an 11.3.x for OclInvalid that enumerates all relevant OclInvalid behaviors; in particular = and <> return invalid for any invalid argument.

Merged with Issue 18437.
Disposition: See issue 18437 for disposition