The PatternSection class currently only allows a simple string for the body attribute. It would be much more useful if it were to allow any MOF::Element based entity to represent the body. This would allow for not only richer text, but also diagrams, a remote URI (as a structured URI, not just a string), or other expression.

Note that the image in Figure 8.1 and the XMI file in SPMS 1.2 were both correct, this only affects the prose in Section 8.5.

Redefine PatternSection:body as a MOF::Element

PatternSection:body will be an attribute of type MOF::Element instead of string. This requires changing both the descriptive text in Section 8.5 and Figure 8.1 to match.

Section 12.6 discusses Multiplicity of PINboxes and Equalities, but does so a bit oddly. While it may have made sense to discuss the topic in one place, the effects are seen in PINbox, Equality, and BindingGlyph classes. It probably makes more sense (particularly for PINbox, where the Stacked view is dependent not on an explicit enum, but on an implicit multiplicity of its instances association), to move this discussion into the relevant sections.

Only moving the PINbox discussion would be acceptable, but clarifying text ought to be added to Equality and BindingGlyph as well.

Leaving the bulk of the Equality and BindingGlyph discussion in Sec 12.6 would then make sense, and it, coupled with Sec 12.7, would make for a good set of topics for guidance on visualization techniques that do not directly rely on the metamodel. (Peeling & Coalescing in particular is a UX behavior that does not currently have a reflection in the metamodel.)

Provided forward pointing hints, instead of moving sections.

While moving the Multiplicity sections was an option, no edits were satisfying, and instead this approach makes the minimal change that accomplishes much of the same goal.

A forward hint is added to each of Sections 12.3, 12.4 and 12.5 that refer to Section 12.6. These inform the reader of an additional twist to each situation, that will be discussed in detail in 12.6.

ISO-IEC Directives Part 2, Sec 22.3.3 indicates that no content should appear between a Clause title and the first Subclause, if it exists.

https://isotc.iso.org/livelink/livelink/fetch/2000/2122/4230450/4230456/ISO_IEC_Directives%2C_Part_2%2C_Principles_and_rules_for_the_structure_and_drafting_of_ISO_and_IEC_documents_-_2018_%288th_edition%29_-_PDF.pdf

Section 14 has as paragraph and figure prior to 14.1 Move that content to 14.1, and adjust remainder of Section 14 subsections accordingly.

Added Section 14.1 heading title

Added "14.1 Introduction" title to content immediately after Section 14 header. Remainder of Section 14 subsection numbering adjusted accordingly.

In Figure 8.1 - Definitions Package, there is a directed association from PatternElement to Formalisms::FormalizedDefinition.

This should be coming from PatternDefinition. The text in Section 8.3 PatternDefinition is correct, the figure is not.

Modified Figure 8.1 as needed

Moved the root of the directed association to SPMS:Formalisms:PatternDefinition from PatternElement, to PatternDefinition, to match the correct text in Sec 8.3.

This is a very convoluted diagram, and may benefit from providing multiple instances of both RES::Field and RES::Method at the top to help reduce the number of crossing lines.

Reworked Fig 16.1 for clarity

Moved items around for better spatial arrangement. No content changes.

Figure 12.1 - PIN Module: Equality class does not show the style : MultiplicityStyle attribute indicated in the text in Section 12.4. The text is correct.

Fixed Figure 12.1 to add attribute to Equality class

Added indicated attribute to Equality class

The association 'equivalents' of the Equality class is missing any textual description.

Add required description.

Section 12.4, page 33 (spec PDF page 33) Added descriptive text to 'equivalents' association in Equality class.

Middle of first paragraph, "Design Patterns" is both italicized and underlined. Remove underlining.

Remove underlining of book title

Sec 8.5, pg. 12 (spec PDF page 20), the book title Design Patterns needs the underlining removed.

First line under definition of term Pattern:

"Desing Patterns, Gamma et al."

Desing -> Design

Italicize "Design Patterns" as title of book.

Fixed listed typos

Title of book misspelled, and not italicized.

Update Diagram Definition reference in the first line of second paragraph to 1.1.

Update DD 1.0 to 1.1

Update numeric reference.

The normative references include UML 2.5 but MOF 2.4.1: MOF 2.5.1 should be referenced since it’s mutually dependent with UML 2.5.

There is also now Diagram Definition, 1.1.

Normative references should be updated to most current referred specifications.

References to UML, MOF, and DD need to be made consistent through prose and XMI files, and should refer to the most current specification available, if the most recent spec does not change backwards compatibility.

Consumers of SPMS have requested the ability to include diagrams, pointers to existing documents, etc., in the section bodies.

Provide guidance on using PatternSection::body as a URI for external resource tracking.

A request was made to allow for richer descriptions in PatternSections than simple strings. The simplest, backward compatible patch for this is to provide guidance such that, if a user enters a simple URI into the body property, that URI is expected to point to an external resource that contains the description for that PatternSection.

Specifically, Word files were requested. As we have no functionality within the OMG specs for directly embedding this data within a model in a meaningful manner, the URI method is workable.

Section 10.1, page 18, paragraph 1:

"Because we desire multiple definitions of a pattern for a variety os use cases,"

should be

"Because we desire multiple definitions of a pattern for a variety of use cases,"

Fix typo

Section 10.1, page 18, paragraph 1 contains a typo:
"Because we desire multiple definitions of a pattern for a variety os use cases,"
should be
"Because we desire multiple definitions of a pattern for a variety of use cases,"

It is not clear initially how or if a formalism can refer to multiple sub-formalisms. While the model allows for it, the text does not make this explicit. Suggestion to add explanatory text to section 10.1.

Clarify that a FormalizedDefinition can be composed of other FormalizedDefinitions

Recommend to replace Section 10.1 Paragraph 3 from:
Because we desire multiple definitions of a pattern for a variety of use cases, many instances of FormalizedDefinition can be referenced by a single PatternDefinition. Each of these FormalizedDefinitions, in turn, can be composed using an extremely lightweight boolean logic mechanism defined here, to allow the composition of model fragments from a number of modeling domains. This satisfies our need for a single pattern formal definition requiring multiple views to properly describe the pattern. Many patterns, for instance, have both unique structural forms and run-time behaviors. It is unlikely that a single OMG model is going to capture all the nuances of each, but a combination of ASTM and OCL models, for instance, or PHORML and KDM, may be sufficient. For this reason, SPMS defines a minimalist composition mechanism for those that wish to have a lightweight yet compliant composition model. For more complex needs, an OCL expression may be used by an instance of DefinitionTerminal referencing an OCL model. This Formalisms package is shown in Figure 5.
With:
Because we desire multiple definitions of a pattern for a variety of use cases, many instances of FormalizedDefinition can be referenced by a single PatternDefinition. Each of these FormalizedDefinitions, in turn, can be composed of further instances of FormalizedDefinitions as sub-models, by using an extremely lightweight boolean logic mechanism defined here. This allows the composition of model fragments from a number of modeling domains into a comprehensive whole. This satisfies our need for a single pattern formal definition requiring multiple views to properly describe the pattern. Many patterns, for instance, have both unique structural forms and run-time behaviors. It is unlikely that a single OMG model is going to capture all the nuances of each, but a combination of ASTM and OCL models, for instance, or PHORML and KDM, may be sufficient. For this reason, SPMS defines a minimalist composition mechanism for those that wish to have a lightweight yet compliant composition model. For more complex needs, an OCL expression may be used by an instance of DefinitionTerminal referencing an OCL model. This Formalisms package is shown in Figure 5.

When reading the Relationships section (11.1) it appears at first glance that a pattern can only be a member of one category at a time. It only becomes obvious after looking at Figure 1 in the Definitions section (8.1) that the multiplicity of memberships in categories is shown there. The model is correct, but explanatory text should be added to section 11.1 to reiterate that a single PatternDefinition can have any number of Interpattern Relationships.

Clarify that a PatternDefinition can have many InterpatternRelationships

Proposed to alter Section 11.1, pg 17, paragraph 1 from:
The Relationships package defines classes to enable rich searching and semantic association in a repository or catalog of PatternDefinitions. The package overview is shown in Figure 6. InterpatternRelationship provides semantic linkages between PatternDefinitions. KnownUse provides specializations of PatternInstances suitable as examples of a PatternDefinition in concrete situations.
To:
The Relationships package defines classes to enable rich searching and semantic association in a repository or catalog of PatternDefinitions. The package overview is shown in Figure 6. InterpatternRelationship provides semantic linkages between PatternDefinitions. A PatternDefinition can have multiple InterpatternRelationship connections to allow for a rich connected network. KnownUse provides specializations of PatternInstances suitable as examples of a PatternDefinition in concrete situations.

Consumers of SPMS have requested the ability to include diagrams, pointers to existing documents, etc., in the section bodies.

Allow PatternSection to contain richer content than a simple string.

Sec 8.1, final paragraph, page 9:

Change from:
Each PatternDefinition contains a list of these Roles, and a list of PatternSections. These PatternSections are prose entries that describe for a human reader the definition of the pattern as defined according to appropriate patterns communities that adopt SPMS.

Change to:
Each PatternDefinition contains a list of these Roles, and a list of PatternSections. These PatternSections entries contain prose, diagrams, or other necessary structured document contents to describe for a human reader the definition of the pattern as defined according to appropriate patterns communities that adopt SPMS.

Sec 8.1 Figure 3, page 10:
Replace with new Figure3.pdf (attached)

Sec 8.5, paragraph 1, first sentence, page 11:
Change from:
A PatternSection is a free-form prose textual description of a portion of a PatternDefinition.

Change to:
A PatternSection is a description of a portion of a PatternDefinition. The description may be free-form prose, diagrams, models, or a structured combination thereof. The body attribute of the PatternSection is a generalized MOF::Element to allow for a multitude of formats and data, although the most common is expected to be simple text.

Section 8.5, Attributes, page 12:
Change from:
body : String The contents of the PatternSection.

Change to:
body : MOF::Element The contents of the PatternSection.

Modification to SPMS1.1.xmi: Convert body element type from PrimitiveTypes.xmi#String to UML.xmi#Element

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.

Clarify that MultiBranched Annotations can be used for multiple roles as well as multiple pattern instances

Submitter of issue requested change to add multiplicity annotation for roles, but the capability was already extant in the specification and figures. Explanatory text needed to be added to make this explicitly clear on reading.

Section 12.6.2, pg 30, paragraph 1 needs to be expanded. It currently reads as:

The MultiBranch annotation can also be used within an Expanded PINbox, as shown in Figure 23. Now, we are showing both instances of the Decorator pattern, unlike in Figure 17 where we showed only one.