1. OMG Mailing List
  2. Structured Assurance Case Metamodel (SACM) 1.2 Revision Task Force

Open Issues

  • Issues not resolved
  • Name: sacm-rtf
  • Issues Count: 34

Issues Summary

Key Issue Reported Fixed Disposition Status
SACM2-31 Reference to non-existent class SACM 1.1 open
SACM2-25 Uncertainty characteristic for claims SAEM 1.0b1 open
SACM2-24 Identifying nature of element contents SAEM 1.0b1 open
SACM2-27 EvidenceProperty inherit from Property SAEM 1.0b1 open
SACM2-32 Superclass in text is inconsistent with diagram SACM 1.1 open
SACM2-6 No method of handling confidence in the ARM SACM 1.0 open
SACM2-8 Issue: No approach to allowing Structured Expression of Claims within ARM SACM 1.0 open
SACM2-3 Page73 ,section 13.2, figure21 SACM 1.0 open
SACM2-4 Evidence evaluation attributes in SAEM overlap in purpose - e.g. insufficient distinction between Strength and ... SACM 1.0 open
SACM2-2 Integration Issue: Inconsistent approaches to handling counter argument and evidence SACM 1.0 open
SACM2-9 Incorporate 11.5.3 Contributes (abstract) (p64) in a coherent way into merged SACM metamodel SACM 1.0 open
SACM2-7 fundamental difference in modelling style of each metamodel SACM 1.0 open
SACM2-33 Apparently spurious associations on class diagram SACM 1.1 open
SACM2-10 Integration Issue: Inconsistent terminology SACM 1.0 open
SACM2-1 Add missing definitions to SBVR Vocabulary in Annex A SACM 1.0b1 open
SACM2-22 Events should be able to be Associated with all Kinds of ModelElements ARM 1.0b1 open
SACM2-21 Making Role Binding and SBVR more generally available ARM 1.0b1 open
SACM2-20 Properties of Model Elements must be Distinguished from Properties of what they Represent ARM 1.0b1 open
SACM2-16 Property Inherence Hierarchy ARM 1.0b1 open
SACM2-13 Incorporate 11.2.2 SupportLevel (enumeration) (p52) in a coherent way into merged SACM metamodel SACM 1.0 open
SACM2-15 combined standard should include a vocabulary for talking about standards of proof SACM 1.0 open
SACM2-14 Integration Issue: Inconsistency in level of prescription in the models SACM 1.0 open
SACM2-11 There is no support for patterning, which is found to be useful current practice. SACM 1.0 open
SACM2-5 prefixes in the SAEM 'Evidence.... SACM 1.0 open
SACM2-12 We are missing an SBVR vocabulary for ARM SACM 1.0 open
SACM2-28 Scope of availability of change management information SAEM 1.0b1 open
SACM2-19 Different Meanings of Different Variants/Versions of a Model Elements Need to be Labeled, e.g. for Claims ARM 1.0b1 open
SACM2-17 Assurance Cases under development or Incomplete ARM 1.0b1 open
SACM2-18 Justification of Methods of Reasoning ARM 1.0b1 open
SACM2-29 SBVR should be available in SACM for use wherever this would make sense SAEM 1.0b1 open
SACM2-23 Properties as Assertions ARM 1.0b1 open
SACM2-26 Ownership needs improved representation SAEM 1.0b1 open
SACM2-81 Typo in reference to ISO/IEC 15026 SACM 1.1 open
SACM2-30 Inconsistent naming of class SACM 1.1 open

Issues Descriptions

Reference to non-existent class

  • Key: SACM2-31
  • Legacy Issue Number: 19869
  • Status: open  
  • Source: gmail.com ( Timothy Rowe)
  • Summary:

    The text states that the ArgumentReasoning class has a reference structure:Argument[0..1]

    There is no Argument class defined. This should presumably be structure:Argumentation[0..1], as shown in Figure 9.1

  • Reported: SACM 1.1 — Mon, 14 Dec 2015 05:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

Uncertainty characteristic for claims

  • Key: SACM2-25
  • Legacy Issue Number: 16287
  • Status: open  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    From the viewpoint of compatibility with ISO/IEC 15026, the most important issue is that SACM contain an "Uncertainty" characteristic or attribute, a key aspect of 15026-2, in order to facilitate use of SACM with ISO/IEC 15026 conformant assurance cases. These would be useful throughout SACM as attributes of assertions or claims (not relations).

    Current usage means a need exists for several data type options ­ not necessarily mutually exclusive.

    Data Types
    • Probability true: 0-1.00
    • Type I error: 0-1.00
    • Type 2 error: 0-1.00
    • Enumeration: None, low, medium, large, unknown
    • Standard deviation: real number
    One might also want to include a data type with customizable meaning (values: 1-100) that would parallel the data type for “Strength” in present draft if this is retained.

    This attribute element is associated with claims (assertions) and not with relations. Current SAEM draft defines characteristics ­ such as “Strength,” and “Confidence” ­ of evidence relations between an EvidenceItem (e.g. exhibit) and a DominAssertion. These relate to uncertainty but are associated with a relation and not with a DomainAssertion (claim). Note that the draft of SAEM states these are one-to-one relations unlike the many-to-one inferential relations in ARM.

  • Reported: SAEM 1.0b1 — Fri, 27 May 2011 04:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

Identifying nature of element contents

  • Key: SACM2-24
  • Legacy Issue Number: 16883
  • Status: open  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    2. What is needed to be known by tool or human is information required to establish the meaning of its content (interpret it) for this the notation/means used to express contents needs to be identified. An associated property could do this ­ and with more power/flexibility as any notation could be identified. Among other things, one should not presume that multiple tool vendors would never chose to support a (mathematically) formal notation other than SBVR. The use of different element types to identify nature of contents as “informal” or “structured” would be overkill. Rather, rename/combine “Consistency,” “ IsExpressed InLanguage”or other element to NotationUsed and provide appropriate attributes.

  • Reported: SAEM 1.0b1 — Fri, 9 Dec 2011 05:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

EvidenceProperty inherit from Property

  • Key: SACM2-27
  • Legacy Issue Number: 16882
  • Status: open  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    With integration EvidenceProperty inherit from Property as should all properties - directly or indirectly.

  • Reported: SAEM 1.0b1 — Fri, 9 Dec 2011 05:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

Superclass in text is inconsistent with diagram

  • Key: SACM2-32
  • Legacy Issue Number: 19867
  • Status: open  
  • Source: gmail.com ( Timothy Rowe)
  • Summary:

    The superclass of ArgumentElement is shown as ModelElement in the text but as ArgumentationElement in figure 9.1 on page 27.

  • Reported: SACM 1.1 — Mon, 14 Dec 2015 05:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

No method of handling confidence in the ARM

  • Key: SACM2-6
  • Legacy Issue Number: 16843
  • Status: open  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    No method of handling confidence in the ARM

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

Issue: No approach to allowing Structured Expression of Claims within ARM

  • Key: SACM2-8
  • Legacy Issue Number: 16844
  • Status: open  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Issue: No approach to allowing Structured Expression of Claims within ARM

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

Page73 ,section 13.2, figure21

  • Key: SACM2-3
  • Legacy Issue Number: 16712
  • Status: open  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Some of the concepts being captured in the model here overlap quite strongly with those of
    Configuration Management, and would probably best left to standards in that domain rather
    than creating a conceptual overlap here.

  • Reported: SACM 1.0 — Fri, 18 Nov 2011 05:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

Evidence evaluation attributes in SAEM overlap in purpose - e.g. insufficient distinction between Strength and ...

  • Key: SACM2-4
  • Legacy Issue Number: 16854
  • Status: open  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Evidence evaluation attributes in SAEM overlap in purpose - e.g. insufficient distinction between Strength and ...

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

Integration Issue: Inconsistent approaches to handling counter argument and evidence

  • Key: SACM2-2
  • Legacy Issue Number: 16842
  • Status: open  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Integration Issue: Inconsistent approaches to handling counter argument and evidence. Both standards have evaluation mechanisms (e.g. refuting, rebutting mechanisms)

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

Incorporate 11.5.3 Contributes (abstract) (p64) in a coherent way into merged SACM metamodel

  • Key: SACM2-9
  • Legacy Issue Number: 16807
  • Status: open  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.5.3 Contributes (abstract) (p64) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0 — Tue, 29 Nov 2011 05:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

fundamental difference in modelling style of each metamodel

  • Key: SACM2-7
  • Legacy Issue Number: 16850
  • Status: open  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    There is a fundamental difference in how modelling style of each metamodel. For example SAEM has a more "fact oriented" (nouns and verbs) approach which has a simpler MOF implementation. ARM has

    classes instead.

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

Apparently spurious associations on class diagram

  • Key: SACM2-33
  • Legacy Issue Number: 19870
  • Status: open  
  • Source: gmail.com ( Timothy Rowe)
  • Summary:

    Figure 9.1 shows associations between ArgumentReasoning and AssertedInference, and between ArgumentReasoning and AssertedChallenge, which are not described in the text. Because these can be captured by the association between ArgumentReasoning and AssertedRelationship, I assume they are spurious

  • Reported: SACM 1.1 — Mon, 14 Dec 2015 05:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

Integration Issue: Inconsistent terminology

  • Key: SACM2-10
  • Legacy Issue Number: 16837
  • Status: open  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Integration Issue: Inconsistent terminology

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

Add missing definitions to SBVR Vocabulary in Annex A

  • Key: SACM2-1
  • Legacy Issue Number: 17335
  • Status: open  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    The SBVR vocabulary for evidence in Annex A is missing several definitions.

  • Reported: SACM 1.0b1 — Tue, 24 Apr 2012 04:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

Events should be able to be Associated with all Kinds of ModelElements

  • Key: SACM2-22
  • Legacy Issue Number: 16510
  • Status: open  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    Not just exhibits have events that affect them or otherwise relate to them. This is also relavent to what the elements represent.

    An event might be associated with more than one element
    For example, one bug fix that simultaneously change several code exhibits/artifacts.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

Making Role Binding and SBVR more generally available

  • Key: SACM2-21
  • Legacy Issue Number: 16509
  • Status: open  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    SBVR should be available for use within element contents everywhere unless strong, explicitly recorded reason exists for excluding it.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

Properties of Model Elements must be Distinguished from Properties of what they Represent

  • Key: SACM2-20
  • Legacy Issue Number: 16506
  • Status: open  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    Obviously, properties that apply to Model Elements must be distinguishable from Properties of what they represent. Both these kinds of properties appear in SACM models. The issues titled “Property Inherence Hierarchy” states a way of doing this.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

Property Inherence Hierarchy

  • Key: SACM2-16
  • Legacy Issue Number: 16507
  • Status: open  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    A simple, natural and appropriate set of properties would have Property (abstract?) inheriting from Assertion (or less preferably ModelElement) and having ModelElementProperty, RepesentedObjectProperty, Event, and Timing inheriting from it (Property) and appropriately associated. Artifacts and DomainObjects would use RepesentedObjectProperty’s. The two classes of properties are needed to allow properties associated with a model element and those associated with what it represents to be distinguished. Likewise ModelElementEvent and RepesentedObjectEvent inherit from Event. What type of event timing an instance is relevant to will be clear from what it is associated with. CM events and properties for both model elements and what they represent could be treated within this approach.

    Alternately, a usable set of properties could have Property inheriting from ModelElement and having ModelElementProperty, ArtifactProperty, DomainObjectProperty, Event, and Timing inheriting from it and appropriately associated. The three classes of properties are needed to allow properties associated with a model element and what it represents to be distinguished. Likewise ModelElementEvent, ArtifactEvent, and DomainObjectEvent inherit from Event. What type of event timing is relevant to will be clear from what it is associated with. CM events and properties could be treated likewise.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

Incorporate 11.2.2 SupportLevel (enumeration) (p52) in a coherent way into merged SACM metamodel

  • Key: SACM2-13
  • Legacy Issue Number: 16781
  • Status: open  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.2.2 SupportLevel (enumeration) (p52) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0 — Tue, 29 Nov 2011 05:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

combined standard should include a vocabulary for talking about standards of proof

  • Key: SACM2-15
  • Legacy Issue Number: 16861
  • Status: open  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    combined standard should include a vocabulary for talking about standards of proof

  • Reported: SACM 1.0 — Thu, 1 Dec 2011 05:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

Integration Issue: Inconsistency in level of prescription in the models

  • Key: SACM2-14
  • Legacy Issue Number: 16841
  • Status: open  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Integration Issue: Inconsistency in level of prescription in the models (e.g. raised by Jeremy). E.g. arm does not prescribe what kinds of claims, instead SAEM has more presciption of the subtypes of

    claims.

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

There is no support for patterning, which is found to be useful current practice.

  • Key: SACM2-11
  • Legacy Issue Number: 16853
  • Status: open  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    There is no support for patterning, which is found to be useful current practice.

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

prefixes in the SAEM 'Evidence....

  • Key: SACM2-5
  • Legacy Issue Number: 16849
  • Status: open  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    The name 'Evidence' implies a certain association between some Information / some artefact and some claim. In ARM it was recognised that information can be used both to define context and as

    supporting evidence to an assertion. This suggests that many of the prefixes in the SAEM 'Evidence....' should be changed to allow them to more generally refer to Information (and specialise to Evidence if

    required)

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

We are missing an SBVR vocabulary for ARM

  • Key: SACM2-12
  • Legacy Issue Number: 16864
  • Status: open  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    We are missing an SBVR vocabulary for ARM (authors view - this is work someone else
    to do, maybe close/postpone)

  • Reported: SACM 1.0 — Thu, 1 Dec 2011 05:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

Scope of availability of change management information

  • Key: SACM2-28
  • Legacy Issue Number: 16281
  • Status: open  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    Timing or change management information needs to be able to be associated with anything as anything can change over time. This includes for example with Attributes (and any Properties). In addition, how to best handle changes and change information over time needs to be reviewed throughout SACM.

    The version and change management related information ­ although often kept in a CM system ­ needs to be exchangeable along with an assurance case. At least one exchange standard for CM information exists, TECHAMERICA EIA-836B: Configuration Management Data Exchange and Interoperability, publication date: Mar 1, 2010. It is reportedly both ANSI and DoD approved. (http://engineers.ihs.com/document/abstract/BMVKACAAAAAAAAAA) One option is for this to be appropriately included by reference.

    Versioning should be available for everything. Identification and “HasVersion” attribute should be associated with a near root element, or this availability should be achieved in some other fashion. The standard should not restrict its availability and smallness of possible granularity of elements it may be applied to.

  • Reported: SAEM 1.0b1 — Thu, 26 May 2011 04:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

Different Meanings of Different Variants/Versions of a Model Elements Need to be Labeled, e.g. for Claims

  • Key: SACM2-19
  • Legacy Issue Number: 16511
  • Status: open  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    Claims and other items can have versions that simultaneously exist but have different meanings. For example, what a Claim might represent includes:
    • Required values
    • Planned values to be achieved
    • Supported (established, justified) values
    Two or more of these can be relevant at the same time.
    A suggestion has been made that SBVR be used (within associated properties?) to make this distinction. This would require that SBVR be available for these contents. Use of a TaggedValue is another possibility. Regardless of what mechanism is used, some standardization should be included for the key meanings.

    Placing this distinction within the contents of claim true-false statement might be more awkward and not make it as readily handled by tools as having it reside in a property.

    In any case, what is standardized needs to have precise definitions or distinguishable among multiple definitions (or explicitly made usage/implementation dependent?) as subtle variations in meaning are possible. Note that for some assertions differences might be entirely in the value for confidence.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

Assurance Cases under development or Incomplete

  • Key: SACM2-17
  • Legacy Issue Number: 16289
  • Status: open  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    SACM standard must accommodate assurance cases under development as this is expected to be a common usage ­ transferring assurance cases among their developers or maintainers. This includes those incomplete.

    In addition to incompleteness, decisions may yet to be concerning option options including the type of certain relations ­ e.g. does an inference relation challenge or not. As the relative distinctions are not always known, particularly early in assurance cases construction, which currently abstract classes should be concrete classes should be reviewed and changed as required to accommodate this.

    Recording explicit options yet to be decided among (and optionally their effects) could be useful (and also relevant to patterns).

    More elements similar in name to the UnknownSubject might be included if required to meet this need.

  • Reported: ARM 1.0b1 — Fri, 27 May 2011 04:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

Justification of Methods of Reasoning

  • Key: SACM2-18
  • Legacy Issue Number: 16514
  • Status: open  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    How might and/or should the justification for an ArgumentReasoning element’s method(s) of argumentation be represented in SACM? Several options or possibilities exist. This justification might be a supplied by a Claim, a DescriptiveAssertion, or Assumption connected by an AssertedInference link or an AssertedConext link in turn potentionally supported by InformationElement, EvidenceElement, or Artifact. More generally justification for its method(s) of argumentation can be in the form of an assurance case. On the other hand might it be supplied by an AssertedContextLink to an Artifact or even simply a citation?

    What is the designers approach? Should these options be restricted or others used ­ particularly for the link between the ArgumentReasoning element and justification of its methods? Should some approaches be preferred?

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

SBVR should be available in SACM for use wherever this would make sense

  • Key: SACM2-29
  • Legacy Issue Number: 16313
  • Status: open  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    SBVR should be available in SACM for use wherever this would make sense. This includes in (ARM) claims and ReasoningElements and in SAEM many assertions particularly claims and possible rationales. Wherever narrative or prose, or mathematical expressions are allowed, why not also allow SBVR (and some places graphics or even other media also) unless strong reasons exist for doing otherwise?

  • Reported: SAEM 1.0b1 — Sun, 5 Jun 2011 04:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

Properties as Assertions

  • Key: SACM2-23
  • Legacy Issue Number: 16505
  • Status: open  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    The property elements of various kinds contain assertions concerning proper values for various properties (or attributes). Should they not therefore inherit from Assertion? This includes tagged values unless these are used to tag kinds of “annotations” instead of using general Annotation elements.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

Ownership needs improved representation

  • Key: SACM2-26
  • Legacy Issue Number: 16310
  • Status: open  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    The following aspects need to be accommodated:
    Owning, creating, and approving can be done concurrently by multiple entities and different (sets of) entities over time.

    Ownership can be divided unequally among owners and fractions could need to be recorded.

    Ownership can have aspects, for example IP rights versus physical object ­ I own the book, but not its copyright.

  • Reported: SAEM 1.0b1 — Sun, 5 Jun 2011 04:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

Typo in reference to ISO/IEC 15026

  • Key: SACM2-81
  • Status: open  
  • Source: Luxembourg Institute of Science and Technology ( Eric Grandry)
  • Summary:

    In Semantics sub-section, the text refers to ISO/IEC 15026, but it is written:
    "An AssuranceCase element represents assurance cases as defined in ISO/IEC 15206."
    It should be written:
    "An AssuranceCase element represents assurance cases as defined in ISO/IEC 15026."

  • Reported: SACM 1.1 — Wed, 28 Dec 2016 15:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT

Inconsistent naming of class

  • Key: SACM2-30
  • Legacy Issue Number: 19868
  • Status: open  
  • Source: gmail.com ( Timothy Rowe)
  • Summary:

    The class is described as ArgumentElementCitation in the section title, but CitationElement in the body text. For consistency with InformationCitationElement, it is probably supposed to be ArgumentCitationElement

  • Reported: SACM 1.1 — Mon, 14 Dec 2015 05:00 GMT
  • Updated: Thu, 6 Apr 2017 13:57 GMT