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

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

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.

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.

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

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'

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

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

Reverse the Titles of the two groupings of XSDs.

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

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

page 18 - Missing tiles on Figure 5.3

Add: “Figure 5.3 - Development of Transactional Models”

page 18 - Missing tiles on Figure 5.2

Add: “Figure 5.2 - Using JC3IEDM Meta Model”

Replace:

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

Delete:

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

Accept wording change

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.

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

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

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

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”

Accept editorial change

XML schema is used in the Annexes – not DTDs

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.

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?

see dtc/2010-05-06

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

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.

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

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

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

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”

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

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.

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.

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

“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

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.

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

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.

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

see dtc/2010-05-06

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.

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="

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.

see dtc/2010-05-06

This transactional has no OCL constraints.

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.

Remove extra period at end of para.

No Change

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

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.

Accept requested wording change

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.”

Accept wording change

Wording Change:

Replace:

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

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

Accept wording change

Wording Change:

Replace:

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

Requested change from the US Delegation to MIP
E. Chaum

Accept wording change

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

Accept wording change

Wording Change:

Delete “the implementation”.

Replace:

“application for” With “application of”

Accept wording change

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. “

Accept wording change

Wording Change:

Replace:

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

Accept wording change

Wording Change:

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

With

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

Accept requested wording change

Wording Change:

Replace:

“As” with “Serve as”

Accept wording change

Wording Change:

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

With

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

Accept wording change

Remove “(semantics)”

Accept wording change

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?

Accept editorial Change.