${taskforce.name} Avatar
  1. OMG Task Force

SOPES IEDM FTF — All Issues

  • Key: SOPES
  • Issues Count: 41
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
SOPES-41 Missing Annex SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-40 Navigation Constraint modelling SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-39 Annex A - The Navigation Constraint example in diagram A.8 could benefit from further explanation SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-38 Annex D - xsd issue SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-37 Related in nature to SOPES-00001 ie missing oclConstructionSequence elements in the following subsections- SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-36 Missing tiles on Figure 5.2 SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-35 Missing tiles on Figure 5.3 SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-30 You should avoid using identifier names with hyphens SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-29 Annex A - If you do use the class name, you must use lowercase its first letter SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-28 Annex A - You should navigate using the association role name (identifier), not the class name SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-27 If the invariant is on the association then you need to navigate through class InformationSemantic_1 SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-26 Annex A - “Wrapper::Wrapper_1” isn’t proper OCL (or UML). SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-25 Annex A - The syntax of the navigation constraint isn’t OCL SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-24 Annex A SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-23 Page 38 – section 7.5.1 - editorial SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-22 Page 38 – section 7.5.1 – SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-33 Navigation constraint names SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-32 Annex C - logic behind the order in which OCL elements appear SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-31 Clarify ConstructionSequence SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-2 Optimized and Verbose having been submitted incorrectly SOPES 1.0b1 open
SOPES-1 Missing titles on Figure 5.3 SOPES 1.0b1 open
SOPES-7 Page xv – Para 4: SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-6 …Verbose XSD\Line_Item.xsd SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-5 Elipse_Surface SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-4 Plan_Order_Item SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-3 Replace normative spelling of "materiel" to US spelling "material" SOPES 1.0 open
SOPES-21 Page 35, Section 7.2.1 – para 1 SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-20 Section 5.13.1 SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-19 Page 25 – Section 5.13 – Para 1 SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-18 Page 24 – Section 5.13 – Para 1: SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-17 Page 23 – Section 5.13 – bullets 2, 3, 4: SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-16 Page 16 – Section 5.8.3 – para 4: SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-15 Page 16 – Section 5.8.2 – bullet 6: SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-14 Page 14 – Section 5.6.4 Para 1: SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-13 Page 13 – Section 5.6.3 Para 2: SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-12 Page 8 – Section 5.2 Para 2: editorial SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-11 Page 8 – Section 5.2 Para 2: wording change SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-10 Page 8 – Section 5.2 Para 1: SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-9 Section 1.5.1 para 1: SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-8 Page xv – Para 4: wording change SOPES 1.0b1 SOPES 1.0 Resolved closed
SOPES-34 Annex A - A navigation constraint appears in a note SOPES 1.0b1 SOPES 1.0 Resolved closed

Issues Descriptions

Missing Annex

  • Key: SOPES-41
  • Legacy Issue Number: 15252
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    Annex F
    Missing XMI for the Models. Add Annex F and Zip file containing the XMI version of the model

  • Reported: SOPES 1.0b1 — Mon, 10 May 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    Add Annex F and Zip file containing the XMI version of the model

  • Updated: Sat, 7 Mar 2015 09:11 GMT

Navigation Constraint modelling

  • Key: SOPES-40
  • Legacy Issue Number: 15246
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Michael Abramson)
  • Summary:

    Annex A - Navigation Constraint modelling should include disallowed cardinality values for the subtended constraint evaluation Wrapper as well as an explanation of the acceptable uses of NULL as it concerns the Wrapper Attribute‘s value.

  • Reported: SOPES 1.0b1 — Wed, 5 May 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    These explanations are to be added to section A.2.9.2 Navigation Constraints

    The Wrapper containing the evaluation attribute (e.g., Point) on a navigation constraint must have a multiplicity of 1 (/1..1) within the data pattern. In reference to Figure A.12 and Table A.3 both Point and Location are constraint evaluation Wrapper instances and thus are required to have a cardinality of 1..1.

    It should be noted that the Wrapper Attribute which holds the value must comply with the model's domain constraints and as such it is possible that the value held by the Wrapper Attribute could properly be expressed as NULL.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Annex A - The Navigation Constraint example in diagram A.8 could benefit from further explanation

  • Key: SOPES-39
  • Legacy Issue Number: 15245
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Michael Abramson)
  • Summary:

    The Navigation Constraint example in diagram A.8 could benefit from further explanation

  • Reported: SOPES 1.0b1 — Wed, 5 May 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    The clarification of the example Navigation Constraint in Figure A.8 is to be added in section A.1.7.6 . Though this concern was not specifically mentioned in discussion of issue SOPES-00026, it is included for clarification as SOPES-00041.

    Clarifications:

    For all instances of the constrained navigation the initial element 'self' is the enclosing Transactional,
    and in the case of the example from diagram A.8 self refers to ‘InformationTransactional_1’.

    The second element of the constraint is the Wrapper instance which must be a directly subtended element of the enclosing Transactional,
    and in this case the Wrapper instance is 'Wrapper_1'.

    The third element is the named Wrapper Attribute featured on the specified Wrapper,
    and in this case this element is 'catCode'.

    The final element is evaluated against the constraint, and in this case the value is 'domainValue'

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Annex D - xsd issue

  • Key: SOPES-38
  • Legacy Issue Number: 15244
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Optimized xsd; reported as a collection of Wrapper elements with the appropriate cardinality.
    Verbose xsd; reported as a hierarchical grouping of Artifacts based on the uml model ie as a combination of Transactionals and Wrapper elements

  • Reported: SOPES 1.0b1 — Wed, 5 May 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    Original submission mislabelled the folders containing the two sets of schemas.

    Reverse the Titles of the two groupings of XSDs.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Related in nature to SOPES-00001 ie missing oclConstructionSequence elements in the following subsections-

  • Key: SOPES-37
  • Legacy Issue Number: 15243
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Michael Abramson)
  • Summary:

    Related in nature to SOPES-00001 ie missing oclConstructionSequence elements in the following subsections - Annex C

    C.1.37 Associated_Target_Detail

    C.2.3 EngineeringCapability_Type

    C.2.4 FireCapability_Type

    C.2.5 StorageCapability_Type

    C.2.6 TransmissionCapability_Type

    C.3.6 Context_Item

    C.4.1 ApproachDirection_Item

    C.5.22 Runway_Item

    C.9.8 Principal_Equipment_Type

    C.12.5 Object_Type_Establishment

  • Reported: SOPES 1.0b1 — Wed, 5 May 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    These oclConstructionSequences were missed during the generation of the document and need to be added to the relevant subsections in Annex C

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Missing tiles on Figure 5.2

  • Key: SOPES-36
  • Legacy Issue Number: 15242
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Michael Abramson)
  • Summary:

    page 18 - Missing tiles on Figure 5.2

  • Reported: SOPES 1.0b1 — Wed, 5 May 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    Add: “Figure 5.2 - Using JC3IEDM Meta Model”

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Missing tiles on Figure 5.3

  • Key: SOPES-35
  • Legacy Issue Number: 15241
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Michael Abramson)
  • Summary:

    page 18 - Missing tiles on Figure 5.3

  • Reported: SOPES 1.0b1 — Wed, 5 May 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    Add: “Figure 5.3 - Development of Transactional Models”

  • Updated: Fri, 6 Mar 2015 23:15 GMT

You should avoid using identifier names with hyphens

  • Key: SOPES-30
  • Legacy Issue Number: 15201
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    You should avoid using identifier names with hyphens. Parsing them will be impractical. I know we did this in the JC3IEDM PIM at one time. It wasn’t a good idea then, either.

  • Reported: SOPES 1.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    Changing Case is problematic as we are using the MIP JC3IEDM logical model naming conventions. As this is a set of data patterns for the JC3IEDM we need to remain consistent.

    No change to the SOPES IEDM specification required

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Annex A - If you do use the class name, you must use lowercase its first letter

  • Key: SOPES-29
  • Legacy Issue Number: 15200
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    If you do use the class name, you must use lowercase its first letter

  • Reported: SOPES 1.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    Changing Case is problematic as we are using the MIP JC3IEDM logical model naming conventions. As this is a set of data patterns for the JC3IEDM we need to remain consistent.

    No change to the specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Annex A - You should navigate using the association role name (identifier), not the class name

  • Key: SOPES-28
  • Legacy Issue Number: 15199
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    You should navigate using the association role name (identifier), not the class name

  • Reported: SOPES 1.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    Identifier is a tagged value identifying the source of the construction keys it is not a role name. We use the name field on the arc to illustrate the isIdentifier=True condition of the tagged value.

    No change to the specification

  • Updated: Fri, 6 Mar 2015 20:58 GMT

If the invariant is on the association then you need to navigate through class InformationSemantic_1

  • Key: SOPES-27
  • Legacy Issue Number: 15198
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Annex A
    If the invariant is on the association then you need to navigate through class InformationSemantic_1.

  • Reported: SOPES 1.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    The diagram reflects deprecated approach the definition of the data patterns and needs to be updated. Rework Figure A.8.

    Correction: inv self.securityLevel = “unclassified”

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Annex A - “Wrapper::Wrapper_1” isn’t proper OCL (or UML).

  • Key: SOPES-26
  • Legacy Issue Number: 15197
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    “Wrapper::Wrapper_1” isn’t proper OCL (or UML). You don’t include the stereotype name as part of navigation. Just use the class name

  • Reported: SOPES 1.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    The diagram reflects deprecated approach the definition of the data patterns and needs to be updated. Rework Figure A.8.

    Correction: inv self.Wrapper_1.catCode = “domainValue”; where domainValue is a legal value in the catCode domain.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Annex A - The syntax of the navigation constraint isn’t OCL

  • Key: SOPES-25
  • Legacy Issue Number: 15196
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    The syntax of the navigation constraint isn’t OCL. For one thing, it uses the “==” operator. For another, it has an “if” without an “else”. I can understand what’s being achieved (sort of – see below) but I don’t know why this syntax was chosen

  • Reported: SOPES 1.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    The diagram reflects deprecated approach the definition of the data patterns and needs to be updated. Rework Figure A.8.

    Correction: inv self.Wrapper_1.catCode = “domainValue”; where domainValue is a legal value in the catCode domain.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Annex A

  • Key: SOPES-24
  • Legacy Issue Number: 15194
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Figure A.8 depicts some OCL, and contains several things I find unusual or unclear:

    OCL string literals use single quotes, not double quotes.
    IDA

  • Reported: SOPES 1.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    Rework the elements in the diagrams in the Annex to reflect the corrections needed in the OCL.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 38 – section 7.5.1 - editorial

  • Key: SOPES-23
  • Legacy Issue Number: 15193
  • Status: closed  
  • Source: ECC ( Erik Chaum)
  • Summary:

    The following lines should be bullets:

    “The XML DTD Production Rules for producing XML Document Type Definitions (DTDs) for XMI encoded metadata. XMI DTDs serve as syntax specifications for XMI documents, and allow generic XML tools to be used to compose and validate XMI documents.

    The XML Document Production Rules for encoding metadata into an XML compatible format. The production rules can be applied in reverse to decode XMI documents and reconstruct the metadata.
    Requested change from the US Delegation to MIP
    E. Chaum

    Page 52 – Section 9.1 – Bullet 4

    This is the finial version and exemplar semantics are provides in section 11
    Requested change from the US Delegation to MIP
    E. Chaum

    Page 57 – Section 9.5.1 – Bullet 1

    “JC3-V3-1b_entity” with “JC3-V3-1c_entity”

  • Reported: SOPES 1.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    Accept editorial change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 38 – section 7.5.1 –

  • Key: SOPES-22
  • Legacy Issue Number: 15192
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    XML schema is used in the Annexes – not DTDs

  • Reported: SOPES 1.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    Replace DTD references with XML Schema. Old reference based on the length of the specification effort.
    Wording changes to sections 7.5.1 and 7.5.2.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Navigation constraint names

  • Key: SOPES-33
  • Legacy Issue Number: 15204
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Looking through the first few tables, it seems as if the navigation constraint names all end with a “}”.

  • Reported: SOPES 1.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    see dtc/2010-05-06

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Annex C - logic behind the order in which OCL elements appear

  • Key: SOPES-32
  • Legacy Issue Number: 15203
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    In Annex C, I don’t follow the logic behind the order in which OCL elements appear. For Action_Context_Status (p. c-11), you have:

    self.action-id = self.Action_Context.ActionContext.action-id and …
    Context ActionContextStatus, inv ActionContextStatus_Action_Context:

    A few points here. First, there shouldn’t be a comma before “inv”. Second, it looks as if the invariant expression is the thing on the first line, instead of following the second line. Why?

  • Reported: SOPES 1.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    see dtc/2010-05-06

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify ConstructionSequence

  • Key: SOPES-31
  • Legacy Issue Number: 15202
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    I’m not clear what the ConstructionSequence is. It’s first mentioned on p. 273 but is not defined. It’s not valid OCL, either, appearing as it does outside of an expression or function. If you are trying to specify an order of operations, I suggest using OCL’s messaging constructs

  • Reported: SOPES 1.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    The use of the term ConstructionSequence need to described in Annex A, section A.2.9 Build Plan

    The oclConstructionSequence was included as guidance to a developer on the order in which the classes on the diagram are navigates during information aggregation. The sequences are derived from the models in section 10.

    An explanation that the oclConstructionSequence is not intended to be executable and is therefore included only for its informational value will be added as a preamble to Annex C.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Optimized and Verbose having been submitted incorrectly

  • Key: SOPES-2
  • Legacy Issue Number: 15206
  • Status: open  
  • Source: Advanced Systems Management Group Ltd. ( Simon Brameld)
  • Summary:

    Optimized xsd; reported as a collection of Wrapper elements with the appropriate cardinality.
    Verbose xsd; reported as a hierarchical grouping of Artifacts based on the uml model ie as a combination of Transactionals and Wrapper elements

  • Reported: SOPES 1.0b1 — Fri, 16 Apr 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing titles on Figure 5.3

  • Key: SOPES-1
  • Legacy Issue Number: 15205
  • Status: open  
  • Source: Advanced Systems Management Group Ltd. ( Michael Abramson)
  • Summary:

    Missing titles on Figure 5.3 - Add: "Development of Transactional Models"

  • Reported: SOPES 1.0b1 — Fri, 16 Apr 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page xv – Para 4:

  • Key: SOPES-7
  • Legacy Issue Number: 15177
  • Status: closed  
  • Source: ECC ( Erik Chaum)
  • Summary:

    Wording Change:

    ... that the ECM Community see during ECM operations.

    With

    ... that the ECM Community may see during ECM operations with military partners.

  • Reported: SOPES 1.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    Accept requested wording change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

…Verbose XSD\Line_Item.xsd

  • Key: SOPES-6
  • Legacy Issue Number: 14839
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This schema doesn't reflect the right element's cardinality w.r.t their corresponding transactional. For instance, a line is made of a minimum of 2 points. Accordingly, the verbose schema should indicate a minimum of 2 LinePoint, 2 Point and 3 Location. 3 Location because Line "is a" Location.

  • Reported: SOPES 1.0b1 — Wed, 23 Dec 2009 05:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    Schema generator incorrectly some of subtended multiplicities. These need to be updated in the XSDs. This issue only affects the Verbose XSDs.

    Candidate_Target_Detail_Assoc.xsd
    Line # 8 change to: minOccurs="2" maxOccurs="2"
    Line #10 change to: minOccurs="2" maxOccurs="2"
    Line #11 change to: maxOccurs="2"
    Line #12 change to: maxOccurs="2"
    Line #13 change to: minOccurs="2" maxOccurs="2"
    Line #14 change to: minOccurs="2" maxOccurs="2"
    Line #16 change to: maxOccurs="2"
    Line #17 change to: maxOccurs="2"
    Line #18 change to: maxOccurs="2"

    Action_Objective_Item.xsd
    Line #10 change to: maxOccurs="unbounded"
    Line #12 change to: maxOccurs="unbounded"
    Line #15 change to: maxOccurs="unbounded"
    Line #16 change to: maxOccurs="unbounded"
    Line #17 changeto maxOccurs="unbounded"
    Line #18 change to: maxOccurs="unbounded"
    Line #19 change to: maxOccurs="unbounded"
    Line #20 change to: maxOccurs="unbounded"
    Candidate_Target_Detail_Authorisation.xsd
    Line #10 change to: maxOccurs="2"
    Line #11 change to: maxOccurs="2"
    Line #16 change to: maxOccurs="2"
    Line # 17 change to: maxOccurs="2"

    Candidate_Target_List.xsd
    Line #9 change to: maxOccurs="2"
    Line #10 change to: maxOccurs="2"
    Line #14 change to: maxOccurs="unbounded"
    Line #16 change to: maxOccurs="2"
    Line #17 change to: maxOccurs="unbounded"
    Line #18 change to:" maxOccurs="unbounded"
    Line #19 change to: maxOccurs="2"
    Line #20 change to: maxOccurs="unbounded"
    Candidate_Target_List_Assoc.xsd
    Line #8 change to: minOccurs="2" maxOccurs="2"
    Line #10 change to: maxOccurs="unbounded"
    Line #11 change to: maxOccurs="4"
    Line #12 change to: minOccurs="2" maxOccurs="4"
    Line # 13 change to: minOccurs="2" maxOccurs="4"
    Line #15 change to: maxOccurs="unbounded"
    Line #16 change to: maxOccurs="2"
    Line # 17 change to: maxOccurs="4"
    Line #18 change to: maxOccurs="unbounded"
    Line #19 change to: maxOccurs="unbounded"
    Line #20 change to: maxOccurs="4"
    Line #21 change to: maxOccurs="unbounded"
    Context_Context_Assoc_Status.xsd
    Line #8 change to: minOccurs="2" maxOccurs="2"
    Line #14 change to: maxOccurs="2"
    Context_Element.xsd
    Line #10 change to: maxOccurs="unbounded"
    Line #11 change to: maxOccurs="unbounded"
    Line #12 change to: maxOccurs="unbounded"
    Line #17 change to: maxOccurs="unbounded"
    Line # 18 change to: maxOccurs="unbounded"
    Context_Specification.xsd
    Line #9 change to: maxOccurs="unbounded"
    Line #10 change to: maxOccurs="unbounded"
    Line #11 change to: maxOccurs="unbounded"
    Line #12 change to: maxOccurs="unbounded"
    Line #13 change to: maxOccurs="unbounded"
    Line #17 change to: maxOccurs="unbounded"
    Line # 18 change to: maxOccurs="unbounded"
    Line #19 change to: maxOccurs="unbounded"
    Line #20 change to: maxOccurs="unbounded"
    Line #21 change to: minOccurs="1" maxOccurs="unbounded"
    Ellipse_Surface.xsd
    Line #8 add: minOccurs="1" maxOccurs="1"
    Line #9 change to: minOccurs="4" maxOccurs="4"
    Line #10 change to: minOccurs="3" maxOccurs="3"
    Line #12 change to: maxOccurs="3"
    Line #13 change to: maxOccurs="3"
    Line #14 change to: maxOccurs="3"
    Line #15 change to: maxOccurs="3"
    Line #16 change to: maxOccurs="3"
    Line #17 change to: maxOccurs="3"
    Line #18 change to: maxOccurs="3"
    Line #19 change to: maxOccurs="3"
    Line #20 change to: maxOccurs="3"
    Line #21 change to: maxOccurs="3"
    Line #22 change to: maxOccurs="3"
    Line #2 3 change to: maxOccurs="3"
    Line #24 change to: maxOccurs="3"
    Line #25 change to: maxOccurs="3"
    Line #26 change to: maxOccurs="3"
    Line #27 change to: maxOccurs="3"
    Line_Item.xsd
    Line #9 change to: minOccurs="2" maxOccurs="unbounded"
    Line #10 change to: minOccurs="3" maxOccurs="unbounded"
    Line #11 change to: minOccurs="2" maxOccurs="unbounded"
    Line #13 change to: maxOccurs="unbounded"
    Line #14 change to: maxOccurs="unbounded"
    Line #15 change to: maxOccurs="unbounded"
    Line #16 change to: maxOccurs="unbounded"
    Line #17 change to: maxOccurs="unbounded"
    Line #18 change to: maxOccurs="unbounded"
    Line #23 change to: maxOccurs="unbounded"
    Line #24 change to: maxOccurs="unbounded"
    Line #27 change to: maxOccurs="unbounded"
    Medical_Facility_Status_Composite.xsd
    Line #9 change to: maxOccurs="unbounded"
    Line #10 change to: maxOccurs="unbounded"
    Line #11 change to: maxOccurs="unbounded"
    Line #12 change to: maxOccurs="unbounded"
    Line #13 change to: maxOccurs="unbounded"
    Line #14 change to: maxOccurs="unbounded"
    Military_Obstacle.xsd
    Line #11 change to: maxOccurs="unbounded"
    Line #12 change to: " maxOccurs="unbounded"
    Network_Facility_Item.xsd
    Line #10 change to: maxOccurs="unbounded"
    Line #11 change to: maxOccurs="unbounded"
    Object_Item_Assoc_Status.xsd
    Line #8 change to: maxOccurs="3"
    Object_Type_Establishment_Detail.xsd
    Line #8 change to: maxOccurs="2"
    Line #9 change to: maxOccurs="2"
    OrbitArea_Surface.xsd
    Line #8 change to: minOccurs="2" maxOccurs="2"
    Line #10 change to: minOccurs="2" maxOccurs="8"
    Line #11 change to: maxOccurs="2"
    Line #12 change to: maxOccurs="2"
    Line #13 change to: maxOccurs="2"
    Line #14 change to: maxOccurs="2"
    Line #15 change to: maxOccurs="2"
    Line #17 change to: minOccurs="2" maxOccurs="2"
    Line #19 change to: maxOccurs="2"
    Line #20 change to: maxOccurs="2"
    Line #21 change to: maxOccurs="2"
    Line #22 change to: maxOccurs="2"
    Line #23 change to: maxOccurs="2"
    Line #24 change to: maxOccurs="2"
    Line #25 change to: maxOccurs="2"
    Line #26 change to: " maxOccurs="2"
    Line #27 change to: maxOccurs="2"
    Organisation_Plan_Order_Assoc_Status.xsd
    Line #13 change to: maxOccurs="unbounded"
    Line #15 change to: maxOccurs="unbounded"
    Line #16 change to: maxOccurs="unbounded"
    Line #17 change to: maxOccurs="unbounded"
    Line #21 change to: maxOccurs="unbounded"
    Line #22 change to: maxOccurs="unbounded"
    Line #24 change to: maxOccurs="unbounded"
    Organisation_Structure.xsd
    Line #8 change to: maxOccurs="2"
    Line #9 change to: maxOccurs="2"
    Line #11 change to: maxOccurs="unbounded"
    Line #14 change to: maxOccurs="2"
    Line #17 change to: maxOccurs="2"
    Person_Item.xsd
    Line #11 change to: maxOccurs="unbounded"
    Line #12 change to: maxOccurs="unbounded"
    Plan_Order_Component.xsd
    Line #10 change to: maxOccurs="unbounded"
    Line #11 change to: maxOccurs="unbounded"
    Line #12 change to: maxOccurs="unbounded"
    Line #13 change to: maxOccurs="unbounded"
    Line #14 change to: maxOccurs="unbounded"
    Line #15 change to: maxOccurs="unbounded"
    Line #16 change to: maxOccurs="unbounded"
    Plan_Order_Component_Content.xsd
    Line #13 change to: maxOccurs="unbounded"
    Line #16 change to: maxOccurs="unbounded"
    Plan_Order_Component_Structure.xsd
    Line #8 change to: minOccurs="2" maxOccurs="2"
    Line #9 change to: minOccurs="2" maxOccurs="2"
    Line #10 change to: minOccurs="2" maxOccurs="unbounded"
    Line #12 change to: maxOccurs="unbounded"
    Line #13 change to: maxOccurs="unbounded"
    Line #14 change to: maxOccurs="unbounded"
    Line #15 change to: maxOccurs="unbounded"
    Line #16 change to: maxOccurs="unbounded"
    Line #17 change to: maxOccurs="unbounded"
    Plan_Order_Item.xsd
    Line #9 change to: maxOccurs="unbounded"
    Line #11 change to: maxOccurs="unbounded"
    Line #12 change to: maxOccurs="unbounded"
    Line #13 change to: maxOccurs="unbounded"
    Line #14 change to: maxOccurs="unbounded"
    Line #15 change to: maxOccurs="unbounded"
    Line #16 change to: maxOccurs="unbounded"
    Line #17 change to: maxOccurs="unbounded"
    Line #18 change to: maxOccurs="unbounded"
    Request_Answer.xsd
    Line #10 change to: maxOccurs="unbounded"
    Line #11 change to: maxOccurs="4"
    Line #12 change to: minOccurs="2" maxOccurs="3"
    Line #13 change to: minOccurs="2" maxOccurs="3"
    Line #17 change to: maxOccurs="unbounded"
    Line #20 change to: maxOccurs="unbounded"
    Line #21 change to: maxOccurs="unbounded"
    Line #24 change to: maxOccurs="3"
    Line #25 change to: maxOccurs="unbounded"
    Line #26 change to: maxOccurs="unbounded"
    Line #27 change to: maxOccurs="unbounded"
    TrackArea_Surface.xsd
    Line #8 change to: minOccurs="2" maxOccurs="2"
    Line #9 change to: minOccurs="2" maxOccurs="8"
    Line #11 change to: maxOccurs="2"
    Line #12 change to: maxOccurs="2"
    Line #13 change to: maxOccurs="2"
    Line #14 change to: maxOccurs="2"
    Line #15 change to: maxOccurs="2"
    Line #16 change to: maxOccurs="2"
    Line #17 change to: maxOccurs="2"
    Line #19 change to: maxOccurs="2"
    Line #20 change to: maxOccurs="2"
    Line #21 change to: maxOccurs="2"
    Line #22 change to: maxOccurs="2"
    Line #23 change to: maxOccurs="2"
    Line #24 change to: maxOccurs="2"
    Line #25 change to: maxOccurs="2"
    Line #26 change to: maxOccurs="2"
    Line #27 change to: maxOccurs="

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Elipse_Surface

  • Key: SOPES-5
  • Legacy Issue Number: 14838
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This transactional's oclConstructionSequence refers to Elipse.elps_center_point_id when it should refer to Elipse.elipse-center-point-id. Idem for Elipse.elps_scnd_cnjg_diam_point_id and Elipse.elps_first_cnjg_diam_point_id.

  • Reported: SOPES 1.0b1 — Wed, 23 Dec 2009 05:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    see dtc/2010-05-06

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Plan_Order_Item

  • Key: SOPES-4
  • Legacy Issue Number: 14837
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This transactional has no OCL constraints.

  • Reported: SOPES 1.0b1 — Wed, 23 Dec 2009 05:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    An oclConstructionSequence is to be added in Annex C section C.15.11 Plan_Order_Item

    These oclConstructionsequences were derived from the UML models in Section 10. The models form the normative element of the specification. The OCL provides additional information to the developers on the order in which the arcs are navigated during the aggregation of data elements.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Replace normative spelling of "materiel" to US spelling "material"

  • Key: SOPES-3
  • Legacy Issue Number: 16165
  • Status: open  
  • Source: Object Management Group ( Linda Heaton)
  • Summary:

    Replace normative spelling of such words as materiel, organisation, specialisation, authorisation, colour, harbour, and programme to the US spelling. This includes model and technical element of the specification and involves figures as well.

  • Reported: SOPES 1.0 — Thu, 5 May 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 35, Section 7.2.1 – para 1

  • Key: SOPES-21
  • Legacy Issue Number: 15191
  • Status: closed  
  • Source: ECC ( Erik Chaum)
  • Summary:

    Replace:

    “... SOPES Modeling ...” with “... SOPES UML Modeling... “”

    Delete:

    “, which describes the UML modeling profile and it links the UML Profile for DOAF and MODAF”

  • Reported: SOPES 1.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    Accept wording change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 5.13.1

  • Key: SOPES-20
  • Legacy Issue Number: 15190
  • Status: closed  
  • Source: ECC ( Erik Chaum)
  • Summary:

    Prototype cancelled by DND – Demonstration secion (5.13.1) needs to be limited to an SA capability using SOPES (Figure 5.5).
    ASMG

    Page 35, Section 7.2 header

    Web Ontology Language (OWL). Is last bullet from previous section.

  • Reported: SOPES 1.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    Need to add an alternative demonstration of the SOPES IEMS usage in the time frame. The addition will reflect the current demonstration available at ASMG and GD Canada Technology evaluation and demonstration Laboratory in Ottawa Canada.

    Replace Figure 5.6 with

    Update the description of the prototpe implementation.
    See Attachment SOPES-00019 for edited section 5.13.1

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 25 – Section 5.13 – Para 1

  • Key: SOPES-19
  • Legacy Issue Number: 15189
  • Status: closed  
  • Source: ECC ( Erik Chaum)
  • Summary:

    Wording Change:

    Replace:

    “... specify the a ...” ”... specify a ...”

    Delete:

    “an operational nodes’ information environment,”

    Delete:

    “The demonstration of this Proof-of-Concepts is scheduled for December 2009.”

  • Reported: SOPES 1.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    Accept wording change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 24 – Section 5.13 – Para 1:

  • Key: SOPES-18
  • Legacy Issue Number: 15188
  • Status: closed  
  • Source: ECC ( Erik Chaum)
  • Summary:

    Wording Change:

    Replace:

    “... ate ...” with “at”

    “... define ...” with “... defined ...”

  • Reported: SOPES 1.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    Accept wording change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 23 – Section 5.13 – bullets 2, 3, 4:

  • Key: SOPES-17
  • Legacy Issue Number: 15187
  • Status: closed  
  • Source: ECC ( Erik Chaum)
  • Summary:

    Wording Change:

    Replace:

    “As” with “Serve as”

  • Reported: SOPES 1.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    Accept wording change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 16 – Section 5.8.3 – para 4:

  • Key: SOPES-16
  • Legacy Issue Number: 15186
  • Status: closed  
  • Source: ECC ( Erik Chaum)
  • Summary:

    Wording Change:

    Replace:

    “ ... semantics of a community by limiting the specification to a set of transactional patterns; leaving the specification of the message semantic to the community adopting this specification.”

    With

    “semantics. The limited set of transactional patterns may be extended and combined, as required, to form messages / semantics for community information exchange. “

  • Reported: SOPES 1.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    Accept wording change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 16 – Section 5.8.2 – bullet 6:

  • Key: SOPES-15
  • Legacy Issue Number: 15185
  • Status: closed  
  • Source: ECC ( Erik Chaum)
  • Summary:

    Wording Change:

    Replace:

    “... provide communities can use...” with “...enable communities to use ...”

  • Reported: SOPES 1.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    Accept wording change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 14 – Section 5.6.4 Para 1:

  • Key: SOPES-14
  • Legacy Issue Number: 15184
  • Status: closed  
  • Source: ECC ( Erik Chaum)
  • Summary:

    Wording Change:

    Delete “the implementation”.

    Replace:

    “application for” With “application of”

  • Reported: SOPES 1.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    Accept wording change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 13 – Section 5.6.3 Para 2:

  • Key: SOPES-13
  • Legacy Issue Number: 15183
  • Status: closed  
  • Source: ECC ( Erik Chaum)
  • Summary:

    Wording Change:

    Replace:

    “This specific PSM ...” With “These specific PSMs were ...”

    Requested change from the US Delegation to MIP
    E. Chaum

  • Reported: SOPES 1.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    Accept wording change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 8 – Section 5.2 Para 2: editorial

  • Key: SOPES-12
  • Legacy Issue Number: 15182
  • Status: closed  
  • Source: ECC ( Erik Chaum)
  • Summary:

    Wording Change:

    Replace:

    “This SOPES IEDM specification has one objective that of formalizing a set of reusable information patterns for the MIP JC3IEDM to deliver building blocks for multiple community semantics. “

    With

    “This SOPES IEDM proposal has as an objective to formalize a set of reusable information patterns, based on the JC3IEDM, that can be used as building blocks for community information exchanges / messages (referred to as "semantics")”
    Requested change from the US Delegation to MIP
    E. Chaum

  • Reported: SOPES 1.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    Accept wording change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 8 – Section 5.2 Para 2: wording change

  • Key: SOPES-11
  • Legacy Issue Number: 15181
  • Status: closed  
  • Source: ECC ( Erik Chaum)
  • Summary:

    Remove “(semantics)”

  • Reported: SOPES 1.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    Accept wording change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 8 – Section 5.2 Para 1:

  • Key: SOPES-10
  • Legacy Issue Number: 15180
  • Status: closed  
  • Source: ECC ( Erik Chaum)
  • Summary:

    Wording Change:

    ... will provide two or more communities to ...

    With

    ... will enable two of more community systems ...

  • Reported: SOPES 1.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    Accept wording change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 1.5.1 para 1:

  • Key: SOPES-9
  • Legacy Issue Number: 15179
  • Status: closed  
  • Source: ECC ( Erik Chaum)
  • Summary:

    Remove extra period at end of para.

  • Reported: SOPES 1.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    No Change

    Cannot find the extra period – likely corrected in the reformatting after AB version which the MIP comments were based.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page xv – Para 4: wording change

  • Key: SOPES-8
  • Legacy Issue Number: 15178
  • Status: closed  
  • Source: ECC ( Erik Chaum)
  • Summary:

    A number of ...

    With

    Today, there are many who are interested in exploiting the semantics of the JC3IEDM in service oriented architecture

    (SOA), web services, web portals and/or Data-Distribution Service for Real-time Systems (DDS) implementations. For

    communities to use JC3IEDM, with modern platform specific dissemination technologies, requires representation of the

    DEM information exchange business rules in a platform independent manner. This specification provides a platform

    independent representation of the JC3IEDM and its information exchange business rules.

  • Reported: SOPES 1.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    Accept requested wording change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Annex A - A navigation constraint appears in a note

  • Key: SOPES-34
  • Legacy Issue Number: 15195
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    A navigation constraint appears in a note. Notes, more or less by definition, have no formal semantics. Why are they being used to include the OCL? Or is that just how the tool displays constraints?

  • Reported: SOPES 1.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — SOPES 1.0
  • Disposition Summary:

    Accept editorial Change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT