On behalf of Gilles Malfreyt, Thales Group:

p.15: Associations "members" from Perspective and from Category to PatternDefinition seem redundant with the fact that InterpatternRelationship already has an association with PatternDefinition [p.6]: wouldn't it be better to make this existing association bi-navigable?

The bi-navigable relationship would lose an important aspect of Perspectives and Categories as independent views into a repository of IPMSS definitions. A Category is a 'kind of' grouping for PatternDefinitions. A Perspective is a 'stakeholder view' grouping for PatternDefinitions. The MITRE folks asked for this distinction to allow for a more flexible way of presenting patterns catalogs to stakeholders who may have vastly different expectations of how to 'slice' Categories.

Specification: Implementation Patterns Metamodel for Software Systems RFC (admtf/14-03-01)
Artifact: Updated IPMSS XMI (admtf/14-03-03)

The IPMSS XMI declares the xmi namespace as http://www.omg.org/spec/XMI/20131001, which is the namespace for XMI 2.5, and also declares the uml namespace as http://www.omg.org/spec/UML/20131001, which is, consistently, for UML 2.5. However:

• All hrefs in the file to UML primitive types reference the file http://www.omg.org/UML/20110701/PrimitiveTypes.xmi, which is the primitive types file for UML 2.4.1. For consistency, these references should be changed to the corresponding file for UML 2.5, http://www.omg.org/UML/20131001/PrimitiveTypes.xmi.

• The file contains several hrefs to http://www.omg.org/spec/UML/20110701/Infrastructure.xmi#Core-Basic-Element and http://www.omg.org/spec/UML/20110701/Infrastructure.xmi#Core-Basic-Property. These should be changed to the UML 2.5 references, http://www.omg.org/UML/20131001/UML.xmi#Element and http://www.omg.org/UML/20131001/UML.xmi#Property. (Even in the case of UML 2.4.1, the references should have been to the UML.xmi file, not the infrastructure.)

I propose that Ed's suggestions be adopted.

On behalf of Gilles Malfreyt, Thales Group:

[following the fact that we don't understand the use of the boolean expressions (are they used for pattern conformance ? as set-like operations for combination of patterns ??...)]:

p.11: We don't understand at all the usage of VariableToRole, PropertyToVar, PropertyToRole.

Clarify FormalBinding

FormalBinding was causing confusion, add explanatory text to provide guidance.

On behalf of Olivier Constant, Thales Group:

My main concern is about the "formalism" concepts from Section 10, which are central in the specification. There seems to be a Boolean interpretation for FormalDefinition and all its subclasses, but this interpretation is not explicitly explained. What does it represent? Is it related to pattern conformance? It seems to me that this is a major issue.

Add explanatory text to Formalisms package to clarify intentions and applicability

The Formalisms package was lacking sufficient explanatory text to allow for implementation solely on the basis of the specification. This is now fixed. No changes made to metamodel or semantics, this is strictly explanatory text, but a significant amount of it.

On behalf of Olivier Constant, Thales Group:

p.9. Section 9.2 states that "At least two Bindings will be associated with each PatternInstance, one for each Role in the matching PatternDefinition". However, Figure 4 and the description of role "fulfillments" in section 9.2 only specify a multiplicity with a lower bound of 1. Furthermore, section 8.2 and Figure 3 specify that a PatternDefinition may have a unique Role, which contradicts the sentence.

One sentence in 9.3 (previously 9.2) mismatches the multiplicity stated in the remainder of the text. Fix to bring in line.

On behalf of Olivier Constant, Thales Group:

p.6. Role PatternDefinition::relatedPatts in Figure 3 is named "relatedPatterns" in section 8.2.

p.9-10. Role PatternInstance::instanceOf in Figure 4 is named "instantiates" in section 9.2.

p.9-10. The multiplicity of role PatternObservation::foundVia is inconsistent: [*] in Figure 4, [0..1] in 9.3.

Confirmed that XMI and Figures in question are correct, the text is incorrect.

Editorial comment from Manfred Koethe, 88 Solutions, that Figure 3 needed a non-content-altering tweak of the position of some text. Updated Figure 3 is attached.

The specification does not (or I missed where) list the accompanying machine readable files listed in the inventory. Seems to me it ought to do so. The FTF can certainly fix this one.

List the machine readable files on the specification cover under "Normative Machine Consumable Files" using document URIs as reported by Juergen.

On behalf of Olivier Constant, Thales Group:

p.14, section 10.11: "an MOF::Property, such as an MOF::Class or MOF::Type". In MOF, a Class or a Type is not a Property.

MOF::Class and MOF::Type were incorrectly stated to be subclasses of MOF::Property. Text is corrected to no longer make this statement.

On behalf of Olivier Constant, Thales Group:

p.11. Figure 5, a note states "Element must own Property". This implies that the Element be a MOF::Class/DataType/Association/Extension. What is really meant, according to my understanding, is "Metaclass of Element must own Property". A similar issue arises in section 10.11 in the description of PropertyToRole::from.

MOF hierarchy false implication needs to be clarified. The intent was not that a MOF::Element contain a MOF::Property, as that limits the relationship to a certain subset of MOF classes. Instead, a metaclass was intended. The text in Figure 5, Sections 10.11 and 10.2 needs to be changed to reflect this.

On behalf of Elisa Kendall, Thematix:

A couple of nits – on the cover and in the inventory I noticed you included /PDF/ in the URI for the specification. While in practice that's where the pdf version of the specification might be posted, there might also be a PS version for postscript, etc, and I don't think you want the URI with /PDF/ in it to be the definitive URI for the spec on its cover. Linda would likely catch this in document production, but it's one of the first things I'd fix in FTF. Similarly in the inventory, URLs for the specification don't look right to me, for example, I would think that "http://www.omg.org/spec/IPMSS/PDF/IPMSS1.0.pdf" should be something closer to "http://www.omg.org/spec/IPMSS/1.0/IPMSS.pdf", and similarly with the changebarred version.

Adopt Elisa's suggestions to remove '/PDF' from URIs, confirm document numbers/URIs w/ Juergen prior to submission.

On behalf of Gilles Malfreyt, Thales Group:

p.25: section 12.5 Multiplicities: it seems that what is proposed leads to duplicate pattern instances each time a role is multiple.
Maybe it would be interesting to also have the case where roles are multiple without duplicating pattern instances.

Stacked PINboxes (12.5.1) and the MultiBranch annotation (12.5.2) are designed to handle precisely this case, as shown in Figure 19 and 20 on page 26. If this is not clear, then we can clarify.