Issues for Mailing list of the SOPES IEDM Finalization Task Force
To comment on any of these issues, send email to sopes-iedm-ftf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.
List of issues (green=resolved, yellow=pending Board vote, red=unresolved)
Issue 14837: Plan_Order_Item
Issue 14838: Elipse_Surface
Issue 14839: …Verbose XSD\Line_Item.xsd
Issue 15177: Page xv – Para 4:
Issue 15178: Page xv – Para 4: wording change
Issue 15179: Section 1.5.1 para 1:
Issue 15180: Page 8 – Section 5.2 Para 1:
Issue 15181: Page 8 – Section 5.2 Para 2: wording change
Issue 15182: Page 8 – Section 5.2 Para 2: editorial
Issue 15183: Page 13 – Section 5.6.3 Para 2:
Issue 15184: Page 14 – Section 5.6.4 Para 1:
Issue 15185: Page 16 – Section 5.8.2 – bullet 6:
Issue 15186: Page 16 – Section 5.8.3 – para 4:
Issue 15187: Page 23 – Section 5.13 – bullets 2, 3, 4:
Issue 15188: Page 24 – Section 5.13 – Para 1:
Issue 15189: Page 25 – Section 5.13 – Para 1
Issue 15190: Section 5.13.1
Issue 15191: Page 35, Section 7.2.1 – para 1
Issue 15192: Page 38 – section 7.5.1 –
Issue 15193: Page 38 – section 7.5.1 - editorial
Issue 15194: Annex A
Issue 15196: Annex A - The syntax of the navigation constraint isn’t OCL
Issue 15197: Annex A - “Wrapper::Wrapper_1” isn’t proper OCL (or UML).
Issue 15198: If the invariant is on the association then you need to navigate through class InformationSemantic_1
Issue 15199: Annex A - You should navigate using the association role name (identifier), not the class name
Issue 15200: Annex A - If you do use the class name, you must use lowercase its first letter
Issue 15201: You should avoid using identifier names with hyphens
Issue 15202: Clarify ConstructionSequence
Issue 15203: Annex C - logic behind the order in which OCL elements appear
Issue 15204: Navigation constraint names
Issue 15205: Missing titles on Figure 5.3
Issue 15206: Optimized and Verbose having been submitted incorrectly
Issue 15241: Missing tiles on Figure 5.3
Issue 15242: Missing tiles on Figure 5.2
Issue 15243: Related in nature to SOPES-00001 ie missing oclConstructionSequence elements in the following subsections-
Issue 15244: Annex D - xsd issue
Issue 15245: Annex A - The Navigation Constraint example in diagram A.8 could benefit from further explanation
Issue 15246: Navigation Constraint modelling
Issue 15252: Missing Annex
Issue 16165: Replace normative spelling of "materiel" to US spelling "material"
Issue 14837: Plan_Order_Item (sopes-iedm-ftf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: This transactional has no OCL constraints.
Resolution: 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.
Revised Text: Subsection C.15.11 Plan_Order_Item: Add
oclConstructionSequence
Context Plan_Order_Item
let step1ReadPlan1 = Tuple{sourceAttr = self.PlanOrder.plan-order-id, targetAttr = self.Plan_Order_Header_Content.plan-order-id}
let step1ReadSeq = Sequence{ step1ReadPlan1}
let step1 = Tuple{source = self.PlanOrder, target = self.Plan_Order_Header_Content, multiplicity = 1..*, rdSeq = step1ReadSeq}
let step2ReadPlan1 = Tuple{sourceAttr = self.PlanOrder.plan-order-id, targetAttr = self.Plan.plan-id}
let step2ReadSeq = Sequence{ step2ReadPlan1}
let step2 = Tuple{source = self.PlanOrder, target = self.Plan, multiplicity = 1, rdSeq = step2ReadSeq}
let step3ReadPlan1 = Tuple{sourceAttr = self.PlanOrder.plan-order-id, targetAttr = self.Order.order-id}
let step3ReadSeq = Sequence{ step3ReadPlan1}
let step3 = Tuple{source = self.PlanOrder, target = self.Order, multiplicity = 1, rdSeq = step3ReadSeq}
let step4ReadPlan1 = Tuple{sourceAttr = self.PlanOrder.plan-order-id, targetAttr = self.Plan_Order_Component.plan-order-id}
let step4ReadSeq = Sequence{ step4ReadPlan1}
let step4 = Tuple{source = self.PlanOrder, target = self.Plan_Order_Component, multiplicity = 0..*, rdSeq = step4ReadSeq}
let constructionSequence = Sequence{self.PlanOrder, step1, step2, step3, step4}
Disposition: Resolved
Actions taken:
December 23, 2009: received issue
October 21, 2010: closed issue
Issue 14838: Elipse_Surface (sopes-iedm-ftf)
Click here for this issue's archive.
Click here for this issue's attachments.
Nature: Uncategorized Issue
Severity:
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.
Resolution: see dtc/2010-05-06
Revised Text:
Actions taken:
December 23, 2009: received issue
October 21, 2010: closed issue
Issue 14839: …Verbose XSD\Line_Item.xsd (sopes-iedm-ftf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
Resolution: 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="
Revised Text:
Actions taken:
December 23, 2009: received issue
October 21, 2010: closed issue
Discussion:
Issue 15177: Page xv – Para 4: (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Naval Undersea Warfare Center (Mr. Erik Chaum, erik.chaum(at)navy.mil)
Nature: Uncategorized Issue
Severity:
Summary:
Wording Change:
... that the ECM Community see during ECM operations.
With
... that the ECM Community may see during ECM operations with military partners.
Resolution: Accept requested wording change
Revised Text: Informal discussions with the MIP member nations exposed a natural desire to share MIP technology and lessons-learned from its rich history of accomplishment. It is felt that the JC3IEDM could enable and support the requirements of a broader community such as the emergency and crisis management. Even if not internalized by ECM systems, the JC3IEDM provides a standard multinational command and control (C2) interface specification that the ECM Community may see during ECM operations with military partners In return, MIP enabled organizations could interoperate with a broader community without major changes to its internal processes and structures. The OMG C4I DTF represents an opportunity for the MIP and ECM communities to leverage each others' activities in a neutral forum.
Disposition: Resolved
Actions taken:
April 7, 2010: received issue
October 21, 2010: closed issue
Discussion:
Issue 15178: Page xv – Para 4: wording change (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Naval Undersea Warfare Center (Mr. Erik Chaum, erik.chaum(at)navy.mil)
Nature: Uncategorized Issue
Severity:
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.
Resolution: Accept requested wording change
Revised Text: 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.
Disposition: Resolved
Actions taken:
April 7, 2010: received issue
October 21, 2010: closed issue
Issue 15179: Section 1.5.1 para 1: (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Naval Undersea Warfare Center (Mr. Erik Chaum, erik.chaum(at)navy.mil)
Nature: Uncategorized Issue
Severity:
Summary: Remove extra period at end of para.
Resolution: No Change
Cannot find the extra period – likely corrected in the reformatting after AB version which the MIP comments were based.
Revised Text:
Actions taken:
April 7, 2010: received issue
October 21, 2010: closed issue
Discussion:
Issue 15180: Page 8 – Section 5.2 Para 1: (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Naval Undersea Warfare Center (Mr. Erik Chaum, erik.chaum(at)navy.mil)
Nature: Uncategorized Issue
Severity:
Summary: Wording Change:
... will provide two or more communities to ...
With
... will enable two of more community systems ...
Resolution: Accept wording change
Revised Text: The SOPES initiative will deliver a set of open specifications that deliver policy based Semantic Interoperability between heterogeneous information systems. The capability will enable two of more community systems to exchange information between systems and have the meaning of that information preserved. The information will be automatically parsed, interpreted, stored and reported by the receiving system in a manner that produces a desired result, as specified by the community of interest.
Actions taken:
April 7, 2010: received issue
October 21, 2010: closed issue
Issue 15181: Page 8 – Section 5.2 Para 2: wording change (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Naval Undersea Warfare Center (Mr. Erik Chaum, erik.chaum(at)navy.mil)
Nature: Uncategorized Issue
Severity:
Summary: Remove “(semantics)”
Resolution: Accept wording change
Revised Text: Over the last decade the community has started to appreciate the value of formal languages for expressing concepts that enable coordination, collaboration, command and control.
Actions taken:
April 7, 2010: received issue
October 21, 2010: closed issue
Issue 15182: Page 8 – Section 5.2 Para 2: editorial (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Naval Undersea Warfare Center (Mr. Erik Chaum, erik.chaum(at)navy.mil)
Nature: Uncategorized Issue
Severity:
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
Resolution: Accept wording change
Revised Text: This SOPES IEDM proposal has as an objective to formalize a set of reusable information patterns, based on the JC3IEDM, which can be used as building blocks for community information exchanges / messages (referred to as "semantics").
Actions taken:
April 7, 2010: received issue
October 21, 2010: closed issue
Issue 15183: Page 13 – Section 5.6.3 Para 2: (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Naval Undersea Warfare Center (Mr. Erik Chaum, erik.chaum(at)navy.mil)
Nature: Uncategorized Issue
Severity:
Summary: Wording Change:
Replace:
“This specific PSM ...” With “These specific PSMs were ...”
Requested change from the US Delegation to MIP
E. Chaum
Resolution: Accept wording change
Revised Text: These specific PSMs werenot generated for the specification but have been generated as part of the MIP model-driven architecture (MDA) working party proof-of-principal demonstrations (not currently a MIP standard product).
Actions taken:
April 7, 2010: received issue
October 21, 2010: closed issue
Issue 15184: Page 14 – Section 5.6.4 Para 1: (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Naval Undersea Warfare Center (Mr. Erik Chaum, erik.chaum(at)navy.mil)
Nature: Uncategorized Issue
Severity:
Summary: Wording Change:
Delete “the implementation”.
Replace:
“application for” With “application of”
Resolution: Accept wording change
Revised Text: The SOPES IEDM is a UML notation that can be used to directly generate XML XSD, OWL or RDF. These specific PSMs werenot generated for the specification but have been generated as part of the MIP model-driven architecture (MDA) working party proof-of-principal demonstrations (not currently a MIP standard product). As these products are certified and accredited by the MIP community, there is an opportunity to incorporate them into the SOPES and IEF initiatives through the OMG Request for Comment (RFC) Process; further expanding interoperability options.
5.6.4 Database Applications
NATO STANAG 5525 provides the logical and physical Entity Relationship Diagrams (ERD) in IDEF 1x notation and the Structured Query language (SQL) Data Definition language (DDL) for the application of relational database application for the JC3IEDM. Prior to SOPES initiative, there was no modeling convention for the expression of a UML representation of the database and its component information elements. The SOPES IEDM Specification defines a standard set of transactions for the JC3IEDM physical schema. The SOPES defined transactions are expected to be useful, but do not represent all possible concepts supported by the JC3IEDM. Communities are free to extend the concepts to support community needs.
Actions taken:
April 7, 2010: received issue
October 21, 2010: closed issue
Issue 15185: Page 16 – Section 5.8.2 – bullet 6: (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Naval Undersea Warfare Center (Mr. Erik Chaum, erik.chaum(at)navy.mil)
Nature: Uncategorized Issue
Severity:
Summary: Wording Change:
Replace:
“... provide communities can use...” with “...enable communities to use ...”
Resolution: Accept wording change
Revised Text: · The approach would enable communities to useselected building blocks without being forced to adopt the entire JC3IEDM.
Actions taken:
April 7, 2010: received issue
October 21, 2010: closed issue
Issue 15186: Page 16 – Section 5.8.3 – para 4: (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Naval Undersea Warfare Center (Mr. Erik Chaum, erik.chaum(at)navy.mil)
Nature: Uncategorized Issue
Severity:
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. “
Resolution: Accept wording change
Revised Text: Extensibility. The SOPES IEDM PIM is structured in a manner that facilitates the extension of the core semantics. The limited set of transactional patterns may be extended and combined, as required, to form messages / semantics for community information exchange. The adoption of UML allows communities to add security (filters, constraints, etc.) and transformations to enable communities to refine the specification while maintaining JC3IEDM integrity.
Actions taken:
April 7, 2010: received issue
October 21, 2010: closed issue
Issue 15187: Page 23 – Section 5.13 – bullets 2, 3, 4: (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Naval Undersea Warfare Center (Mr. Erik Chaum, erik.chaum(at)navy.mil)
Nature: Uncategorized Issue
Severity:
Summary: Wording Change:
Replace:
“As” with “Serve as”
Resolution: Accept wording change
Revised Text: The Department of National Defence (DND), Enterprise Information Security Environment (EISE) in pnning the development of an operational prototype using the SOPES IEDM Specification to:
1. Provide an architected set of data patterns for the aggregation of data maintained as part operational databases instantiating the MIP JC3IEDM Schema;
2. Serve as a basis for selectively aggregating data based on community approved semantics;
3. Serve as a foundation for dynamically altering community semantics and exchange agreement in order to address changes in the operational situation requiring the changes in information release policy; and
4. Serve as the basis for determining and assessing the sensitivity and risks associated with the release of additional operational data.
Actions taken:
April 7, 2010: received issue
October 21, 2010: closed issue
Issue 15188: Page 24 – Section 5.13 – Para 1: (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Naval Undersea Warfare Center (Mr. Erik Chaum, erik.chaum(at)navy.mil)
Nature: Uncategorized Issue
Severity:
Summary: Wording Change:
Replace:
“... ate ...” with “at”
“... define ...” with “... defined ...”
Resolution: Accept wording change
Revised Text: The Department of National Defence (DND), Enterprise Information Security Environment (EISE) in pinning the development of an operational prototype using the SOPES IEDM Specification to:
Actions taken:
April 7, 2010: received issue
October 21, 2010: closed issue
Issue 15189: Page 25 – Section 5.13 – Para 1 (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Naval Undersea Warfare Center (Mr. Erik Chaum, erik.chaum(at)navy.mil)
Nature: Uncategorized Issue
Severity:
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.”
Resolution: Accept wording change
Revised Text: The ASMG has developed a Maritime Security demonstration using the SOPES IEDM to prescribe the semantics to specify the exchange rules between the operational nodes in a harbour security demonstration, comprising multiple government operating centres. The demonstration will also demonstrate:
· The transformation of the SOPES IEDM and supporting semantic models into a set of executable information exchange policies;
· The ability to execute the information exchange based on on the SOPES data patterns and developed semantics.
· The ability to alter the exchange patterns during the demonstration, to address changes in operational context (new information exchange requirements), based on the metadata construct held in the SOPES defined policies.;
· The ability to use the underlying meta-data to define data filters in exchange agreements; and
· The use of the SOPES IEDM in the development of user entry forms.
Actions taken:
April 7, 2010: received issue
October 21, 2010: closed issue
Issue 15190: Section 5.13.1 (sopes-iedm-ftf)
Click here for this issue's archive.
Click here for this issue's attachments.
Source: Naval Undersea Warfare Center (Mr. Erik Chaum, erik.chaum(at)navy.mil)
Nature: Uncategorized Issue
Severity:
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.
Resolution: 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
Revised Text: Figure 5.5 illustrates the operational context for the demonstration. The JC3IEDM Schema forms the data environment for each node, with the SOPES IEDM forming the transactional rules underpinning community information exchange agreements.
Figure 5.5 - Initial Proof of Concept Overview
Figure 5.6 illustrates where the rules expressed by the SOPES models are enforced. For the EISE demonstration SOPES IEDM metadata will be transformed in to a meta-object model (MOM) that reflect the information exchange policies (rules) to be enforced at each of the operational nodes. The Common Object Interoperability Layer (COIL) ingests the MOM and uses its underlying rules to aggregate JC3EDM information for use or dissemination; and marshal received information for storage in an instantiated JC3IEDM data store. The MOM forms a runtime instantiation of the SOPES IEDM defined rules integrated into community contracts and semantics (see Chapter 11 and Annex A).
The demonstration will exchange information between nodes in accordance with the Optimized XSD (see Annex D2) and MIP PDUs. Community contracts will be enforced using the publish and subscribe protocols specified for Data Distribution Service for Real-time Systems (DDS).
Figure 5.6 Information Exchange Policy Management Demonstration
The ASMG has developed a Maritime Security demonstration using the SOPES IEDM to prescribe the semantics to specify the exchange rules between the operational nodes in a harbour security demonstration, comprising multiple government operating centres. The demonstration will also demonstrate:
· The transformation of the SOPES IEDM and supporting semantic models into a set of executable information exchange policies;
· The ability to execute the information exchange based on on the SOPES data patterns and developed semantics.
· The ability to alter the exchange patterns during the demonstration, to address changes in operational context (new information exchange requirements), based on the metadata construct held in the SOPES defined policies.;
· The ability to use the underlying meta-data to define data filters in exchange agreements; and
· The use of the SOPES IEDM in the development of user entry forms.
Figure 5.6 illustrates the components of a policy management being developed for the demonstration.
Disposition: Resolved
Actions taken:
April 7, 2010: received issue
October 21, 2010: closed issue
Issue 15191: Page 35, Section 7.2.1 – para 1 (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Naval Undersea Warfare Center (Mr. Erik Chaum, erik.chaum(at)navy.mil)
Nature: Uncategorized Issue
Severity:
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”
Resolution: Accept wording change
Revised Text: Additional SOPES PIM MDA transformation options include the following types of PSMs:
· NET Objects
· Java Object
· Web Ontology Language (OWL).
7.2 SOPES Design
7.2.1 Modeling Concept
Actions taken:
April 7, 2010: received issue
October 21, 2010: closed issue
Issue 15192: Page 38 – section 7.5.1 – (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary: XML schema is used in the Annexes – not DTDs
Resolution: 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.
Revised Text: 7.5.1 An Overview of XMI
The purpose of XMI is to allow the interchange of models in a serialized form. Since the MOF is the OMG’s adopted technology for representing metadata, it is natural that XMI focuses on the interchange of MOF metadata; that is, metadata conforming to a MOF meta-model. In fact, XMI is really a pair of parallel mappings: one between MOF meta- models and XML Schems, and another between MOF metadata and XML documents.
XMI can be viewed as a common metadata interchange format that is independent of middleware technology. Any metadata repository or tool that can encode and decode XMI streams can exchange metadata with other repositories or tools with the same capability.
XMI provides a possible route for interchange of metadata with repositories whose meta-models are not MOF based. This interchange can be realized by specific mappings between an XMI document and the repository’s native meta-model.
XMI is based on the W3C’s Extensible Markup Language (XML), and has two major components:
The XML Schema Rules 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 XMI generated by Sparx Enterprise Architecture is published along with the SOPES IEDM Specification.
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.
XMI supports the interchange of any kind of metadata that can be expressed using the MOF specification. It supports the encoding of metadata consisting of both complete models and model fragments, as well as tool-specific extension metadata. XMI has optional support for interchange of metadata in differential form, and for metadata interchange with tools that have incomplete understanding of the metadata.
7.5.2 The Relationship between SOPES IEDM and XMI
SOPES IEDM uses XMI as its interchange mechanism. This means that the full power and flexibility of XMI is available for interchanging both warehouse metadata and the SOPES IEDM meta-model itself. SOPES IEDM does not require any extensions to XMI. A standard schema for the SOPES IEDM meta-model is generated using XMI’s schema Production Rules. A standard XML document for the SOPES IEDM meta-model is also generated using XMI’s Document Production Rules, based on the MOF Schema.
Actions taken:
April 7, 2010: received issue
October 21, 2010: closed issue
Issue 15193: Page 38 – section 7.5.1 - editorial (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Naval Undersea Warfare Center (Mr. Erik Chaum, erik.chaum(at)navy.mil)
Nature: Uncategorized Issue
Severity:
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”
Resolution: Accept editorial change
Revised Text: OMG Issue No: 15193
Title: SOPES-00022
Source:
E. Chaum, MIP/ DOD/ NUWC - erik.chaum@navy.mil
Summary:
Page 38 – section 7.5.1 –
This is the final version and exemplar semantics are provides in section 11
Resolution:
Accept editorial change
Revised Text:
Disposition: Resolved
OMG Issue No: 15193
Title: SOPES-00023
Source:
E. Chaum, MIP/ DOD/ NUWC - erik.chaum@navy.mil
Summary:
Page 52 – Section 9.2 – Bullet 4
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.
Resolution:
Accept editorial change
Revised Text:
· “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.
Disposition: Resolved
OMG Issue No: 15193
Title: SOPES-00024
Source:
E. Chaum, MIP/ DOD/ NUWC - erik.chaum@navy.mil
Summary:
Page 52 – Section 9.2 – Bullet 4
This is the final version and exemplar semantics are provides in section 11
Resolution:
Re word:
Reword the bullet to reflect the inclusion of the Exemplar Semantic in the Final Version of the Specification.
The edit was missed from earlier revised specification where the semantics were not yet provided.
Revised Text:
.
Disposition: Resolved
OMG Issue No: 15193
Title: SOPES-00025
Source:
E. Chaum, MIP/ DOD/ NUWC - erik.chaum@navy.mil
Summary:
Page 57 – Section 9.5.1 – Bullet 1
“JC3-V3-1b_entity” with “JC3-V3-1c_entity”
Resolution:
Accept editorial Change.
Revised Text:
.
Disposition: Resolved
Actions taken:
April 7, 2010: received issue
October 21, 2010: closed issue
Discussion:
Issue 15194: Annex A (sopes-iedm-ftf)
Click here for this issue's archive.
Click here for this issue's attachments.
Source: Institute for Defense Analyses (Dr. Steven Wartik, swartik(at)ida.org)
Nature: Uncategorized Issue
Severity:
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
Resolution: Rework the elements in the diagrams in the Annex to reflect the corrections needed in the OCL.
Revised Text:
Actions taken:
April 7, 2010: received issue
October 21, 2010: closed issue
Discussion:
Issue 15196: Annex A - The syntax of the navigation constraint isn’t OCL (sopes-iedm-ftf)
Click here for this issue's archive.
Click here for this issue's attachments.
Source: Institute for Defense Analyses (Dr. Steven Wartik, swartik(at)ida.org)
Nature: Uncategorized Issue
Severity:
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
Resolution: 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.
Revised Text:
Figure A.8 - Constraints
Actions taken:
April 7, 2010: received issue
October 21, 2010: closed issue
Issue 15197: Annex A - “Wrapper::Wrapper_1” isn’t proper OCL (or UML). (sopes-iedm-ftf)
Click here for this issue's archive.
Click here for this issue's attachments.
Source: Institute for Defense Analyses (Dr. Steven Wartik, swartik(at)ida.org)
Nature: Uncategorized Issue
Severity:
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
Resolution: 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.
Revised Text:
Actions taken:
April 7, 2010: received issue
October 21, 2010: closed issue
Discussion:
Issue 15198: If the invariant is on the association then you need to navigate through class InformationSemantic_1 (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Institute for Defense Analyses (Dr. Steven Wartik, swartik(at)ida.org)
Nature: Uncategorized Issue
Severity:
Summary: Annex A
If the invariant is on the association then you need to navigate through class InformationSemantic_1.
Resolution: 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”
Revised Text:
Actions taken:
April 7, 2010: received issue
October 21, 2010: closed issue
Issue 15199: Annex A - You should navigate using the association role name (identifier), not the class name (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Institute for Defense Analyses (Dr. Steven Wartik, swartik(at)ida.org)
Nature: Uncategorized Issue
Severity:
Summary: You should navigate using the association role name (identifier), not the class name
Resolution: 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
Revised Text:
Actions taken:
April 7, 2010: received issue
October 21, 2010: closed issue
Issue 15200: Annex A - If you do use the class name, you must use lowercase its first letter (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Institute for Defense Analyses (Dr. Steven Wartik, swartik(at)ida.org)
Nature: Uncategorized Issue
Severity:
Summary: If you do use the class name, you must use lowercase its first letter
Resolution: 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.
Revised Text:
Actions taken:
April 7, 2010: received issue
October 21, 2010: closed issue
Issue 15201: You should avoid using identifier names with hyphens (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Institute for Defense Analyses (Dr. Steven Wartik, swartik(at)ida.org)
Nature: Uncategorized Issue
Severity:
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.
Resolution: 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
Revised Text:
Actions taken:
April 7, 2010: received issue
October 21, 2010: closed issue
Issue 15202: Clarify ConstructionSequence (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Institute for Defense Analyses (Dr. Steven Wartik, swartik(at)ida.org)
Nature: Uncategorized Issue
Severity:
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
Resolution: 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.
Revised Text:
Actions taken:
April 7, 2010: received issue
October 21, 2010: closed issue
Issue 15203: Annex C - logic behind the order in which OCL elements appear (sopes-iedm-ftf)
Click here for this issue's archive.
Click here for this issue's attachments.
Source: Institute for Defense Analyses (Dr. Steven Wartik, swartik(at)ida.org)
Nature: Uncategorized Issue
Severity:
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?
Resolution: see dtc/2010-05-06
Revised Text:
Actions taken:
April 7, 2010: received issue
October 21, 2010: closed issue
Issue 15204: Navigation constraint names (sopes-iedm-ftf)
Click here for this issue's archive.
Click here for this issue's attachments.
Source: Institute for Defense Analyses (Dr. Steven Wartik, swartik(at)ida.org)
Nature: Uncategorized Issue
Severity:
Summary: Looking through the first few tables, it seems as if the navigation constraint names all end with a “}”.
Resolution: see dtc/2010-05-06
Revised Text:
Actions taken:
April 7, 2010: received issue
October 21, 2010: closed issue
Issue 15205: Missing titles on Figure 5.3 (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Advanced Systems Management Group Ltd. (Mr. Michael Abramson, abramson(at)rogers.com)
Nature: Uncategorized Issue
Severity:
Summary: Missing titles on Figure 5.3 - Add: "Development of Transactional Models"
Resolution:
Revised Text:
Actions taken:
April 16, 2010: received issue
Issue 15206: Optimized and Verbose having been submitted incorrectly (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Advanced Systems Management Group Ltd. (Mr. Simon Brameld, sbrameld(at)asmg-ltd.com)
Nature: Uncategorized Issue
Severity:
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
Resolution:
Revised Text:
Actions taken:
April 16, 2010: received issue
Issue 15241: Missing tiles on Figure 5.3 (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Advanced Systems Management Group Ltd. (Mr. Michael Abramson, abramson(at)rogers.com)
Nature: Revision
Severity: Minor
Summary: page 18 - Missing tiles on Figure 5.3
Resolution: Add: “Figure 5.3 - Development of Transactional Models”
Revised Text:
Actions taken:
May 5, 2010: received issue
October 21, 2010: closed issue
Issue 15242: Missing tiles on Figure 5.2 (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Advanced Systems Management Group Ltd. (Mr. Michael Abramson, abramson(at)rogers.com)
Nature: Revision
Severity: Minor
Summary: page 18 - Missing tiles on Figure 5.2
Resolution: Add: “Figure 5.2 - Using JC3IEDM Meta Model”
Revised Text:
Actions taken:
May 5, 2010: received issue
October 21, 2010: closed issue
Issue 15243: Related in nature to SOPES-00001 ie missing oclConstructionSequence elements in the following subsections- (sopes-iedm-ftf)
Click here for this issue's archive.
Click here for this issue's attachments.
Source: Advanced Systems Management Group Ltd. (Mr. Michael Abramson, abramson(at)rogers.com)
Nature: Revision
Severity: Minor
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
Resolution: These oclConstructionSequences were missed during the generation of the document and need to be added to the relevant subsections in Annex C
Revised Text: see dtc/2010-05-06
Actions taken:
May 5, 2010: received issue
October 21, 2010: closed issue
Issue 15244: Annex D - xsd issue (sopes-iedm-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Significant
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
Resolution: Original submission mislabelled the folders containing the two sets of schemas.
Reverse the Titles of the two groupings of XSDs.
Revised Text:
Actions taken:
May 5, 2010: received issue
October 21, 2010: closed issue
Discussion:
Issue 15245: Annex A - The Navigation Constraint example in diagram A.8 could benefit from further explanation (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Advanced Systems Management Group Ltd. (Mr. Michael Abramson, abramson(at)rogers.com)
Nature: Uncategorized Issue
Severity:
Summary: The Navigation Constraint example in diagram A.8 could benefit from further explanation
Resolution: 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'
Revised Text:
Actions taken:
May 5, 2010: received issue
October 21, 2010: closed issue
Issue 15246: Navigation Constraint modelling (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Advanced Systems Management Group Ltd. (Mr. Michael Abramson, abramson(at)rogers.com)
Nature: Uncategorized Issue
Severity:
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.
Resolution: 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.
Revised Text:
Actions taken:
May 5, 2010: received issue
October 21, 2010: closed issue
Issue 15252: Missing Annex (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Object Management Group (Mr. Andrew Watson, andrew(at)omg.org)
Nature: Uncategorized Issue
Severity:
Summary: Annex F
Missing XMI for the Models. Add Annex F and Zip file containing the XMI version of the model
Resolution: Add Annex F and Zip file containing the XMI version of the model
Revised Text:
Actions taken:
May 10, 2010:
October 21, 2010: closed issue
Discussion:
Issue 16165: Replace normative spelling of "materiel" to US spelling "material" (sopes-iedm-ftf)
Click here for this issue's archive.
Source: Object Management Group (Ms. Linda Heaton, linda(at)omg.org)
Nature: Revision
Severity: Significant
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.
Resolution:
Revised Text:
Actions taken:
May 5, 2011: received issue