Need to update last paragraph on page 6 to reflect existence of version 2.2 of SACM and describe it.

Need to update copyrights and list of submitters too.

Update items in spec to reflect new version

Added sentence about the content of SACM 2.3 and revised previous SACM 2.2 content sentence to be past tense and update Figures 8.1, 9.1, 11.1 and 12.1 to reflect different modeling tool used to generate figures.

The original proposal of an informative uml profile needs to be made normative and covered by a compliance point.

Change of Annex F to Normative and add compliance point

Changing Annex F to be Normative and describe it in section 2 as part of a new compliance point.

The emof file has a missing tag and uses an old version of xmi and the uml profile is not of the correct form due to the tooling used to generate it.

Regenerated SACM machine readable files using MagicDraw

The eclipse tools we had used to generate the SACM machine readable files of the SACM model and the SACM UML profile were not producing appropriate files.

Some how Figure 8.1 was relabeled with the same label as Figure 7.2

Correct label on Figure 8.1

Somehow in the revisions to SACM the figure in Section 8.1 was changed to the label used in the previous section (7.2). This needs to be fixed.

The .xml files for emof and uml were github pages in html that had the expected emof and uml information as tables within the html. Need the content by itself.

Correct content of emof and uml profile files

Pulled intended content out of html encoded material.

mistakenly created

This issue is extraneous and should be closed

This issue was accidentally created and should be removed.

SACM provides an abstract model for information on assurance cases. However, most humans normally interact with assurance cases shown as diagrams with supporting text. SACM 2.1 finally adds a standard graphical notation, and I'm happy to see it.

However, SACM currently does not provide enough information to enable sharing diagrams in this notation. For example, there's no positioning or size information for displaying each ArgumentationElement in an ArgumentPackage. Tools do not always do a great job doing automatic layout, and in any case, humans often set up a layout to maximize human understanding. I believe this inability to exchange such information is a serious weakness in SACM.

There are many ways to include such information.

One way would be to require sharing display information in a standard form (like SVG) and provide a standard way to map between the SVG display information and the metamodel.

An alternative is to extend the metamodel to include display information. Some basic constructs from SVG could be borrowed (being maximally compatible with SVG in general is recommended). An ArgumentationElement could have a new optional "location" with contents min_x, min_y, width, and height per SVG. Each ArgumentPackage would establish a viewpoint (and essentially determine portrait, landscape, or some other display is preferred).

I'm sure there are many details to work out, but the first step is to agree that display information needs to be shared somehow.

Thank you for your time.

Graphical layout formats out of scope of SACM standard

The requested functionality is out of scope of the SACM work.

To allow for more consistent and direct use of SACM concepts in tools and other environments, a SACM UML profile is needed.

Add an annex with a UML profile of SACM

Add a SACM UML profile to allow UML-based tools to work with SACM concepts by leveraging the SACM UML profile.

Having the separate explicit UML profile of SACM that is maintained as part of the SACM specification will allow others to leverage that profile. For example, the GSN team can constrain the SACM UML profile into a GSN UML profile in a similar manner to how they leverage the SACM meta-model to define their GSN meta-model, making it cleaner for external groups leveraging GSN.

To allow for capturing terminology use as it occurs in communities there is a need to support nesting of categories in SACM’s Terminology Category class.

Allow Categories to have sub-categories

Add to SACM::Terminology::Category class a field called category of type Category, with cardinality 0..* allowing composite categories to be directly definable.

For SACM 2.3 the list of companies involved, their respective copyrights, and a sentence about the scope of SACM 2.3 is needed.

This issue is extraneous and should be closed

This issue was accidentally marked as deferred and balloted. The content of the issue was addressed by resolving SACM23-12. This issue is duplicative of that issue.