There is no documented standard serializiation of MOF 1.4 as an XMI 2.0 schema. OMG has published a document for MOF 1.3 as an XMI 2.0 document and MOF 1.4 and an XMI 1.2 DTD, but not MOF 1.4 as an XMI 2.0 schema. This is despite the fact that XMI 2.0 was designed around MOF 1.4. As far as I know, OMG has not released a single full XMI 2.0 schema example. Do any exist?

This is requesting that an XMI-compliant XML Schema be provided for MOF itself, as an example of a metamodel. This is an issue for MOF not XMI.

Revised Text:

• none -

Disposition: Transferred to MOF RTF

The document MOF 2.0 XMI Mapping (ptc/04-06-11) contains some (typographical) errors in the EBNF for XML Schema Production (Chapter 8). The proposed corrections are listed below: 1g. XMIFixedAttribs ::= ( "<xsd:attribute ref=’xmi:id’" "use=’optional’>" | "<xsd:attribute name=’" //Id attrib name// "’" "type=’xsd:ID’ use=’optional’>") "<xsd:attributeGroup ref=’xmi:ObjectAttribs’/>" 4. ClassTypeDef ::= "<xsd:complexType name=’" //Name of Class// "’" ("mixed=’true’")? ">" ( "<xsd:complexContent>" "<xsd:extension base=’" 4a:ClassTypeName "’")? ("<xsd:choice minOccurs=’0’ maxOccurs=’unbounded’>" | "<xsd:sequence>")? ( 4b:ClassContents | "<xsd:any minOccurs=’0’ maxOccurs=’unbounded’ processContents=’" // ProcessContents Value // "’/>")? ("</xsd:choice>" | "</xsd:sequence>")? 4g:ClassAttListItems ( "</xsd:extension>" "</xsd:complexContent>" )? "</xsd:complexType>" 7a. AssnElmtName ::= 1h:Namespace //Name of association// 8. EnumSchema ::= "<xsd:simpleType name=’" 8a:EnumTypeName "’>" "<xsd:restriction base=’xsd:string’>" 8c:EnumLiterals "</xsd:restriction>" "</xsd:simpleType>" Futhermore, production rule 4i contains a reference to QName. This is neither a rule nor a terminal/placeholder. Please clarify. Regards, Mick Baggen Principal Consultant Technolution

This is now section 5.2.1. There are more syntax errors in the EBNF rules than pointed out in the original issue, and the current formatting of the EBNF rules in the document allows ambiguous interpretation. Therefore, most EBNF rules in section 5.2.1 will be replaced.

Inside UML and SysML, there are cases where opaque content occurs as strings. In particular, in the body of comments and constraint expressions. In SysML it is suggested that MathML be used for parametric constraints, similarly Z can be used instead of OCL. MathML is an XML language, and Z may be interchanged using ZedML, an XML language. In comments, it would be nice to allow XHTML for formatting rich text. At the moment, these are all possible by escaping the XML in the opaque string which ends up in an attribute value: <Unable to render embedded object: File (XMI SYSTEM "http://schema.omg.org/spec/XMI/2.1" [ <!ENTITY math "http://www.w3.org/1998/Math/MathML"> <!ENTITY modelica "http://www.modelica.org/documents/ModelicaSpec21.pdf">]> <xmi:XMI xmlns:UML="http://schema.omg.org/spec/UML/1.4" xmlns:SysML="http://schema.omg.org/spec/SysML/0.9" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"> <Documentation> <shortDescription>Some queries on parametric constraints in SysML.</shortDescription> </Documentation> <UML:Model name="BaseLibrary" xmi:id="z0"> <ownedElement xmi:type="UML:Package" xmi:label="BasicPhysics" xmi:id="z1"> <ownedElement xmi:type="SysML:ParamConstraint" xmi:label="NewtonsSecondLawOfMotion"> <ownedElement xmi:type="SysML:Parameter" xmi:label="F" type="Force"/> <ownedElement xmi:type="SysML:Parameter" xmi:label="m" type="Mass"/> <ownedElement xmi:type="SysML:Parameter" xmi:label="a" type="Acceleration"/> <ownedElement xmi:type="UML:Constraint" constrainedElement"> <) not found.-- SysML suggests MathML as a constraint language, but the body of a constraint is defined as a string, so XMI maps it to a xsd:string. This means XML literals such as MathML have to be escaped. This complicates general XML tool based queries of the model. -> <specification xmi:type="UML:OpaqueExpression" language="&math;" body=" <math xmlns="&math;"e;> <apply> <eq/> <ci>F</ci> <apply> <times/> <ci>m</ci> <ci>a</ci> </apply> </apply> </math> </math> "/> </specification> <Unable to render embedded object: File (type="UML:Expression" symbol="&math;#eq"> <operand xmi:type="UML:Expression" symbol="F"/> <operand xmi:type="UML:Expression" symbol="&math;#times"> <operand xmi:type="UML:Expression" symbol="m"/> <operand xmi:type="UML:Expression" symbol="a"/> </operand> </specification> <) not found.- In UML2 specification is multiplicity [0..1]; is there no mechanism for specifications in multiple languages? You /could/ use an 'one-of-n' Expression on these, but that sort of implies the expressions may be evaluated, rather than 'choose the one you can evaluate in your context', which is what you can do with XPath and the language attribute. Should you define multiple constraints in such cases, even though it's the same constraint, expressed in a manner to be processed by different tools? -> <specification xmi:type="UML:OpaqueExpression" language="&modelica;" body="F = m * a"/> </ownedElement> </ownedElement> </ownedElement> </UML:Model> </xmi:XMI> If you are post-processing the XMI using standard XML technologies (XPath, XSLT, XQuery), it is far better to have XML as nested elements rather than escaped strings even using XMI's option for having a <body> element will still require the content to be xsd:string. Can the mapping be changed so that opaque content is string or any element() from a different namespace, allowing MathML and ZedML to be used as opaque constraints and XHTML etc. as comments without breaking the way XML is intended to work? The data value is opaque anyway, and converting XML to escaped XML inside XML is reduces generic tool support and adds no value. This may need to effect the UML core too- changing the type of the opaque string to OpaqueString rather than string; alternatively a tag 'org.omg.xmi.parsedContent' could be added to indicate the string (assumed to be a valid XML document fragement) is serialised as parsed XML content rather than unparsed content. It is understood that Extension elements allow xsd:any content, but in these cases the structured content is the actual value of the attribute as an opaque string, rather than an extension to the model - the body of the contstraint is the MathML, just as much as it would be if it were OCL, rather than the MathML being additional, vendor specific data. Pete

Note: The sample XMI in the issue is not valid in that it shows instances of SysML stereotypes nested within their owning UML elements. Furthermore, as the issue later acknowledges, XMI allows properties to be serialized as XML elements instead of XML attributes: this can be forced by setting org.omg.xmi.attribute to true at either the property or Class or package/profile level.

The issue asks: “In UML2 specification is multiplicity [0..1]; is there no mechanism for specifications in multiple languages? “
Though not an XMI question, the answer is ‘yes’: in Finalization of UML 2.0, OpaqueExpression::body and OpaqueExpression::language were made multi-valued.

The substantive issue is how to allow nesting of other XML in the attribute value.
This can be achieved by using xsd:anyType as the value of the org.omg.xmi.schemaType property. This validates the following:
<body>
<math xmlns="math">
<apply>
<eq/>
<ci>F</ci>
<apply>
<times/>
<ci>m</ci>
<ci>a</ci>
</apply>
</apply>
</math>
</body>

This Tag could even be added to the UML metamodel by the SysML Profile XMI to change the serialization specifically for SysML (though this would risk interoperability with UML tools).

Revised Text:

• none -

Disposition: Closed – No Change

Section 9.5.3 on p64 has a bullet:
"Addition to Rule 1 for the EMOF package: in some well-defined cases, derived information has a more compact form than (and should be serialized instead of) the information it is derived from. Examples from the UML2 superstructure are multiplicity and generalization."

and on p65 has the following bullet:

"No special serialization rules need to be defined for subsetted Properties. Following EMOF rule 1, when one of the subsetted or subsetting Properties is derived, it is not serialized by default. Properties that are not derived are serialized."

However the referenced EMOF rule 1 was removed from the XMI submission prior to adoption (it is there in ad/02-12-07): it was in (what is now) section 9.5.2 as the first bullet under the table and stated:
"• Derived information is not serialized."

So as things stand the specification does not hang together, since there are references to a non-existent rule. And subsetted properties would always be serialized (unless a tag is used to override)

In general it does not make sense to serialize derived information since it bloats the file, is redundant, and in the bulk of cases derived Properties are readOnly so cannot be used on import anyway. So the rule from the original submission seems to be make sense - especially as there is the ability to override the default. Not having the rule means that all the derived Properties in UML (for example) would have to be explicitly tagged with serialize=false.

With respect to the 'well defined cases' where derived is serialized, it should be made clear that it is up to the metamodel definition (e.g. UML) to do the efinition of which derived properties are to be serialized. It is misleading to refer to specifiy examples which may or may not be correct (at time of writing UML does not do this).

Proposed resolution
----------------------------

1. Reinstate the missing rule by adding a new first bullet in section 9.5.2:

"• Derived information is not serialized."

2. In section 9.5.2 replace the bullet:

"Addition to Rule 1 for the EMOF package: in some well-defined cases, derived information has a more compact form than (and should be serialized instead of) the information it is derived from. Examples from the UML2 superstructure are multiplicity and generalization."

With

"Additional to the first bullet in rules for the EMOF package: for some metamodels, it may be desirable to serialize particular derived Properties, since the derived form has a more compact form than (and should be serialized instead of) the information it is derived from. In this case the default behavior can be overridden by setting the serialize tag to 'true' for the derived property and to 'false' for the base Property (or Properties). However this step should be taken with caution since it also requires the derived property to be writeable (isReadOnly=false) and, to be able to import the information, it must be possible to reverse-derive the base information from the derived form."

3. Section 2.9.8, replace

"The serialization tag is provided to optionally suppress derived data."

with:

"The serialize tag is provided to optionally include derived data."

4. Section 2.12.1, in the entry for serialize, replace 'boolean' by 'string' in column 2, 'true' by' non-derived' in column 3 and in column 4 replace:

"If false, suppresses serialization of the MOF construct. Typically applied to derived features."

with:

"If 'non-derived' then the MOF construct is serialized unless it is derived. 'true' forces the construct to be serilized regardless of wheher it is derived; and 'false' suppresses the it regardless."

5. Rule 2h on page 61. Replace:

"You must not serialize an attribute or reference at all if the value of the org.omg.xmi.serialize tag is "false"."

With:

"You must not serialize an attribute or reference at all if the value of the org.omg.xmi.serialize tag is "false"; or the value of that tag is "non-derived" and the attribute or reference has isDerived="true"."

This has already been resolved and completed in a previous RTF. Close no change.

Disposition: Closed – No Change

The document MOF 2.0 XMI Mapping (ptc/04-06-11) contains some (typographical) errors in the EBNF for XML Document Production (Chapter 9). The proposed corrections are listed below: 1a:XMI ::= "<" 1b:XMINamespace "XMI" 1c:StartAttribs ">" ( 2a:XMIObjectElement)* ( 3:Extension )* "</" 1b:XMINamespace "XMI>" 1b:XMINamespace ::= (1h:NsName ":") ? 1e:Namespaces ::= 1f:XMINamespaceDecl ? ( "xmlns:" 1h:NsName "=’" 1i:NsURI "’" )* 1f:XMINamespaceDecl ::= "xmlns=’http://www.omg.org/XMI’" | "xmlns:" 1h:NsName "=’http://www.omg.org/XMI’" 1g:Namespace ::= ( 1h:NsName ":" )? 2h:FeatureAttrib ::= 2i:XMIValueAttribute | 2j:XMIReferenceAttribute 3:Extension ::= "<" 1b:XMINamespace "extension" (" extender=’" // extender // "’")? (" extenderID=’" // extenderID // "’")? ">" // Extension elements // "</" 1b:XMINamespace "extension>" Furthermore, the notation for placeholders throughout the document is inconsistent. Chapter 8 uses text in enclosed double slashes (//placeholder//), whereas in Chapter 9 (without any introduction) placeholders are shown in italics. Please clarify or correct.

This is now section 6.4.1. There are more errors in the EBNF rules than pointed out in the original issue, and the current formatting of the EBNF rules in the document allows ambiguous interpretation. Therefore, all EBNF rules in section 6.4.1 will be replaced, and the missing rule “3. Extension” added.

Section 7.8.7 and example in 9.5.3.1 state that structured datatypes should be represented in a 'flattened' structure as a sequence of strings separated by commas in an XML attribute. Though the rules for the representation are very informally specified through examples only, the normative text saying only: "The values of the Properties are serialized as a single string separated (by default) by commas. The default separator can be overridden by the XMI valueSeparator tag."

This is impractical for several reasons:

• it does not allow string values that may contain quotes or commas: although the separator may be changed at the attribute level this is not very helpful and there is no means of escaping the separator character;
• it breaks other XMI rules (for example a multivalued property is forced to use the XML element form and not the XML attribute form);
• it breaks principles of composability - the same value will appear quite differently if nested in a structure than if it appeared as a property value in its own right;
• it is against guidelines for designing XML structures and is inconvenient to process using most XML technologies. Indeed it is against the whole principle of XML which is for self-identifying structures and is very fragile to metamodel changes;
• it fails if any of the properties of the structure have multiplicity of other than 1..1. For example for a DataType PersonName with properties: title [0..1] forenames[1..*] lastName[1] suffixes[0..*] it would be impossible to parse the string e.g. "Duke, John, William, London, Squire";
• it's trying to optimize the wrong thing: human readability rather than computer processability;
• it introduces an arbitrary inconsistency with XMI 2.0;

Proposed change

Retain the current flattened XMI 2.1 format only as a special option triggered using a new tag org.omg.xmi.flattenStructuredDataTypes (which should default to "false"). This should be restricted in use only for structures whose properties (including nested properties) all have multiplicity of 1..1.

The default should be to use the XMI 2.0 format for structures: the text should be taken from section 3.5.1 of the XMI 2.0 spec formal/05-05-01.

The serialization of structured datatypes as flattened strings is inconvenient at minimum, but frequently ambiguous so that it cannot be parsed back into correct value assignments to the corresponding fields of the structured datatype. Revert to the class-like serialization of XMI 2.0 and allow flattening only for non-nested structured datatypes with field multiplicity [1..1] as a special case, controlled by a new tag org.omg.xmi.flattenStructuredDataTypes, which shall default to false.

This problem is preventing me from implementing an XMI 2.0 Schema generator for a MOF 1.4 metamodeling environment. In Section 2.2.1, rule 6f, nested Package elements contained within the complexType definitions of their encapsulating Packages refer to global Package element definitions using the namespace-qualified name of the nested Package. But global Package elements are never associated with their namespace-qualified names, so the reference cannot be resolved. Rule 6a, which defines namespace-qualified Package names, only gets used a single time during schema generation: in rule 6f. This makes it impossible to correctly generate a schema from a metamodel which includes nested Packages.

As per the resolution to 9694, PackageElements serve no purpose and so this can also clear up this issue – by deleting the whole of rule 6 in section 5.2.

Revised Text:
(see resolution of issue 9694)

Disposition: Closed – Duplicate / Related to 9694

This problem is preventing me from implementing an XMI 2.0 Schema generator for a MOF 1.4 metamodeling environment. XMI 2.0 Schema: There is no rule for generating type or element declarations for Classifiers nested inside of a Class. MOF Classes don’t get corresponding XMI namespaces. XMI 2.0 seems to ignore the fact that MOF Classes define Namespaces. It is completely valid in MOF to have a Class A which contains an Attribute B and a Class C, where Class C serves as the type of Attribute B. You could also replace ‘Class C’ with any DataType subtype – say ‘CollectionType C’. However, there is no rule for declaring types or elements for nested Classifiers, so the specification does not say how to declare the type of serialized Attribute B. Even if there were a rule for type and element declarations for Classifiers nested within a Class, the nsPrefix and nsURI tags only apply to Packages. Since Classes don’t define XMI namespaces, any nested Classifiers are going to suffer from name collision. If you look at the Eclipse Modeling Framework, you can see how implementers of MDA standards have gotten around this. The MOF-based EMF metamodeling language (ECORE) simply doesn't allow nested Classifiers or DataType subtypes other than EnumerationTypes and PrimitiveTypes. XMI 2.0 is supposed to be designed with MOF 1.4 in mind, so I shouldn't have to limit my metamodeling environment to a subset of the expressive power of MOF just for the purpose of XMI metamodel interchange.

Resolution:
MOF has never permitted nested classes in metamodels: Class::nestedClassifier was added in UML superstructure. For MOF 2.4 which is based on Superstructure, an explicit constraint was added, as part of MOF Issue 15398, that for metamodels Class::nestedClassifier must be empty. Hence no XMI rule is needed for these.

Revised Text:

• none -

Disposition: Closed – No Change

This issue is preventing me from implementing an XMI 2.0 Schema generator for a MOF 1.4 metamodeling environment. The specification contradicts itself regarding the type specification of MOF Attributes. >From section 1.8.4: “The XML element corresponding to the attribute is declared in the content of the complexType corresponding to the class that owns the attribute. The type specification is either an XML schema data type, an enumeration data type, or a class from the metamodel.” Then, in section 2.2.1, rule 4d: “The type is “xsd:string” for simple attributes, the name of an enumeration for enumerated attributes, or part of the value of the org.omg.xmi.schemaType tag, if present.” I have no idea what the specification means by “simple attribute” (the phrase appears just that one time in the entire document), but the two statements above are clearly out of sync and confusing. Also, the type of an attribute might be something other than a metamodel Class, PrimitiveType, or EnumerationType in MOF 1.4: it might for example be a CollectionType or an AliasType. Rules are provided for serializing these other DataType subtypes as Classes, but they themselves are not metamodel Classes.

(now sections 4.8.4 and 5.2.1)
“simple attribute” is actually a well established term, meaning an attribute which can be represented as a single value.

Also the MOF 1.4 types mentioned in the issue: CollectionType and AliasType are no longer present in MOF 2.x

See resolution for issue 8884 regarding structured DataTypes.

Revised Text:

• none -

Proposed Disposition: Closed – No Change

In the normative XMI file for the metamodel, no Associations have a
name.
The name is needed for generating APIs and (in some cases) XMI elements;
and their absence actually makes UML2 an invalid MOF2 metamodel: MOF2
Core has the following constraint for CMOF:
[6] Names are required for all classifiers and features (though there is
nothing to prevent these names being automatically generated by a tool).

(Association is a classifier)

We could get by with not having a name in the MDL and auto-generating a
name into the XMI. This is in fact what the Unisys XMI plug-in did when
no Association name was provided - and this was hence reflected in the
normative XMI for UML 1.x (the names were of the form A_<end1>_<end2>).

No Data Available

page 429 Constraints for message need to include "no EventOccurences before receiving the create message". In the graphic notation this is handled by defining the create graphic path as flowing into the Lifeline head symbol, but since we do not want to introduce the concept of a Lifeline head in the meta-model, we need an additional constraint.

Constraints need to be updated as new sorts of messages are added.

No Data Available

In section 11.5.1 (DataType) the first association is specified as:

ownedAttribute: Attribute[*] The Attributes owned by the DataType.

This is out of date: the class Attribute has been replaced by Property,
though the association name is OK referring to 'Attribute'. This is
reflected in the diagram above that text (Fig 86).

Proposed resolution:
Replace the above text with:
ownedAttribute: Property[*] The Properties owned by the DataType.

No Data Available

The example text <Company xmi:id="Company_1" name="Acme"> <HQAddress xmi:id="Address_1" Street="Side Street" </Company>City="Hometown"/> should be <Company xmi:id="Company_1" name="Acme"> <HQAddress xmi:id="Address_1" Street="Side Street" City="Hometown"/> </Company>

No Data Available

Should Component::provided and Component::required really be derived? It seems that these sets of interfaces should be subsets of the sets of interfaces implemented/used by the component and/or its realizing classifiers, not derived from them

No Data Available

This is a general issue that is quite pervasive. I think it is important
enough to be considered by the FTF.

The specification is littered with keywords which are used on diagrams
to indicate various things.

What the specification sorely needs is an Appendix that gathers them all
together. And cross-references each with where it is defined and the
compliance level it is associated with.
Also what it needs is a general description of the semantics of
keywords, how they differ from 'Standard Stereotypes' and associated
constraints - e.g. it should not be allowed to declare a Stereotype with
a name which, when decapitalized, is the same as a keyword (since they'd
be indistinguishable).

Arguably keywords would be depicted with a distinct notation from
stereotypes (based on language design principles and to help users
interpret diagrams where they see words in guillemets and don't know
whether to look it up in the list of keywords or stereotypes) but that
is probably too major a change to make at this stage. However the
notation should be clarified to cover the following cases:
A) if the same element requires a keyword and has a stereotype applied
are they shown in 2 separate <<xxx>> expressions or in one, separated by
a comma?
B) if a stereotype is applied to a class normally indicated by a
keyword, does that keyword still need to be provided?

see above

This is in my opinion important enough to be considered by the FTF since
it affects implementability.

Appendix B contains a list of Standard Stereotypes.
Ironically, due to the nature of the UML2 Profile mechanism this
mechanism is more heavyweight than a subclass since it requires a
separate instance - so for the <<call>> stereotype of Usage one ends up
with not only a instance of Usage but an attached instance of Call -
this is far more heavyweight than having a distinct subclass of Usage
which would result in only one object. And it's also harder to process
via XMI or APIs.

The Appendix is not adequate as a definition and does not use the
official Stereotype notation? In particular it does not make clear the
name of the instance of Stereotype (which I can only guess would be the
capitalized form of the stereotype keyword e.g. "Call"), nor does it
specify the name of the association used to attach an instance of the
stereotype with the instance of the metaclass. And, of course, is there
actually a Profile object (or objects) that contains these stereotypes?
Can users consider this Profile already applied to any UML model or does
it have to be explicitly done or is this a variation point?

Finally, Appendix B is not properly referenced: 7.14.1 refers to the
"Standard Profiles chapter" and 8.3.3 and 10.3.1 refer to "The UML
Standard Profile".

see above

The description of Lifeline on p. 427 (and Figure 331 on p. 409) indicates that the Lifeline::decomposedAs property is mandatory. This property refers, indirectly through a PartDecomposition, to an interaction the describes the internal workings of the ConnectableElement that the Lifeline represents.

Unfortunately, there are common situations in which the decomposedAs property cannot be specified because the ConnectableElement is not decomposable (i.e., is not structured). In fact, the first constraint on p. 431 in the description of the PartDecomposition metaclass makes this very clear: "PartDecompositions apply only to Parts that are Parts of Internal Structures not to Parts of Collaborations."

Therefore, we would request that the specification be amended to make the Lifeline::decomposedAs property optional (multiplicity [0..1]). If you can amend the generated multiplicity in your API in advance of any changes to the spec, that would be greatly appreciated!

see above

"The contents of the Interfaces package is shown in Figure 51. The Interfaces package is one of the packages of the Classes package. "

Should be "Figure 58"

see above

Should InteractionFragment::enclosingOperation be navigable? The association end is named and even has a subset constraint, but the association isn't navigable in that direction for some reason (see Figure 329).

see above

In section 7.14.1 (Abstraction) it is stated explicitly that the mapping associated with an abstraction is optional (as it should be, since we do not necessarily want to have a mapping attached to every kind of abstraction). However, the diagram in figure 51 has a multiplicty of 1 for the "mapping" role (at the Expression end). This should be changed to 0..1.

see above

ParameterableElement::owningParameter should subset ParameterableElement::templateParameter

see above

The sections of the spec that describe the run-time semantics of UML are scattered throughout the document and not clearly identified. There should be at least some convenient guide in the document that would help locate those sections.

see above

on page 115 (section 7.15.3) when talking about the Notation of an
interface, the third paragraph (between figure 59 and 60) says:
"
The usage dependency from a classifer to an interface is shown by
representing the interface by a half-circle or socket, labeled
with the name of the interface, attached by a solid line to the
classifier that *implements* this interface (see Figure 60).
"

And I think it should say:
"
The usage dependency from a classifer to an interface is shown by
representing the interface by a half-circle or socket, labeled
with the name of the interface, attached by a solid line to the
classifier that *requires* this interface (see Figure 60).
"

see above

The importedMember property is derived from the ElementImports and the PackageImports.

self.importedMember->includesAll(self.importedMembers(self.elementImport.importedElement.asSet()>union(self.packageImport.importedPackage>collect(p | >p.visibleMembers()))))

The query importedMembers(...) should be importMembers(...). A fixed version is:

self.importedMember->includesAll(self.importMembers(self.elementImport.importedElement.asSet()>union(self.packageImport.importedPackage>collect(p | >p.visibleMembers()))))

see above

On page 408 there is text that says:

Gates are just points on the frame, the ends of the messages. They may have an explicit name. See Figure 335.

I think it should say:

Gates are just points on the frame, the ends of the messages. They may have an explicit name. See Figure 336.

On page 414 there is text that says

See example of the usage of collaboration occurrences in Figure 345.

I think it should say:

See example of the usage of collaboration occurrences in Figure 339.

No Data Available

There is a missing closing bracket in slot->forAll(s | classifier->exists(c | c.allFeatures()->includes(s.definingFeature) )

The correct version is: slot->forAll(s | classifier->exists(c | c.allFeatures()->includes(s.definingFeature)) )

see above

"• value : InstanceSpecification [*] ~~~~~~~~~~~~~~~~~~~~~ <<<< should be ValueSpecification The value or values corresponding to the defining feature for the owning instance specification. This is an ordered association. Subsets Element::ownedElement

see above

Currently, the UML 2 specification defines Operation properties precondition, postcondition, and bodyCondition that are owned constraints. However, these properties do not subset the Namespace::ownedRule property, but rather the Namespace::ownedMember property.

The opposites of these properties are preConstraint, postConstraint, and bodyConstraint, all of which are non-navigable and subset Constraint::context and Constraint::namespace.

Also, the Constraint::namespace property, which is non-navigable, subsets Constraint::context, which is navigable. This is inconsistent, and in fact violates the UML's own constraint on property subsetting which stipulates that a navigable property can only be subsetted by a navigable property (constraint [4] of metaclass Property).

The consequence of all this is that a Constraint that is the precondition (for example) of an Operation does not have a context . This means that a constraint such as an OCL expressions in pre-conditions cannot be parsed against the context namespace.

There are (at least) two ways to solve this problem:
let Operation::precondition and its cohorts subset Namespace::ownedRule instead of Namespace::ownedMember (which would leverage the eContainer() "cheat" that EMF offers to get the owner of an element that doesn't have a navigable owner property)
let Constraint::namespace redefine NamedElement::namespace and make it navigable, thus making the subset relationship with Constraint::context valid

The first option seems preferred, for two reasons:
It makes sense that all constraints that a namespace owns should be included in the ownedRule property
This would be consistent with the Behavior metaclass, whose precondition and postcondition properties do subset ownedRule

see above

It seems to me the the following properties should perhaps be ordered (currently they are not):

ApplyFunctionAction::argument
Association::endType
CombinedFragment::operand
ConnectableElement::end
InteractionOccurrence::argument
Message::argument
StringExpression::subExpression
StructuredClassifier::ownedAttribute
TemplateSignature::parameter

see above

There appears to be an inconsistency in the specification as to what it
means to be a formal parameter or a return result. Please choose between the
following two interpretations:

A. A return result is a parameter that is specially indicated to be the
return result. All other parameters are formal parameters.

B. A return result is any parameter with direction return, out, or inout. A
formal parameter is any parameter with direction in or inout.

You could view (A) as focusing on the syntactical role the parameters play,
while (B) focuses on when they communicate data.

The difficulty arises from that the infrastructure and the superstructure
have differing machineries of dealing with parameters.

This is a duplicate of issue 7344

03-08-02.pdf: page 412: consider/ignore - I can find no explanation of how
the message types to be considered/ignored are modeled. The spec should be
clear on this issue, probably in the description of combined fragment.

see above

Figure 428 says that TemplateParameterSubstitution::ownedActual has a multiplicity of (0..1). However, the association description on page 549 states that the multiplicity is (1..). However, it seems to me that the multiplicity was intended to be 0.. despite what the diagram (and Rose model) seem to suggest.
This is because a template substitution may not necessarily own any of its actual parameter values.

see above

The new rule for extension end role names as adopted in ballot 10 (specifically for metaclass extension role names) is likely to lead to name collisions. For example, a stereotype that extends the Package metaclass with a property named 'basePackage' would conflict with the recommended role name of the metaclass extension end ('basePackage'). The recommended role names should be less likely to collide with names that might be chosen for stereotype properties, for example, base$"ExtendedMetaClassName" (i.e. base$Package).

see above

Enumeration is a subtype of DataType, and DataType allows both Properties and Operations. And since Enumeration has no additional constraints, this means that Enumeration also allows owned Property and Operation instances. Is there a reason why this is so? I would have expected an OCL constraint that limited the owned members of Enumeration to be only EnumerationLiteral instances.

EnumerationLiteral is a subtype of InstanceSpecification, which itself is a subtype of PackageableElement. Because Package and own any number of PackageableElements, Package can actually own EnumerationLiteral. Is there a reason why this is so? The sematics talk about EnumerationLiteral being in the scope of an Enumeration, but it is somewhat vague about whether that is a constraint (there are no additional constraints). I would have expected an OCL constraint stating that EnumerationLiteral is only valid in the context of an Enumeration.

No Data Available

The owners of the metaclasses InformationFlow, ParameterSet, and PrimitiveFunction are not defined

see above

Currently, a State is not a namespace, even though it contians things such as entry and exit pseudostates, substates, etc. all of which are in the context of a State. Therefore, State should be made a kind of Namespace as well as being a kind of Vertex. (Note that Vertices in general do not need to be Namespaces.

This issue is resolved by the resolution to issue 6207.

03-08-02.pdf, page 163:
Specifies a link that enables communication between two or more instances.
This link may be an instance of an association, or it may represent the
possibility of the instances being able to communicate because their
identities are known by virtue of being passed in as parameters, held in
variables, created during the execution of a behavior, or because the
communicating instances are the same instance.

Doesn't this imply a semantic variation point?

No Data Available

In figure 317, Trigger is defined as a specialization of Element. However, it seems reasonable for triggers to have names, so it really should be a subclass of NamedElement

see above

The current model of use cases does not allow navigation from a subject classifier of a use case to its use case. It should be possible to do this, so that a classifier can easily identify which use cases apply to it. The proposed resolution is to make Classifier::useCase navigable.

see above

It would greatly improve readability if every metaclass had a section that listed all the immediate superclasses of that class. This would also make the document consistent with the resolution to issue 7156, which indicates that such a subsection should exist.

see above

Maybe this is a stupid question. But I could not find an answer ... A transition is not required to have a trigger. If the source of the transition is a composite state, its triggering is described by the rules about "completion transitions". But what happens if the source is just a simple state: It would seem that the transition cannot be considered as a "completion transition", but at the same time, the transition never satisfies the rules about "enabled transitions". Hence it woulds seem that the transition is simply never enabled. Is this interpretation correct? If so, it this behaviour really intended?

see above

In the UML Sequence diagram there are asynchronous message that is very useful in designing application. I am trying to create an activity diagram between 4 asynchronous system. Why cant we have asynchronous arrow in activity diagram between swim lanes? That is the true representation of a flow in a distributed system.

No Data Available

UseCase - Constraint for non-circular include relation

I suggest to add the following fragments to the sections "Additional Operations" and "Constraints":

Additional Operations [1] The query allIncludedCases() gives a set of all of the uses cases which are either included directly by this use case or indirectly by other included use cases.

UseCase::allIncludedCases(): Set(UseCase); allIncludedCases = self.include->union( self.include->collect(uc | uc.allIncludedCases()) )

Constraints [4] A Use Case may not directly or indirectly include itself not self.allIncludedCases()->includes(self)

see above

UML 2.0 does not state which level of MOF (EMOF, CMOF, or
whatever else) provides its meta-meta-model. Therefore, there is
no formal statement defining which Class definition (Basic or
Constructs package level) and so forth is the basis for the
definitions in the UML 2.0 specification. UML tools implement
this class, so it's probably a good idea to know which one it's
supposed to be. (Proof, in case you're wondering: The names
EMOF and CMOF do not occur anywhere in the Superstructure
final adopted specification 03-08-02. The name MOF does, but
not in the context of which version of MOF defines the
UML metametamodel.)

If there is an ambiguity in which it is, the FTF needs to resolve
it. Once it's resolved ("The metamodel for UML 2.0 is CMOF"), it
should be stated clearly in the specification.

see above

Table 28 in the appendix identifying standard stereotypes identifies that the "realizes" stereotype of Abstraction has been retired. However, on page 110 it is stated that the notation for a Realization dependency is a dependency with the "realize" keyword attached to this. Although this could be explained by saying that the keyword has not been retired whereas the stereotype has, this is very confusing and appears contradictory. I suggest we eliminate the table entry in Table to 28 that specifies that the "realize" stereotype has been retired.

The bigger problem, perhaps is that the difference between keywords and stereotypes is not properly explained anywhere (at least not where I could find it). Perhaps the Notation appendix should discuss this.

No Data Available

It seems that the lower bound of Feature::featuringClassifier should perhaps be 0 (not 1) to allow for the situation in which a Property is owned not by a class, association, or data type, but another property (as one of its qualifiers)

see above

Top of page 367, text says:
Activity diagrams have graphical elements for containment. These
are included in Table 13.

In the next line, the table caption says:
Table 13 - Graphic nodes included in activity diagrams

Proposed resolution:
These are inconsistent, although not necessarily wrong. They should be
made consistent.

see above

Middle of page 366, text says:
The graphic paths that can be included in structural diagrams are
shown in Table 12.

In the next line, the table caption says:
Table 12 - Graphic nodes included in activity diagrams

Proposed resolution:
The table caption is correct, and the text above it needs to be changed
to conform.

see above

Inconsistent labeling of tables in Section 12.4, Activities.Diagrams:

Issue 1:
Top of page 365, text says:
The graphic nodes that can be included in structural diagrams are
shown in Table 11.

In the next line, the table caption says:
Table 11 - Graphic nodes included in activity diagrams

Proposed resolution:
The table caption is correct, and the text above it needs to be changed
to conform.

see above

Table 9 on page 199 references pages such as 10-50, 26-201. These are not valid page number in the spec.

see above

Table 22 on pages 523-524 is titled "Graphic nodes used in sequence diagrams" but should be titled "Graphic nodes used in use case diagrams"

see above

UseCase - Include - Constraint for irreflexivity

I suggest to add the following constraint for Include:

Constraints [1] An include relation is irreflexive, i.e. source and target are not equal. self.addition <> self.includingCase

This issue is resolved by the resolution to issue 6965.

A quick survey of the superstructure spec reveals the following places where Dependency is defined (and I probably missed some):

Fig 51, P.106, shown as NOT abstract - this is where the Dependency package is shown
Table 4, P.130, defines a visual symbol for it
Fig. 101, P.155, shown as abstract
Fig. 126, P.183, shown as abstract
Fig 130, P.188, shows a pure dependency in an example
Table 9, P.199, defines a visual symbol for it

Most of the text also refers to the section containing figure 51 for the definition of dependency. If I were reading the spec, I would tend to consider the section where it is defined as the authority and dismiss the others as errors made by those writing the other chapters.

see above

UML2 superstructure 03-08-02
p. 513
"[1] An actor can only have associations to use cases, subsystems, components and classes, and these associations must be binary."

A subsystem is a component stereotype, so it doesn't make sense to mention it here.

I would propose the following constraint instead of the above one:
"[1] An actor can only have associations to classifiers, and these associations must be binary."

It makes sense that an actor can have binary associations to the subject they are interacting with.
The subject of an use case is a classifier.

see above

In most cases, when a metaclass is refined in a package, the phrase used in the title of the class description is "as specialized". In a few places, however, it is flagged as just "specialized". This needs to be made consistent.

see above

In UML Superstructure, ad/03-08-02, Section 14.4 "Diagrams", page 443,
figure 346, bottom right box labeled "sd Q", the label "ysuperB" needs
a colon, and should be "y:superB" (as it is in the top right box).

see above

There are three different ways to specify text strings used in the notation and two variations.

The three ways:

1. a sort of Bakus-Naur form as in: multiplicity ::= <multiplicity_range> [ ‘

’ ] see Super 7.4.1

2. a second way as in: [visibility] [/] name [: type] [multiplicity] [= default] [

] {{ [ name ] ‘:’ classname } | name } [ ‘[‘ multiplicity ‘]’ ] see Super 17.5.7

The two variations:

a. Sometimes a single bracket does double duty as in: direction name : type-expression [multiplicity] = default-value [

] see Super 7.10.1 Here, the brackets around multiplicity indicate both that multiplicity is optional, and that the multiplicity is to be shown inside brackets. see Super 7.10.1

b. Sometimes the brackets are not used when an item is optional as in: visibility name ( parameter-list ) : property-string see Super 7.10.1

see above

Appendix A of the superstructure spec specify the usage of frames
in diagrams. The text says:
"Each diagram has a frame, a contents area, and a heading, see Figure 460."

This statement implies that frames are normative. The text later says
that "In cases where not needed, the frame may be omitted and implied by the border of the diagram area provided by a tool."

This entire explanation distorts the common intent and practice of UML
diagramming. Text should present the frames as an optional presentation
option in the first place. Also, in all cases mentioned (ports, entry points)
it is possible to notate the context using class boxes or states, so in none of these cases frames are "needed". It is a mere presentation option that might be

used as an alternative to using prime container symbols.

see above

In Fig. 192 on pg. 277, the association end StructuredActivityNode::activity, the constraint

is duplicated

No Data Available

The semantics of isStatic = true is ambiguous for structural features
declared on classifiers that have children. It is not defined whether
this gives a single value for the classifier and all its descendents,
or values for the classifier and each descendant separately.

This is the same issue as issue 6974

There is a serious model consistency issue with InteractionFragment::enclosingOperand because it is currently constrained to be a subset of NamedElement::namespace, but its type (InteractionOperand) is not a specialization of Namespace. Also, InteractionOperand::enclosingInteraction does not subset NamedElement::namespace (it probably should; Interaction is already an indirect specialization of Namespace).

The simplest solution is to make InteractionOperand a specialization of Namespace

see above

there appears to be a bug in the specification with respect to the definition of the makesVisible() OCL query on packages. Here is the OCL expression from the specification (page 100):

Package::makesVisible(el: Namespaces::NamedElement) : Boolean;
pre: self.member->includes(el)
makesVisible = el.visibility->isEmpty() or el.visibility = #public

As you can see, this definition makes even imported elements visible based on their own visbility rather than the visibility of the import
relationship. The same applies to elements made visible indirectly via a package import.

see above

It seems that there is an issue with the hasVisibilityOf(NamedElement) operation on Classifier. In particular, it doesn't consider visibilities when determining if a member is visible:

Classifier::hasVisibilityOf(n: NamedElement) : Boolean;
pre: self.allParents()>collect(c | c.member)>includes
hasVisibilityOf =true

One might logically expect the operation to exclude, for example, members with private visibility.

see above

I am looking at ValueSpecification which introduces Additional Operations, such as integerValue(). My question is : What is the reasoning behind making these Operations vs. Derived attributes?

In MultiplicityElement we have a derived attribute lower which is equal to lowerBound(). What logic is used to determine whether an Operation has a corresponding Attribute?

Also the spec seems to indicate that all derived values will be implemented via some operation. Is this a requirement or an assumption of implementation?

Why can’t lower in MultiplicityElement simple be defined as if lowerValue->notEmpty() then 1 else lowerValue.integerValue()… what makes the lowerBound() operation required?

No Data Available

Today, the reason for this mail is that in my UML certification I was asked a question regarding the include and extend relationship between use cases.
I was (and am still a bit) confused, because one question was dealing with the extend and include notation between use cases. I think the 640 pages UML 2 documnet 03-08-02.pdf is inconsistent here. (I now ask because I think I lost two correct answers in my fundamental UML 2 certification caused by include/includes and extend/extends...): UML 1 used the stereotype notations "extends" and "includes". Im UML 2, the classifiers are now called "include" and "extend". But confusingly enough, some association arrows inside the OMG document 03-08-02.pdf
"UML Superstructure 2.0 Draft Adopted Specification" use the stereotypes (see <<extends>> and <<includes>> in Fig 406 p. 521 and twice <<extends>> and one time <<includes>> in Table 22 on page 523/524.)

Who to report these inconsistencies to? Or are the stererotypes still allowed to be labeled <<extends>> and one time <<includes>> ?

Duplicate of issue 6465.

p587 para 2 line 2 "UML diagrams contains graphical elements" (should be "contain")
p587 para 5 line 1 "symbols defines the type" (should be "define")
p587 last para "C1 and C1" (should be "C1 and C2")
p588 para 1 line 2 "a graphical symbols" (should remove "a")
p588 para 1 line 4 "assocition"

see above

Semantics of the alternative CombinedFragment (page 410) does not describe what happens if all branches are guarded, and
all guards are false.
Does this means: a) empty trace, or b) (dynamically) invalid trace ?
I suggest to add a sentence, defining such traces as dynamically invalid.
This will be consistent with the behavior of a ConditionalNode in Activities (page 313): "if no test section yields a true value, then no body section is executed; this may be a semantic error if output values are expected from the conditional node".

see above

The Classes chapter is organized differently from all other chapters in the document – it should be made consistent with the organization of all the other chapters

see above

In figure 354 on page 457, it is shown that it is not possible to navigate back from Region towards either the state machine that owns it or the state that owns it. However, it is often necessary to know who the owner of a region is, therefore these associations need to be made navigable in both directions.

see above

Different chapters in different parts of the spec use different conventions for naming, headings, layout etc. These should all be made consistent based on one shared convention.

This is resolved by the resolutions to issue 6958 and 7190.

The document needs an explanation of how it is laid out and how the format and meaning of the various sections in the individual class descriptions

see above

In my interpretation of the current semantics description of UML
activity diagrams (Superstructure, Final Adopted Spec, ptc/03-08-02) I
have identified some rather unpleasant properties of the current
traverse-to-completion semantics. The full discussion together with
examples can be found in the attached .pdf, the short of it is:

*) the current semantics does not prevent deadlocks (as it is
supposed to do)

*) it rather induces deadlocks even in simple examples (e.g. examples
in the UML spec are wrong)

*) it makes for a very complex evaluation and introduces unnecessary
synchronization in the (basically asynchronous) notation of Activiy
Diagrams.

I therefore propose to relax the semantics of token flow by dropping
the constraint that every Action has to accept all tokens for all its
input pins at once. MergeNodes should als be able to buffer tokens
until their conditions are satisfied. This is a more natural way of
interpreting ADs.

see above

In section 10.3.2 and Figure 125 the constraint is given that a
CommunicationPath can only associate Nodes.
This seems too restrictive and does not, for example, allow
CommunicationPaths between actual servers (Instance Specifications).

Proposed resolution:
Relax constraint such that a CommunicationPath can link
DeploymentTargets.

see above

UML::StateMachines::BehaviorStateMachines::Region::transitions should be renamed to transition (i.e. made singular) to be consistent with the naming convention for other association ends.

see above

page 178, table 6 - the entry for port shows the only option for a port as
being on the boundary of an enclosing box whereas the notation section for
ports (169) states that port boxes may be shown inside the boundary of the
enclosing box. The port entry on table 6 should amended so that it includes
all cases.

page 179, the table is headed table 6 but should be table 7.

see above

figure 274 - should the arrow between Award Quote and Quote Responses be the
other way round

see above

Can a connector be typed by an association one of whose ends are composite
or shared? I can't see anything in the spec that prohibits this but I'm not
sure that it makes a lot of sense to do so.

No Data Available

Page 415-6 Figures 334,335 use a rectangular box with the text "DoSth" in it. The meaning of this symbols is not explained in the corresponding section, nor in Table 14 graphical nodes in Sequence Diagrams.
In ITU Message Sequence Charts this would mean an informal action, local to the Lifeline.

The syntax and semantics of local actions is the key issue in "executable sequence diagrams", and in proper alignment of semantics between Interactions, Activities and State Machines (and Actions).

As a minimum, Figures 334, 335 need to be explained, and table 14 updated.
It would be better to illustrate formal use of Actions.
Ideally, Interactions will benefit from a data sublanguage based on Actions, in order to have a capability to fully specify flows of data between Lifelines:

• message parameters (including composite values)
• local attributes (storing data in Lifeliens; in data structures like lists, sets, tables, etc.)
• identities of objects (input and output pins for actions)
• actions (manipulations on data, access to data structures and composite values)
• proper usage of data in guards and state invariants
• proper usage of data in loop expressions

see above

page 410 mentions that "Break CombinedFragments must be global relative o the enclosing InteractionFragment".

This is ambiguous and needs to be explained in more precise way, involving InteractionOccurences and Interaction Overview Diagrams. There were debates on the scope of a similar construct in the ITU language.

see above

The enum type name InteractionOperator is often misspelt (e.g. interactionOperator or interaction operator). It is also used inconsistently when referring to a particular operator, e.g. InteractionOperator alt.
I suggest using a single typigraphic convention:
InteractionOperator <italic> alt </italic>

see above

Page 416:

The sequences of Eventoccurences are the meanings of Interactions. >>Messages are sent through either asynchronous signal sending or operation calls.<<
Likewise they are >>>recieved<<< by >>Receptions or actions of consuption.<<

typo needs to be corrected.
highlighted parts need to be re-phrased and terminology aligned with the rest of the spec.

see above

It is not possible to visually distinguish between a continuation (oval with a name) and a simple state invariant (also oval with a state name). Compare Figure 345 and 334.

One possibility is to use guard syntax for state invariants.
Another possibility is to use a different graphic for continuations

No Data Available

The semantics of isStatic = true is ambiguous for structural features
declared on classifiers that have children. It is not defined whether
this gives a single value for the classifier and all its descendents,
or values for the classifier and each descendant separately.

see above

UMl 1.x sequence diagrams had a notation for self-activation, where the activation boxes (now called "execution occurrences" in UML 2) can be nested.

E.g. UML 1.4, Notation, Sequence Diagrams, section 3.60.4, figure 3-56

This notation is missing from UMl 2.0 Interactions chapter. No alternative notation is provided.

duplicate

Most sections in chapter 14 on Interactions do not have a Rationale subsection, while the remaining few only contain the text "not applicable". This is not informative.
I suggest to remove the Rationale subsections altogether.

Pages 414 421 423 425 428 430 433

Remove the empty “Rationale” sub-sections on pages 414, 421, 423, 425, 428, 430, 433.

Grammar for <state-info> at page 434 has a typo:
<state-info>::=<region}

*

It is not clear, how to define <region-name> in Sequence Diagrams.

see above

Page 410 The word "execute" is used to describe the Alternative CombinedFragment i nthe context "operand will execute", etc. This word is ambiguous. I suggest changing it to "operand is chosen", etc.
Or even the full description, like "the meaning of the InteractionOperator alt is a trace corresponding to only one of its operands".

see above

page 433 has the following text: "A StateInvariant is a constraint on the state of a Lifeline. In this case we mean by "state" also the values of >>eventual attributes<< of the Lifeline".

The term >>eventual attribute<< may be ambiguous.

see above

Page 450 has the following text:
"The graphic nodes that can be included into >>structural diagrams<< are shown in Table 19". Table 19 has the following title "Graphic nodes and paths included in >>sequence diagrams<<"

The text needs to be changed into "The graphic nodes >>and paths<< that can be included into >>timing diagrams<< are shown in Table 19"

Title of Table 19 should read "timing diagrams" instead of "sequence diagrams".

see above

Page 436 has the following text:
"The graphic nodel that can be included in >>structural diagrams<< are shown in Table 14."

Table 14 is called "Graphic nodes included in sequence diagrams".

Text needs to be changed into "sequence diagrams"

This is a duplicate of 6934, already resolved

There are multiple places in the Interaction section, where class name EventOccurence is spelt incorrectly (usually as Eventoccurence).

pages 403 410 411 416 417 419 420 422 427 429 431

see above

On page 411 subsection for Critical Region mentions the InteractionOperator "critical", while the metamodel uses the enum "region".

see above