PROBLEM STATEMENT
"When one or more ends of the association have isUnique=false, it is
possible to have several links associating the same set of instances."
(Superstructure, p. 81)

As Pierre-Alain Muller demonstrated in an informal conversation with Bran
Selic during a lunch in San Francisco in the last UML Conference (I also was
taking part in that conversation), isUnique must have the same value for all
ends in an association.

This has implications, for example, for the property strings that can be
placed near the association ends (

,

,

). According to the
table in Superstructure, p. 92, if one end is a Set or an OrderedSet, then
the opposite end must be a Set or an OrderedSet, too; and if one end is a
Bag or a Sequence, then the opposite end must be a Bag or a Sequence, too.

PROPOSED SOLUTION
Explain this in the Spec.

This topic is discussed in detail in DraganMilicev’s paper at http://afrodita.rcub.bg.ac.rs/ dmilicev/pubs/mdd/
trumlassoc.zip. In the paper he proposes that the collection that provides the value of a property that is an
association end is derived from the links that instantiate the association as modified by the isUnique marking.
So, even if there are two links targeting an instance in the extent of the association, if the property is
marked as unique then there will only be one instance in the collection. This interpretation allows there to
be associations with mixed unique/nonunique ends. After discussion the FTF thinks that this interpretation
is in fact the intended interpretation of the current spec, and should be clarified as such.
Milicev also points out that AssociationClasses make the identity of links visible in the semantics, and in
contrast to what the spec currently suggests, it is possible to have multiple instances of an AssociationClass
that associate the same set of end instances, regardless of the uniqueness marking of the ends. This is
clarified in the current resolution. Milicev proposes adding an isUnique property to AssociationClass to
give the power to rule out such multiple instances. Adding such a property is outside the scope of UML 2.5.
This resolution also clarifies that property subsetting applies to property values coerced to sets. Currently
nonunique B could be marked as subsetting unique A. If B contains the same value twice and A contains it
once, then that should be legal, even though the size of the value of B is larger than that of A.
The resolution also accounts for the use of qualifiers, makes some improvements to the definition and use
of the term “cardinality”, and corrects the semantics of CreateLinkAction to correspond to the clarified
definition.
This also resolves issue 5977.

The SoaML submission team understands the concerns about making UML extensions at all, let alone introducing changes too high up in the hierarchy that might introduce additional unintended inheritance issues. But we are also reluctant to submit to the UPMS RFP without addressing the need to distinguish services from requests, and without addressing the usability issues that result from the need to create separate types for both ends of a connector.

Recall that the problem is that ports appear on two ends of a connector. It is very often the case that consumers and providers can agree on the provided and required interfaces, and the interaction characteristics (protocol) and should therefore be able to use the same type to highlight that agreement. This is not possible with UML2. Ports don't have direction to indicate whether the owning component is using the operations or providing them. So users are forced to create "conjugate" types that flip the usage and realization relationships between classes and interfaces. This is especially troubling for the common simple case where the port is typed by a simple Interface.

There have been a number of suggestions about how to solve this problem, many involving how ports define provided and required interfaces, and whether they need a type at all. We wanted to solve this problem without making a lot of changes to UML that may have other unintended consequences, or not sufficiently address the issues. So our updated proposal is very simple, and hopefully not something that would in any way effect future changes to UML2.

We suggest the addition of a new Enumeration called PortDirection which has literals incoming and outgoing. Then add a new ownedAttribute to Port called direction: PortDirection = incoming. This would provide a direction on port that would be used to change how the provided and required interfaces are calculated. If direction=incoming, then the provided interfaces are those realized by the port's type and the required interfaces are those used by its type. If the direction is outgoing, the calculations are reversed: the provided interfaces are those used by the port's type, and the required interfaces are those realized by the port's type. Therefore, provided and required interfaces are calculated from the point of view of the owner of the port based on whether they are using the capabilities defined by the port's type, or providing them.

This does not provide similar capabilities for things like connected collaborationRole Properties in a Collaboration. These properties are of course not Ports, and there is no specific specialization of Property (i.e., Role) that distinguishes the usage of a property in a collaboration that could specify the direction from other usages of property where direction is not relevant. We will miss that capability, but don't want to expand the scope of the UML change to address it at this time. Rather we'll wait and see if the UML2 RTF comes up with a more general solution that is also consistent with port direction.

Is this acceptable?

This issue addresses a widely-recognized fundamental omission from UML. As such it is worthy of making an exception to normal RTF policy of not introducing new features to the language, particularly since the new feature is purely additive.
But the wording of the proposed change in the UPMS specification is somewhat problematical. Notably the idea of "incoming" and "outgoing" does not sit very comfortably with the notion of a Port being essentially a bidirectional intermediary entity which specifies both provided and required interfaces.
For this reason we propose a slightly different solution with similar semantic consequences: the introduction of a Boolean property isConjugated (default false) to the metaclass Port. When isConjugated is false, the semantics of Port are what they are today. When isConjugated is true, the calculation of provided and required interfaces from the Port's type is inverted.
This works nicely when the type of a port is a single interface, because it allows a port that provides one interface and a port that requires one interface both to be simply represented. Today, a simple port that requires one interface has to be typed by a class that requires that interface, which is cumbersome and inconvenient.
However, the idea of conjugating a port renders problematical the concept of instantiating the port type in the form of "interaction points" as currently specified in chapter 9. Instantiating the same type at both ends of an asymmetrical link is clearly unlikely to work. From a SoaML point of view, the port type represents a protocol, which will be applied differently at each end of the link depending on the sense of isConjugated. Therefore from a UML point of view we propose to delete all text that suggests direct instantiation of port types.
Finally, it is important for modelers to be able to distinguish conjugated ports in the notation, so we introduce suitable new notation.

In chapter 9 (CompositeStructures) the semantics of ports are given strictly in terms of instantiating the owning classifier and instantiating the ports as “interaction point objects” typed by the type of the port. Yet in chapter 8 (Components), a Component (through its IsIndirectlyInstantiated attribute) may not be instantiated at run time, in which case the inherited semantics of ports and port types cannot apply. The sentence from 8.3.1 “The required and provided interfaces may optionally be organized through ports, these enable the definition of named sets of provided and required interfaces that are typically (but not always) addressed at run-time” clearly states that ports are a way to organize required and provided interfaces of a component at design time, yet this is contradictory to the notion that the provided and required interfaces of a port are derived from its type which is instantiated as interaction point objects. These contradictions should be resolved

Much of this issue is resolved by 13080, in which the text about the interaction point objects being instances of the port types has been deleted.
The remainder of the issue can be handled by some explanatory text as proposed below.

UML2 Superstructure 2.1.1:Interactions

In Fig 14.26 there are various time annotations shown which relate to the Simple Time package.

The notation sections for TimeObservation and DurationObservation read thus:

TimeObservation: “A time observation is often denoted by a straight line attached to a model element. The observation is given a name that is shown close to the unattached end of the line.”

DurationObservation: “A duration observation is often denoted by a straight line attached to a model element. The observation is given a name that is shown close to the unattached end of the line.”

However the notations in Figure 14.26 look like this:

TimeObservation: “t=now”

DurationObservation: “d=duration”

I don’t see how the example notation is consistent with the notation descriptions

Merged with 17841

Issue: UML representation of applied stereotypes and their properties is
insufficiently described
Nature: Clarification
Severity: Significant
Summary:

1. In the Superstructure spec 2.1.1, it is not clearly stated what an
applied stereotype is in terms of metaclasses. The spec talks
about "instance of a Stereotype", but it fails to sufficiently
clarify the so-called meta-level crossing, i.e. the fact that an
instance of the Stereotype metaclass at the same time is a new
metaclass. The description of Stereotype says in the Semantics
section: "An instance “S” of Stereotype is a kind of (meta) class
". I think "a kind of" as well as putting "(meta)" in parenthesis
is confusing. I suggest to say: "An instance “S” of the Stereotype
metaclass is itself a metaclass.". Also, the text currently does
not describe what the name and particularly the namespace of the
metaclass corresponding to the instance of the Stereotype
metaclass would be. Because of the current uncertainty, UML tools
have taken different (and incompatible) interpretations on how an
applied stereotype should be represented in terms of UML
metaclasses.

2. It is not described currently how any property values of applied
stereotypes are represented in terms of instances of metaclasses.
When looking at generated XMI, it seems that this representation
is quite different from Property metaclass instances that are
ownedAttributes of user model classes, so there is a need to
clarify this. Because of the current uncertainty, UML tools have
taken different (and incompatible) interpretations on how these
values should be represented in terms of UML

No Data Available

Please explain why constrainedElement has to be an ordered set and not a set

Duplicate

Instance modeling does not take into account stereotypes properties.

Assume I create a stereotype that I apply to some Class. That stereotype adds some property 'p' of type String. Now assume I create an InstanceSpecification of that Class.

I believe I should be able to create a slot for 'p' and assign some value to it.

Constraint [1] on InstanceSpecification 7.3.22 seems to restrict this since it mentions that the defining feature of each slot is a structural feature of a classifier of the instance specification. The properties contributed by the stereotype are not considered to be part of the features of the Classifier (assuming the stereotype is applied to a Classifier)

withdrawn by issue submitter

Typo in attributes section of comment: Remove "multiplicity" (red colored) before attribute body.

No Data Available

A package can only own packageable elements. That excludes comments. On the other hand the comment definition states: A comment can be owned by any element. That's a contradiction. It's important that packages can own comments. Therefore I propose a change of the package to allow the ownership of comments.

Discussion: It is not quite right to say that “a package can only own packageable elements”. The spec only says that “Only packageable elements can be owned members of a package.” That is, any owned members of the package, considered as a namespace, must be packageable elements – this is because packagedMember subsets the ownedMember derived union and no other property of Package does. However, a namespace (and hence a package) can have owned elements that are not owned members. In fact, all elements inherit the Element::ownedComment property that subsets ownedElement. For a namespace, ownedMember also subsets ownedElement, so the owned elements of a namespace (and hence a package) include both comments and namespace members. However, while a comment can thus owned by a namespace, it cannot be a member of the namespace, since it is not a named element. Disposition: Closed, no change.

Using the 07-02-03, 2.1.1 spec we have the following (pg 569 or 583/732 section 15.3.14 Transition :: Constraints)):
[5] Transitions outgoing pseudostates may not have a trigger. source.oclIsKindOf(Pseudostate) and ((source.kind <> #junction) and (source.kind <> #join) and (source.kind <> #initial)) implies trigger->isEmpty()

This OCL erroneously states that Junctions and Joins may have outgoing transitions with triggers. As far as I understand, one can never be waiting in a junction point or join for a trigger to occur.

No Data Available

In the 2.1.1 specification (070205):

Regarding the quote on p128:
"All redefinitions should be made explicit with the use of a

property string. Matching features in subclasses without an explicit redefinition result in a redefinition that need not be shown in the notation. Redefinition prevents inheritance of a redefined element into the redefinition context thereby making the name of the redefined element available for reuse, either for the redefining element, or for some other."

I interpret the following quote from the UML 2.1.1 spec to mean that when a subclass includes a property whose name is equal to a property in one of its general classes, then it should be treated as a redefinition even if there is no explicit redefinition between those properties in the model.
This should be clarified in the spec. It is unclear and also includes at least one spelling mistake. Alternatively, we should ban implicit redefinitions and flag them as simple name conflicts.

Two features of the same kind defined in a class and a superclass (i.e., they are both either structural features or behavioral features) does indeed imply a redefinition and, therefore, must conform to the compatibility constraint on redefinitions.

No Data Available

The definition of Port.isService appears to be redundant with the concept of public/private visibility. Is it valid for an isService=true Port to be private, or for an isService=false Port to be public? What about protected and package visibility for Ports?

Resolution:
From Bran Selic:
Please note that isService=false is intended for modeling so-called SPPs (service provision points) in UML-RT. SPPs are ports that are used by the implementation of a structured class to access run-time services of the underlying support layers. In contrast to ports for which isService=true, SPPs are implementation specific – in other words, they are not part of the services that a component publishes to its clients. On the other hand, they must be public ports or you will not be able to connect to them from the outside.

It is a subtle distinction but an important one. The notion of implementation-specific interfaces is one that has, unfortunately, been generally missed in programming languages. It is a key element of layering.

If you remove this capability, you will certainly invalidate a lot of models based on this notion.

Revised Text:
None.

Disposition: Closed, no change.

Could you please clarify what does the UML2 specifications intend for "provided port" and "required port"? Intuitively, it seems that a port could provide (respectively require) the interface which types it. This is in contradiction with the UML2 definition of port. Nevertheless, I belive a port should be able to require the interface tpeing it: the type of a port and its role (provide/require) should be decoupled. This is basically what the graphical front-end of Rhapsody does. It is also the same approach used for SysML ports, where direction is decoupled from the type of the port.

The idea of decoupling the type from the interface is addressed by 13080. The clarification is addressed here by the text revisions below.

There seems to be an inconsistency in the spec.

Supersturcture v2.2 ptc/2008-05-xx
p 550

The spec mentions:
A state with isSimple=true is said to be a simple state. A simple state does not have any regions **and it does not refer to any submachine state machine.**

It also says in the constraints section ( constraint [4] ) :
A simple state is a state without any regions. isSimple = region.isEmpty()

The constraint seems to be missing the part about not refering to any submachine state machine.

The submitter is correct. Add the missing constraint to the isSimple() operation of State by adding that the
isSubmachineState attribute has to be false

To better express links with InstanceSpecifications, InstanceSpecification should be able to reference Slots owned by other InstanceSpecifications similar to an Association's memberEnd. Currently, when modelling an object diagram with a link like the one in fig. 7.54 on p.85, the specification is unclear on which of the involved InstanceSpecifications (Don, Josh, assoc) should own which Slots (father, son). Assuming that the involved association ends are ownedAttributes of the respective classes (Person), one would expect the object specifications (Don, Josh) to have Slots for these ends. Similarly one would expect the link InstanceSpecification to somehow reference its ends. Since a Slot can only belong to one InstanceSpecification, this is currently only possible by duplicating Slots and InstanceValues between object and link InstanceSpecifications (at least that is how e.g. Rational does it). This leads to two problems. First there is of course a lot of redundancy and chances for inconsistency. Second, and more importantly, there is no easy way to navigate from an object InstanceSpecification to the "connected" link InstanceSpecifications. On type level, an association can reference member ends that are owned by other classifiers. For the sake of consistency and simplicity, we would suggest something similar on the instance level for the InstanceSpecification-Slot relationship, i.e. a memberSlot referencing Slots owned by other InstanceSpecifications (maybe in a specialized LinkSpecification). I have created some diagrams to better illustrate the problem, albeit for a different example: - The example: http://www.reckord.de/uml/example.png - What it currently looks like on the meta level: http://www.reckord.de/uml/example-metaobjects.png - What it could look like: http://www.reckord.de/uml/example-meta-fixed.png

Merged with 9961

The specificMachine association of metaclass ProtocolConformance is of type ProtocolStateMachine, which would seem to prohibit the specificMachine from being a BehaviorStateMachines::StateMachine. However, the text sections of section 15.3.5, including the Description and Semantics sections, are very clear that the conforming StateMachine may be a BehavioralStateMachine::StateMachine, which make sense. So the specificMachine association should be changed to be type StateMachine. Also, Figure 15.5 should be similarly changed.

The protocol conformance relationship was explicitly intended to model relationships between protocol state machines
(this is clearly stated in the spec). It is unclear what would be the precise meaning of that type of relationship between
different kinds of state machines, but, whatever it might be, it is likely to be complex, dealing with issues such as
behavioral equivalence. This is still an open research topic with many different approaches and not something one
should standardize as yet.
Disposition: Closed - No Change

[2] The type and ordering of the result output pin are the same as the type and ordering of the open association end.
let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)>asSequence()>first().end in

"AssociationEnd" -> "Propertye"

[3] The multiplicity of the open association end must be compatible with the multiplicity of the result output pin.
270 UML Superstructure Specification, v2.2
let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)>asSequence()>first().end in

"AssociationEnd" -> "Propertye"

[4] The open end must be navigable.
let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)>asSequence()>first().end in

"AssociationEnd" -> "Propertye"

[5] Visibility of the open end must allow access to the object performing the action.
let host : Classifier = self.context in
let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)>asSequence()>first().end in

"AssociationEnd" -> "Propertye"

See issue 6462 (resolved in UML 2.3) for disposition

1)>[1] The operation allConnections results in the set of all AssociationEnds of the Association.

"AssociationEnds" is "Properties", isn't it?

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

[3] The query allParents() gives all of the direct and indirect
ancestors of a generalized Classifier.
Classifier::allParents(): Set(Classifier);
allParents = self.parents()>union(self.parents()>collect(p |
p.allParents())

It seems to be lack of the last parenthesis.

Indeed, there is a missing closing parenthesis.

Classifier has association end "attribute". The association should have the opposite
side of "attribute". Such association end should be "Classifier::attribute".
In the case of "Class", "Datatype", "StructuredClassider" (however, there is a typo),
"Signal", such element have "Classifier::attribute" association end.
However, Interface and Artifact don't have such association end.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

ownedAttribute : Property[0..*]
References the properties owned by the classifier. (Substes StructuredClassifier:: role,
Classifier.attribute...
~~~~~~~~~~~~~~~~~~~~
Classifier::attribute?

No Data Available

However, according to the class description for Property,
Property is "from Kernel and AssociationClass".
Property is defined in Interfaces Package.
Therefore, it seems Property is "from Kernel, Interfaces and AssociationClass".

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

"clientDependency: Dependency[*]
Indicates the dependencies that reference the client."

This explanations is described in "Attribute" clause, not Associations" of NemedElment.
It seems to be in incorrect clause.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

"A property related to a classifier by ownedAttribute represents an attribute..."
and in its semantics
"When a property is owned by a classifier other than an association via ownedAttribute, then it represents an attribute of
the class or data type."

However, in the case of "StructuredClassifier", "Signal", "Artifact",
"Interface".
"attribute" is not necessary

The specification should modified as followings.

p125 L7:
"A property related to a classifier by attribute represents an attribute,"

and

p128 L17
"When a property is owned by a classifier other than an association, then it represents an attribute of the classifier."

The issue is not correct. All attributes are in fact owned via a property called ownedAttribute, different in each case,
but this is true for all subclasses of Classifier including Interface, Signal, Artifact, etc. So the text is correct.
Disposition: Closed - No Change

[4]The query isAttribute() is true if the Property is defined as an attribute of
some classifier.
context Property::isAttribute(p : Property) : Boolean
post : result = Classifier.allInstances->exists(C|c.attribute->includes(p))

This OCL means there is at least one element of Property.
Then, it is better to represent as "not classifier->isEmpty, not "Classifer.allinstances"
like opertation [3]. It is better to represent similar style in a same block.

This issue relates to aleady mentioned issue(Issue 11120). However, it is not exactly same.

Merged with 11120

The first paragraph of section 7.8 suggests that the UML kernel is the merge of Core::Abstractions packages. To obtain Classifier in the UML kernel, we would have to merge Classifiers, Super and Generalizations from Core::Abstractions. How is this possible given that: a) there are no generalization relationships among Classifier metaclasses in these Abstractions packages b) there are two matching operations:

::Classifier::parents (a) means that Generalizations::Classifier::parents cannot redefine Super::Classifier::parents. Even if there were a generalization, the resulting merged model would be ill-formed because it would include a generalization self-loop. (b) means that the merge is ill-formed because it violates constraint #4 defined in the general package merge rules in 11.9.3 (p. 164) POSSIBLE WORKAROUND: - split Core::Abstractions::Super in two packages: Super and SuperParents which only defines Classifier::parents - ditto for Core::Abstractions::Generalizations - if Super is to be merged but Generalizations isn't, then merge SuperParents as well. - if both Super and Generalizations are to be merged, then merge GeneralizationsParent but not SuperParents This is a kludge but that's the only short-term workaround I can find for this bug at this time.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

page 50, the "nestedClassifier" association of Class is described like this: "References all the Classifiers that are defined (nested) within the Class. Subsets Element::ownedMember" page 148, the "packagedElement" association of Component is described like this: packagedElement: PackageableElement [*] "The set of PackageableElements that a Component owns. In the namespace of a component, all model elements that are involved in or related to its definition may be owned or imported explicitly. These may include e.g., Classes, Interfaces, Components, Packages, Use cases, Dependencies (e.g., mappings), and Artifacts. Subsets Namespace::ownedMember." This means a Class may own a Component and this Component may own a Package. I wonder what a Class owning (transitively) a Package could mean.

This is one example of the unintended consequences of Component inheriting from Class. We may observe a related consequence, that it is possible for a Component to own another Component in two ways: as a nestedClassifier, and as a packagedElement. There is no distinction, notationally or otherwise, between these two modes of ownership.
We can resolve these by adding two constraints to Component:
· A Component's nestedClassifier collection is always empty.
· If a Component is nested in a Class, then its packagedElement collection is empty.

for Port, there is a constraint that say :

[1] The required interfaces of a port must be provided by elements to which the port is connected.

I believe that ports are connected by delegation connector, this constraint may not be checked!

Am I right?

You are right, and this constraint is more correctly covered by a revised constraint [1] in chapter 8.

As it is intended by the current specification, an Interaction may be modeled independent of any BehavioredClassifier, which owns it. This would e.g. allow to use Interactions to model communication between analysis objects at a very early analysis stage, where no classes have been designed yet. The intention is manifested in the specification by allowing that a Lifeline or Messages does not have to specify a Property (Multiplicity of 0..1 of Lifelines->represents) or a Connector (Multiplicity of 0..1 of Message->connector) respectively (and that an Interaction does not have to be owned by a BehavioredClassifier). However, the restriction that every OccurrenceSpecification, and as such also every MessageOccurenceSpecification has to be associated with an event (compare Figure 14.5 on page 462) prevents that an Interaction may be used in above described manner. The reason for this is is as follows: 1) As the absense of a MessageEnd has another semantics (the MessageKind is inferred from it), in above described scenario, MessageEnds should indeed be specified (a complete message would be the only appropriate kind to model communication between objects as in above described scenario) 2) Because of above described multiplicity constraint, the MessageOccurenceSpecifications serving as sendEvent and receiveEvent of the message have to refer to some SendSignalEvent/ReceiveSignalEvent or SendOperationEvent/ReceiveOperationEvent respectively. 3) Those events in turn require to specify a Signal or Operation (see Figure 14.2 on page 459). 4) The Signal or Operation would have to be owned by some Classifier. There is however no Classifier in above described scenario, with exception of the Interaction itself (adding the Signals or Operations to the Interaction itself, would however require that all Signals and Operations are named unique, which is inappropriate). I would thus propose to change the specification, so that MessageOccurenceSpecifications (or OccurenceSpecifications) may, but do not have to specify an event (i.e. change multiplicity from 1 to 0..1).

Changing this cardinality in the metamodel is a breaking change, and is unnessary.
It seems that, if you are modeling the sending of a message, then you are modeling that something is being sent. This
.something. can be modeled as a signal, even if, at an early stage of analysis, this is just a placeholder for more detail
to be added later.
There are no constraints requiring that a message signature refer to an operation or signal reception defined for the
type of the ConnectableElement associated with a Lifeline.
Disposition: Closed - No Change

In chapter 15.3.12 (p. 568) the keyword "final" is informally introduced for states: "the states VerifyCard, OutOfService, and VerifyTransaction in the ATM state machine in Figure 15.42 have been specified as

after or below the name of the State."

Agreed. The “final” keyword should be explained in the section describing the notation for state machines
and not in the examples paragraph, it should also be added to the list of keywords in Table C.1 in the
appendix

Section 11.3.25 gives the definition of MultiplicityElement::compatibleWith as: compatibleWith(other) = Integer.allInstances()-> forAll(i : Integer | self.includesCardinality implies other.includesCardinality) While technically correct, this may be a little impractical for any OCL interpreting tool. I think an alternative, that simply uses the upper and lower bounds, would be: compatibleWith(other) = other.includesMultiplicity(self)

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

Various readers are interpreting InstanceSpecification differently. One interpretation is that a particular InstanceSpecification specifies a particular instance. A second interpretation is that a particular InstanceSpecification may be used to specify more than one instance. I prefer the second interpretation. This is supported by the Note at the bottom of page 83 that refers to "... such structures."