In section 12.3.3.1.3 "MOF-Equivalent Semantics", the XMI given for the little "Home" example (starting at the end of page 298 and continuing to page 299) is broken. Some XML attribute values are not quoted at all, and many of the quote marks are "smart" (AKA "fancy") quotes, causing well-formedness checks to fail.

The longer example beginning on page 310 passes well-formedness checks. Both were tested in the opensource "XML Copy Editor" tool.

There is at the most only one return parameter allowed for an Operation due to the existing constraint "at_most_one_return". Why is the returnResult() operation multivalued? It should be [0..1], not [0..*].

Instead of an empty set, it could return null if there is no return parameter, similar to lower(), type() and upper(). But the stated body for those operations is defined in terms of returnResult() returning a set. Would that have an impact?

The issue reported here:
https://issues.omg.org/issues/UMLR-673 "Spec refers to TypeElement twice. Should be TypedElement"

still applies to 2.5.1. The affected pages are:
p. 75 (in a description) and
p. 192 in an OCL body for an operation (Property::isCompatibleWith(), section 9.9.17.7).

"Pages" refer to the PDF file containing the specification document .

In two places an undefined TypeElement is referred to. From the context it should be TypedElement.
As the 2nd occurrence is in an OCL constraint, tools using the OCL cannot be working unless they corrected it.
7.5.3 p 26
9.9 Operations p 154

In section 9.9.16.5 Constraints of ParameterSet, the OCL implementation for the constraint named 'input' assumes that the owner of the ParameterSet is always BehavioralFeature. However, a ParameterSet can also be owned by a Behavior. Also, it is not specified whether the 'in' Parameters include 'inout' direction, and likewise whether 'out' Parameters includes 'inout' and 'return' directions:

• input

If a parameterized entity has input Parameters that are in a ParameterSet, then any inputs that are not in a
ParameterSet must be streaming. Same for output Parameters.

inv: ((parameter->exists(direction = ParameterDirectionKind::_'in')) implies
behavioralFeature.ownedParameter->select(p | p.direction = ParameterDirectionKind::_'in'
and p.parameterSet->isEmpty())->forAll(isStream))
and
((parameter->exists(direction = ParameterDirectionKind::out)) implies
behavioralFeature.ownedParameter->select(p | p.direction = ParameterDirectionKind::out
and p.parameterSet->isEmpty())->forAll(isStream))

The method should be corrected to account for all parameter directions as well as the two possible types of owner. There is an interesting discussion of this on StackOverflow.

In section 9.9.17.8 Constraints, of the description for Property, the constraint "binding_to_attribute" on page 194 reads like this:

A binding of a PropertyTemplateParameter representing an attribute must be to an attribute.

Not sure what "PropertyTemplateParameter" is supposed to be ... either there is a missing space between "Property" and "TemplateParameter", or else maybe there are some missing words in the description. In any case, the OCL implementation is clear enough as to what this constraint does.

Referring to ParameterSet, section 9.9.16.4 "Association Ends" on page 190 of the PDF file:
Since parameters of a ParameterSet specify "alternative sets of inputs or outputs that a Behavior may use", and the Parameters of a Behavior are specified with the "ordered" constraint, by similar reasoning it seems that the parameters of a ParameterSet should also be ordered.

Consider a Behavior which has two alternate sets of input parameters implemented by ParameterSets: each set contains a String and an Integer parameter but ordered differently. Without the ordering constraint, they might be considered equal, and no overloading would be possible.

In the UML 2.5.1 specification document on page 173 of the PDF file in section section 9.9.2.7 "Operations" of BehavioralFeature, the textual description of "isDistinguishableFrom()" does not fit 100% with the OCL implementation given.

The description currently reads:

The query isDistinguishableFrom() determines whether two
BehavioralFeatures may coexist in the same Namespace. It specifies
that they must have different signatures.

Obviously, if they have different names, then they are also distinguishable from each other. This is the first element of the Tuple which is generated in the body of the query:

body: (n.oclIsKindOf(BehavioralFeature) and ns.getNamesOfMember(self)-
>intersection(ns.getNamesOfMember)->notEmpty()) implies
Set

Unknown macro: {self}

>including(n.oclAsType(BehavioralFeature))>isUnique(ownedParameter->collect(p|
Tuple

Unknown macro: { name=p.name, type=p.type,effect=p.effect,direction=p.direction,isException=p.isException, isStream=p.isStream,isOrdered=p.isOrdered,isUnique=p.isUnique,lower=p.lower, upper=p.upper }

))

My suggested improvement of the description:

The query isDistinguishableFrom() determines whether two
BehavioralFeatures may coexist in the same Namespace. It specifies
that they must have different names, or different signatures if their
names are the same.

In the section GeneralizationSet, section 9.9.8.4 "Attributes" on page 181, in the description for attribute "isDisjoint" the word "members" should be replaced by "elements" to avoid confusion with Classifier members. And, after all, sets have elements, not members.

The original text reads:

isDisjoint: Boolean [1..1] = false
Indicates whether or not the set of specific Classifiers in a Generalization relationship have instance in
common. If isDisjoint is true, the specific Classifiers for a particular GeneralizationSet have no members in
common; that is, their intersection is empty. If isDisjoint is false, the specific Classifiers in a particular
GeneralizationSet have one or more members in common; that is, their intersection is not empty.

Suggested improvement:

isDisjoint: Boolean [1..1] = false
Indicates whether or not the set of specific Classifiers in a Generalization relationship have any elements in
common. If isDisjoint is true, the specific Classifiers for a particular GeneralizationSet have no elements in
common; that is, their intersection is empty. If isDisjoint is false, the specific Classifiers in a particular
GeneralizationSet have one or more elements in common; that is, their intersection is not empty.

This seems to be more in agreement with what the summary text on page 162 under 9.7.3 "Semantics" is saying.

In the section BehavioralFeature, section 9.9.2.8 "Constraints" on page 173:

The constraint "abstract_no_method" declares: "When isAbstract is true there are no methods."

At least for C++, this is NOT necessarily true because a member function declared as pure virtual can have a method body. However, the method can only be called using the fully qualified class name.

This seems overly restrictive to me – there might have been a time when the C++ language disallowed method bodies for pure virtual functions, but I can't remember when that might have been ... in Scott Meyer's "Effective C++" 2nd edition, which dates from 1997, he remarks on page 162 that "it is possible to provide a definition for a pure virtual function (...)" and proceeds to illustrate different ways of calling the function.

It might make more sense to define the constraint backwards, such that if "isAbstract" is false, that there must be a (possibly empty) method body.