The text does not explain all of the OCL or what counter assertions mean.

The modifications from the first two ballots and the previous issues in this ballot may have caused changes or complexities in the text that can be simplified.

SACM 2.3 only defined ownership for packages and not for other elements

The new Foundation concepts of comments, constraints, named values, group, and dependencies were externalized and need to be re-integrated into the argument, terminology, and artifact package domains Additionally, the package structures in SACM 2.3 are too loose and need to be better aligned with intended use.

Model should align with MOF to support use by SysML and UML audiences. Also ExpressionElement Attributes need to be aligned with the change adding MultiLangString as well as fixing the relationship between Category and TerminologyAsset. Finally, the arrow direction in the association between ArgumentReasoning and AssertedRelationship needs to be reversed and need to change the type for the attribute value of Argument Reasoning.

Document text and section numbers were not always changed as diagrams changed over the previous ballots and sometimes text was changed but not reflected in diagrams.

Property is no longer needed since any ModelElement can have a NamedValue.

Names are not distinguishable on directed relationships.

Arrow is on the wrong end of the association between NamedValue and ModelElement and generalization association from SACMModel to ModelElement is missing in the diagram but defined in the text.

metaClaim was removed from the text in a previous issue resolution but not from the diagram.

Asserted Relationships need precise targets and sources. The source and target of AssertedRelationships were either not defined or defined in OCL instead of being restricted in the Metamodel. Also, mislabeled (in text) the superclass for AssertedRelationships as Foundation::AssertedRelationship instead of Foundation::DirectedRelationship – is correct in diagram.

Format for IRI in Base is not defined

There is no construct to define what is in a SACM model or pattern.

Date in Artifact section is not defined, nor are the mechanisms to reference to internal portions of external documents.

Association between ExpressionElement and Category, Claim and MetaClaim, and ArgumentReasoning and ArgumentPackage are shown but no longer needed and the association between ArgumentReasoning and AssertedRelationship is in the wrong direction and missing end-point details.

The name and the content of ExpressionElement, ArgumentReasoning, and Claim can be the same or the content can be different, but the SACM 2.3 doesn’t support this.

SACM 2.3 uses unique foundation elements instead of those from UML / Kermal modeling languages and need to fix issue of ArtifactAssetRelationship mislabeled as ArtifactAssertedRelationship in diagram versus specification text.

Currently SACM 2.3 allows too wide of nesting of different types of packages.

Use of current gid is overly restrictive and not aligned with approaches used in UML and KerML.

Can not mix and match the domain elements within the group with the current per domain group approach.

AssertedArtifactContext and AssertedArtifactSupport are redundant and their function can be implemented with the other things in the SACM language.

Artifacts need to be able to be used in Arguments directly as well as ArtifactReference.

The Base Classes have names and scopes that are at odds with current standard modeling languages.

AssertionDeclaration has a number of orthogonal ideas that should not be in the enumeration (namely defeated and asCited), and the name should follow modeling practice of ending in”Kind” to indicate it is a set of enumerations.

The metamodel should follow the open-closed principle to avoid double maintenance when changes are made because the current model requires changes in two places, additionally there is no need for the top-level interface package and but there is a need for a general binding package in the new packaging scheme, finally renaming interface and binging packages to align with normal package naming conventions.

Referencing external elements from the model are dealt with in inconsistent ways.

Names used in the metamodel conflict with standard modeling usage.

ArgumentationElement/ArgumentationElements/argumentationElement has the right naming pattern (i.e., consistent with the other Elements in the model) in 11.2 (ArgumentElements) but does not use that naming pattern in the rest of the model.

With ArtifactElement as the Base for the other Domains, it allowed anything to be connected to anything which was not the original intent.

Terminology package is not tied to everything else in the model.

Need to standardize concepts in SACM to be able to embed SACM in other languages and to be able to create a profile in UML based on the metamodel.

right now the Name of a model element can not be a multi-string... which it should be

There is no reason to have both LangString and ExpressionLangString, given the constraint on ExpressionLangString that the expression and the content cannot both have values. If you insist on having both, have a common base class that includes only the 'lang' attribute - then LangString can have the content field and ExpressionLangString can have the 'expression' field.

There is no reason to have both LangString and ExpressionLangString, given the constraint on ExpressionLangString that the expression and the content cannot both have values. If you insist on having both, have a common base class that includes only the 'lang' attribute - then LangString can have the content field and ExpressionLangString can have the 'expression' field.

Generally: This document is replete with grammatical errors. Has someone run a grammar checker on it?

Specifically:
In addition, the 'Attributes' section for 'ExpressionLangString' states:
"expression:Terminology::ExpressionElement[1] (composition) – a reference"

The field is either a reference or a composition - but not both. Pick one.