The notation previously selected for these concepts could cause confusion when viewed by those familiar with UML notations or when viewing UML notations in proximity to these SACM concepts.

New notations for asserted context and asserted artifact context

Replace diamond line heads with squares with small line at end to distinguish them from UML notations in the 19 figures that used diamond line heads.

JS18 - http -> https throughout for omg.org (all URIs)

http -> https in MOF file

https is not supported in MOF 2.0 and we can not generate MOF 2.5.1 from the version of MagicDraw we have available.

JS19 - Why MOF 2.0, and not 2.5.1?  If no technical reason, update to 2.5.1.

Why MOF 2.0

The MagicDraw version University of York has does not support exporting to MOF any more. We are trying to find any alternatives, but in the meantime we are stuck to this version.

JS17 - The PNG images are less than optimal, and fuzzy throughout Section 11 and Annex C in both clean and changebar docs.  SVG preferred in general.  Can these be regenerated appropriately?

PNG images

new figures were generated for previous png figures - will be attached to the new report and used in the updated specification.

JS16 - Filename for SACM21-31/!!.14 - A2B.pdf  - I assume this should be 11.14… that’s going to wreak havoc with some filesystems.

JIRA file names for files included in Report

Passed on to Mariano for resolution - no change in specification or issue resolution materials.

JS15 - SACM21-1 through 13 were unnecessary to add to archive and muddied the waters.  One for Mariano?

SACM21-1 through 13 were unnecessary

When finishing the previous Report - 14 issues that were resolved in that Report were incorrectly passed to this RTF. Referred to Mariano to resolve.

JS14 - Issue 55 (ptc-19-02-33/SACM21-55/11.11-deletion.pdf) includes editorial ‘that’ to ‘whether’ that is listed in changebar as Issue 30.

showing changes from different issue

removed edit notations from a different issue from 11.11-deletion pdf

JS13 - Issue 58 (ptc-19-02-33/SACM21-58/11.13 multiplicity.pdf) does not include the graphic for Figure 7.2 on pg 12 and changes on pg 37 11.14 marked as Issue 31, 20 - should not have been in this file.

multiplicity change missing figures

included figures in pdf of changes

JS12 - Issue 20 (ptc-19-02-33/SACM21-20/Concrete Syntax.pdf) does not include the Concrete Syntax added to Section 11.10 Assertion (abstract) and includes an editorial change (‘that’ to ‘whether’) on page 38 Sec 11.13 under Attributes that is not in the changebar or clean documents for issue 20. 

Missing Concrete Syntax in 11.10

Added note of insertion in early pages of Concrete Syntax pdf for missing Concrete Syntax in 11.10. Change in word ”that” to “whether” is correctly marked as Issue 30 (not 20) in the clean and changebar pdfs. Removed from Issue 20’s Concrete Syntax pdf.

JS11 – In 12.11 Activity, under Attributes, startDate:Date[0..1] does not match naming of type in Figure 12.1, which is startDate:date[0..1] and under Attributes, endDate:Date[0..1] does not match naming of type in Figure 12.1, which is endDate:date[0..1]

Date or date in 12.11

resolve difference

JS7 – In 8.6 ModelElement (abstract), under Associations, need a newline between implementationConstraint and description.

missing newline

added newline to address comment

JS6 – In 8.2 SACMElement (abstract), under Attributes, isCitation and isAbstract do not match multiplicity in Figure 8.1

multiplicity in figure and text do not match

figure is correct - fix text

JS5 - In 6.2 Acknowledgements, there is an extra trailing bullet.

fix trailing bullet

line after bulleted list has an empty bullet - removed.

JS4 - In 3.2 Non-normative References, SPMS is at 1.2, update doc number to formal/17-11-01.

updating SPMS version reference

In 3.2 Non-normative References, SPMS reference updated.

JS3 - Typo on pdf pg 10: Issues: hhttp in URI -> https

hhttp to https

typo in url and need to move to https

JS2 - http -> https throughout for omg.org, please check other sites and changeover as possible for futureproofing ( on omg.org: pdf pgs 1, 3, 4, 9, 10, 16 and pdf pgs 16, 65, 67).

http -> https for document urls?

Reviewed pdf pgs 1, 3, 4, 9, 10, 16 and pdf pgs 16, 65, 67 and updated urls for https were applicable and resolved broken url for fda document.

RB2 – For SACM21-20 the changes are inconsistent with the changes specified in the associated PDF file. In Concrete Syntax.pdf, Figure 11.2 contains the title "Concrete Syntax for ArguementPackage" whereas "ArgumentPackage" is used in the actual text. The misspelled version is still present in the table of contents.

Arguement-Argument

Correct spelling now shown in the track changes and clean specifications - see RB2-Arguement-Argument.pdf

RB1 – Two of the issues, SACM21-14 and SACM21-16, referred to bad urls and were marked as “Closed; No Change,” but the resolution was not specified – what was done to resolve these two issues?

URL reactivated

The web site behind the urls had lost its registration on the University of York DSN system – that was fixed in a day or so.

There are several areas where the work packages for addressing issues 1, 2, 3, 5, 6, 7, 9, 11, or 12 missed changes, additions, and deletions to support internationalization and package simplification. Additionally, there are several style issues in the text that need to be made consistent.

Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

To support multiple stakeholder views and purposes a mechanism for associating SACMElements is needed.

Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

The ability to create patterns (e.g. AssuranceCase patterns, ArgumentPackage patterns, etc) that contain only abstract SACMElements is needed and the patterns should be re-usable.

Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

ArtifactAssetRelationship can be simplified by removing all its sub-classes. The purpose of an ArtifactAssetRelationship can then be recorded by the property +property:Property in the ArtifactAsset class.

Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

Citations can be simplified by removing them from Argumentataion, Artifact and Terminology classes and replacing them with +isCitation and +citedElement properties in SACMElement in the Base classes.

Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

If all elements in Argumentation, Terminology, Artifact and AssuranceCase can be considered as artifacts the assertion that one or more artifact provide context for another artifact; and the assertion that one or more artifact support another artifact needs to be captured.

Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

There are unnecessary differences between the Assurance Case, Terminology, Argument, and Artifact package definitions, interfaces, and bindings.

Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

Need to add internationalization of the languages used so that elements can be described using multiple languages

Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

In packages (e.g. ArgumentPackage, TerminologyPackage), atomic references are too complicated.

Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

There is currently no direct mechanism to support internationalization in SACM content.

Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

In Argumentation package, AssertedRelationship should directly express if it is a counter relationship.

Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

In SACM, all elements in the Argumentation package, Artifact package, Terminology package, and AssuranceCase package are considered to be Artifacts.

Consequently ArtifactElement needs to be moved to the Base classes and be a direct sub-type of ModelElement. All elements in other packages then will sub-type ArtifactElement.

Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

Use “artifact” instead of “artefact” is needed to make incorporation of SACM into The Open Group standards more practical.

Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

p39:Last sentences of 11.13 and 11.14: Is A and B intentionally exchange in "the truth of" parts of the two sentences?

11.13: "An inference asserted between two claims (A � the source � and B � the target) denotes that the truth of Claim A is said to infer the truth of Claim B."

11.14: "An AssertedInference between two claims (A � the source � and B � the target) denotes that the truth of Claim B is said to infer the truth of Claim A."

I would expect that the inference of truth comes from the source and is asserted for the target so the other way than 11.14 Semantics part defines. [Remark: I am not a native English speaker so it might be strange just for me why the "said to infer" expression is used instead of "inferred from". I interpret "The truth of X is said to infer the truth of Y." as "Truth of Y can be inferred from the truth of X." or "The truth of X logically necessitates the truth of Y."- is it correct?]

A and B are mistakenly swapped in the specification text

Need to revise labels in section 11.14 to correctly describe the functionality.

p38, 11.13, Attributes: If "isCounter" seems to be set to false then stating that "a flag indicating that the AssertedRelationship counters its declared purposes" seems to be controversial, although I understand that the "false" is a default value. I think, adding "that whether the AssertedRelationship counters" is more clear. E.g. in 11.10 at a similar case, it writes "indicating the state ..." which was more clear.

Whether for that

The observation is correct - replacing "That" with "Whether" in Section 11.13

The section title "Literals" is misspelled.

Mistakenly opened issue on spelling mistake.

This is correct in specification - was looking at wrong version.

Terminology misspelled as "Termonology" in Section 2.5

Again was looking at the wrong version of the SACM file

The term is correctly spelled - no change needed.

Mistake in element name – remove “Model” from ArtifactModel::ArtifactPackage

Name of element in compliance point mistakenly has "Model" in it

Revise in specification section 2.3 - SACM 2.0 metamodel is not impacted.
ArtifactModel::ArtifactPackage should be Artifact::ArtifactPackage

Need a concrete syntax for the Argumentation metamodel that can represent the semantic definitions of the elements for semantic transparency, easing the burden of learning the elements and allowing them to be perceived directly from the notation.

Concrete Syntax and Graphical notation

As a result of the work by a graduate student at University of York - which was presented in draft at the March and September meetings we now have a proposed graphical notation for the Argumentation portions of SACM. The proposed revisions to the last part of Section 1 to add this to the history of SACM, along with a new compliance point (2.6) for those choosing to support the notation, update to section 5 on symbols, and the specific notations in many parts of section 11, as well as examples in the new Annex C are provided.

There is no discussion of the terminology model’s role in SACM.

No discussion of the role of the terminology model

In the scope of SACM we should include a discussion of vocabulary and the role of the terminology model at a high level.

The Artifact title is misleading label for this portion of the scope description, this section is actually is about Evidence.

Mistakenly opened issue on Section number name.

Thought section was named "Artifact" and wanted to change it to "Evidence" but in fact it was already named that way. Had looked at earlier version of specification.

The constraint section of the class Claims revers to two attributes ("assumed" and "toBeSupported") that are not part of the SACM 2.0 metamodel (they are replaced by the attribute "assertionDeclaration" of type "AssertionDeclaration).

Proposed fix:

Remove the constraint section. It is no longer required, as the "exclusive or"-constraint is already enforced by AssertionDeclaration being an enumeration.

Duplicative request for removal of constraint from 11.11

Addressed in ballot 3.

The multiplicity of +target should be 1 (target:ArgumentAsset[1]).

In 11.13 the +target should have multiplicity of 1

Update text, diagrams, and emof model.

The constraint statement in 11.11 is unnecessary since there is no longer an assumed nor a toBeSupported attribute in the standard

remove unnecessary constraint statement in 11.11

There is no longer an assumed nor a toBeSupported attribute in the standard, can remove the constraint.

Shouldn't have a compliance point for the Concrete Syntax as part of this revision.

Graphical notation for SACM Argumentation concepts

Remove the compliance point and definitions for a graphical notation that maps to all of SACM Argumentation concepts from the body of the specification and putting that graphical notation into an new Annex to parallel the existing notation mappings to SACM contained in Annex A.

Three supporting pdfs provided to 1) remove compliance point and notation definitions from main body, 2) rename Annex C examples to Annex D, and 3) create new Annex C with graphical notations that represent all SACM Argumentation concepts.

JS10 – In 12.9 Event, under Attributes, date:Date[0..1] does not match naming of attribute in Figure 12.1, which is occurence:date[0..1]

Date or date in 12.9

aligned text

JS9 - In 12.7 Artifact, under Attributes, date:Date[0..1] does not match naming of type in Figure 12.1, which is date:date[0..1]

Date or date in 12.7

align spelling

JS8 – In 11.5 ArgumentPackageBinding, under Associations, participantPackage is listed as ArgumentPackageInterface, should be ArgumentPackage to match Figure 11.1.  Change type, or diagram.  The analogous Sec 12.4 ArtifactPackageBinding indicates the diagram here is likely correct.

address discrepancy between text and figure

Figure is correct - made text change

JS1 - Confirm URI on title page: http://www.omg.org/spec/SACM/190235/emof.xml

http -> https

change url on title page

The specification relates to ArtifactPackage, but the description of the package describes it as ArgumentPackage.

Element name mistake in 12.2

In section 12.2 ArtifactPackage the element is mistakenly named ArgumentPackage - should be ArtifactPackage - correct in model.

Details of the of the mapping between GSN elements and SACM are claimed to be at http://www.goalstructuringnotation.info/gsn-metamodel, but the link is invalid.

Fixed within a day of being reported

This broken link was fixed within a few days of being reported.

The association `value` is shown as LangString[1..*], but the semantics describe it as a list of ExpressionLangString, not LangString.

ExpressionLangString should be LangString

Correct element name and change criteria from "must" to "should"

The link "http://www.goalstructuringnotation.info/sacm-examples
Structured" leads to a "Site Unavailable" page.

Fixed within a day of being reported

University of York had an issue with the routing to their web site - resolved shortly after it was reported.

p33: the last two paragraphs seem to be the same (from word to word) except the last words: "AssertedContext" and "ArtifactReference". I have no consistent understanding yet but it seems that the second paragraph should be removed (or something else was intended to be written there).

Duplicative paragraphs needing revision

The two paragraphs at the bottom of page 33 of the specification need to be rewritten and merged to remove duplicative materials.

In section 1.4 there is a missing "," after the word "Basically" at the beginning of the second sentence in the second paragraph. In section 9.2 "top level" should be hyphenated in the second sentence of the first paragraph. In the last sentence of section 11.1 the "." at the end is in the wrong place.

Minor edits to address mistakes

Add comma after Basically in 1.4, in 9.2 hyphenate top-level, and correctly place the period in 11.1

The word contained is spelled as"containined"

Mistakenly opened issue on spelling mistake.

Word correctly spelled - was looking at the wrong version of SACM.

If all elements in Argumentation, Terminology, Artifact and AssuranceCase can be considered as artifacts the assertion that one or more artifact provide context for another artifact; and the assertion that one or more artifact support another artifact needs to be captured.

deferred

Use “artifact” instead of “artefact” is needed to make incorporation of SACM into The Open Group standards more practical.

deferred

ArtifactAssetRelationship can be simplified by removing all its sub-classes. The purpose of an ArtifactAssetRelationship can then be recorded by the property +property:Property in the ArtifactAsset class.

deferred

In SACM, all elements in the Argumentation package, Artifact package, Terminology package, and AssuranceCase package are considered to be Artifacts.

Consequently ArtifactElement needs to be moved to the Base classes and be a direct sub-type of ModelElement. All elements in other packages then will sub-type ArtifactElement.

deferred

In Argumentation package, AssertedRelationship should directly express if it is a counter relationship.

deferred

There is currently no direct mechanism to support internationalization in SACM content.

deferred

In packages (e.g. ArgumentPackage, TerminologyPackage), atomic references are too complicated.

deferred

Citations can be simplified by removing them from Argumentataion, Artifact and Terminology classes and replacing them with +isCitation and +citedElement properties in SACMElement in the Base classes.

deferred

The ability to create patterns (e.g. AssuranceCase patterns, ArgumentPackage patterns, etc) that contain only abstract SACMElements is needed and the patterns should be re-usable.

deferred

To support multiple stakeholder views and purposes a mechanism for associating SACMElements is needed.

deferred

Need to add internationalization of the languages used so that elements can be described using multiple languages

deferred

There are unnecessary differences between the Assurance Case, Terminology, Argument, and Artifact package definitions, interfaces, and bindings.

deferred

There are several areas where the work packages for addressing issues 1, 2, 3, 5, 6, 7, 9, 11, or 12 missed changes, additions, and deletions to support internationalization and package simplification. Additionally, there are several style issues in the text that need to be made consistent.

deferred

In making support for the Terminology Package optional a compliance point for those that want to support the Terminology Package was mistakenly left out.

Add a Terminology Package Compliance point

In the first sentence of section 2.1 change “three” to “four”; in bulleted list in section 2.1 add a fourth bulleted item “Terminology Model”; and add a new section “2.5 Terminology Model compliance point”, with the text “Software that conforms to the specification at the Terminology Model compliance point shall be able to import and export XMI documents that conform with the SACM XML Schema produced by applying XMI rules to the normative MOF metamodel defined in this entire specification. The top object of the Terminology package as a unit of interchange shall be the SACM::TerminologyPackage element.

The Conformance clause identifies with clauses of the specification are mandatory (or conditionally mandatory) and which are optional for an implementation to claim conformance to the specification.”

See pdf “Adding Terminology Compliance Point.pdf” for markup of proposed changes.

Currently, the Artefact, and Activity classes use the type ‘date’ for some of their attributes, and the ‘date’ attribute is missing from the model and diagrams for ActivityEvent, despite appearing in the text of the specification.

Change date to string

In section 12.5.2 (Attributes of Artefact class) change “date: Date” to “date: String”. In section 12.5.4 (Attributes of ArtefactEvent class) add “date: String”. In section 12.5.6 (Attributes of Activity class) change “startTime: Date” to “startTime: String” and “endTime: Date” to “endTime: String”.

See pdf “Model uses undefined date type.pdf” for markup of proposed changes to Figure 2 and 12.1

The 31 uses of the class name “ArtefactElementCitation” and the 10 uses of the class name “ArgumentElementCitation” are inconsistent with the 20 uses of the class name “ArtefactAssetCitation” and 7 uses of the class name “ArgumentAssetCitation”.

Align terminology to use '...AssetCitation(s)'

To be consistent across the SACM 2.0 metamodel the “ArtefactElementCitation” and “ArgumentElementCitation” uses should be changed to “ArtefactAssetCitation” and “ArgumentAssetCitation” respectively, the class “ArtefactElementCitation” in figure 6 should be changed to “ArtefactAssetCitation”, and the 2 uses of the term “citedElement” should be changed to “citedAsset”.

See the pdf “terms Element and Asset are inconsistently used in citation-related classes.pdf” for markup of proposed changes.

Section 2 doesn’t make it clear that AssuranceCase compliance point is mandatory. Also, some text in section 2.4 should be moved to precede all the compliance point descriptions.

Make it clear that the Assurance Case compliance point is mandatory.

The sentence, “This compliance point is mandatory.” should be added at the beginning of the first paragraph of Section 2.4. The second paragraph should be moved to immediate follow the bullet point list of compliance points at the beginning of Section 2.

See the pdf “AssuranceCase compliance point is mandatory.pdf” for markup of proposed changes.

In the second paragraph of Section 2.1 there is currently the text, “The ‘ArtefactElementCitation’ class shall not be used.” This is incorrect. The ArtefactElementCitation class is still necessary for the use of Argumentation compliance point.

Correct erroneous text about 'ArtefactElementCitation’ class

Omit the sentence. “The ‘ArtefactElementCitation’ class shall not be used.”

See the pdf “Incorrect description of the Argumentation compliance point.pdf” for markup of proposed changes.

Because all the significant classes of the argumentation and artefact package inherit from ModelElement, and ModelElement must use the Description class to provide content (e.g. the text of a Claim), and Descriptions must (given the current multiplicity) contain an Expression object, both argumentation and artefact packages must use the terminology package.

Fix model to allow Terminology Package to be optional as intended

The multiplicity from TaggedValue to Expression and UtilityElement to Expression must be changed from ‘1’ to ‘0..1’ to allow this to be optional. In addition, a new attribute called “sExpression: String” (referring to ‘simple expression’) should be added to UtilityElement, and an additional attribute called “sKey: String” (referring to ‘simple Key’) should be added to TaggedValue.

In Section 8.4 (The description of UtilityElement) the following text needs to be added:

“Attributes
sExpression: String – the text that describes the value of the UtilityElement”

and

“Constraints
If an Expression class is associated (through the expression association) with UtilityElement then sExpression should be null”

In Section 8.8 (The description of TaggedValue) the following text needs to be added to the current ‘Attributes’ section:

“sKey: Expression – the text that describes the key of the tagged value”

and the following text to the existing ‘Constraints’ section:

“If an Expression class is associated (through the key association) with TaggedValue then sKey should be null”

See the pdf “The SACM 2.0 meta-model requires implementation of the Terminology Package.pdf” for markup of proposed changes to figures and “Terminology Package Implementation-8.4 and 8.8.pdf” for text changes.

Of the three compliance points, one is referred to with the word “Model” while the other two are not. All three should consistently use this word in describing the compliance points. Additionally, two times “model” is used instead of “Model”.

Change section 2 to be consistent in use of term "model"

In the bulleted list in section 2.1; the title of section 2.2; the first sentence of the first and second paragraphs of section 2.2; section 2.3; the title of section 2.4; and the first sentence of the first paragraph replace the text “Argumentation” and “Assurance Case” with “Argumentation Model” and “Assurance Case Model” respectively and replace “Artefact model” with “Artefact Model”.

See pdf “Use of word Model in Chapter 2.pdf” for markup of proposed changes.