b) More worryingly, 18.3.5 Semantics also says "As part of a profile, it is
not possible to have an association between two stereotypes or between a
stereotype and a metaclass unless they are subsets of existing associations
in the reference metamodel." I fail to see how a profile could in fact could
cause an association between 2 stereotypes to subset an existing association
in a reference metamodel since the stereotypes do not at all inherit from
the baseClasses so do not inherit any of its properties or associations in
order to be able to subset them: this is emphasized by the MOF
representation shown in the new Figure 447.
—

Indeed profiles do not support association subsetting. This should be made
clear in the spec to avoid any confusion while using profiles.

see above

Referring to the 040829.PDF FTF draft, in Figure 192, the two
associations ownedParameterSet should point to ParameterSet, to be
consistent with the text.

see above

Referring to the 040829.PDF FTF draft, the following dependencies
should be changed:

• Figure 141

IntermediateActions imports BasicActions and Communications,
rather than merge.

CompleteActions does not depend on StructuredActions, and only
imports BehaviorStateMachines and AssociationClasses.

• Figure 175:

FundamentalActivities merges BasicActions. The merge from
StructuredActivities to BasicActions can be removed.

CompleteActivities imports BehaviorStateMachines, rather than
merge.

see above

18.3.5 says that "A profile by definition extends a reference metamodel or
another profile."
While in theory I could see how it might be modeled, I don't see how the
latter could work in practice with real tools. Let's extend the current
example and define a new Profile called ClockTechnology with Stereotype
AtomicClock with baseClass Clock and property radioactiveElement:String..."
—

Import between profiles is supported, and stereotype generalization is the
usual way to achieve what has been called "extending a profile".

The reference to profile extension should be simply discarded. A profile
extends a reference metamodel.

see above

As the Chair of the Diagram Interchange FTF I urge you to make compliance Diagram Interchange a necessity for full compliance with UML 2 Superstructure.

In all discussions I attended it was always pointed out that the ability to exchange UML diagrams compliant to a standard using XMI was the single most important issue missing in UML 1. The Diagram Interchange specification was specifically designed to solve this problem. It is of essence that Diagram Interchange remains a part of UML 2 compliance. Otherwise the whole UML 2 standard is drastically reduces in its value.

see above

With the adoption of the updated definition of package merge, there are a number of places in both the Infrastructure and the Superstructure metamodels where the pre-conditions of package merge are violated. These need to be fixed.

see above

The spec does not have a way of indicating that an operation has "isQuery" set to true.

This is a duplicate of 6514 and has been resolved as part of the resolution to 7315.

At the bottom of pg. 79 of the Super FAS there are some examples ;
+createWindow (location: Coordinates, container: Container [0..1]): Window

+toString (): String

However that does not conform with the syntax of Operations (on page 78), which does not support the ":<return-type>" notation. It is probably a good idea to allow such a syntax since it is quite common, is used in most UML books and tools, and is conveniently similar to the notation for attributes.

This is a duplicate of 6213 and has been resolved as part of the resolution to 7315.

It is necessary to fully document the notational conventions used in the UML metamodel diagrams. In particular, it is necessary to be specific about the conventions used to denote the navigability and ownership of association ends, since the UML spec does not provide a default

see above

Package templates were a nice idea but they were never properly implemented in the UML 2 spec. At the moment, what is in the spec is incorrect and completely different from what is in the metamodel (I am not sure how that came about – maybe Birger recalls). Neither version is complete or correct.

The concept is a nice one to have, however, at this stage I am thinking of removing it altogether and leaving it as a new feature to be added in a future version.

Does anyone have strong objections to the removal of this concept?

(Reminder: package templates were the mechanism that depended on string substitution for instantiation.)

No Data Available

The package MaximumOneRegion was intended to be used as an optional package that restricts some of the general capabilities of behavioral state machines. This kind of capability is normally provided by a profile and should not be included in the standard, since it, effectively, displaces other parts of the standard.

see above

This action should be renamed and semantics clarified to apply to
classifier behaviors.

see above