JC3IEDM-Annex O-XML-3.1.4.doc

Transcription

JC3IEDM - Annex O - IPT3
V3.1.4
ANNEX O. EXTENSIBLE MARKUP LANGUAGE (XML)
REFERENCE SCHEMAS AND IMPLEMENTATION GUIDANCE
Contents
ANNEX O. EXTENSIBLE MARKUP LANGUAGE (XML) REFERENCE SCHEMAS AND
IMPLEMENTATION GUIDANCE ......................................................................................................... 1
O1.
BACKGROUND ................................................................................................................... 3
O2.
PURPOSE OF THE ANNEX ................................................................................................ 4
O3.
OPERATIONAL VIEW ........................................................................................................ 5
O4.
XSD DESIGN OVERVIEW................................................................................................ 15
O5.
SCHEMA DESIGN CONSIDERATIONS .......................................................................... 19
O5.1
RDBMS XSD ...................................................................................................................... 19
O5.2
WEB SERVICE/OBJECT-ORIENTED SCHEMA ............................................................ 21
O5.3
COIS USING JC3IEDM AS A FOUNDATION FOR COI BO ..................................................... 23
O6.
APPLICATION USE CONSIDERATIONS ....................................................................... 24
O7.
TOOLS OVERVIEW .......................................................................................................... 26
O8.
DELIVERY ......................................................................................................................... 26
O9.
ONGOING XML COLLABORATION .............................................................................. 26
ANNEX O, APPENDIX 1 ENTITY-RELATIONSHIP XSD DESIGN DOCUMENT .......................... 1
O-1.1
INTRODUCTION ................................................................................................................. 1
O-1.2
THE MIP XML EXCHANGE MECHANISM USE CASES AND THEIR SCHEMA
REQUIREMENTS .............................................................................................................................. 1
O-1.3
XEM USE CASE GENERAL CONSIDERATIONS ............................................................ 3
O-1.4
GENERAL MIP RDBMS XML CONSIDERATIONS ......................................................... 4
O-1.5
SPECIFIC MIP RDBMS XML CONSIDERATIONS .......................................................... 5
O-1.6
CHARACTERISTICS OF THE BASELINE RDBMS XML SCHEMA ............................... 8
O-1.7
RDBMS XSD STRUCTURE ................................................................................................ 9
O-1.8.
RDBMS XSD GENERATION TOOLKIT ..................................................................... 14
O-1.9.
RDBMS ALTERNATE REPRESENTATIONS ............................................................ 14
ANNEX O, APPENDIX 2 EXTENSIBLE MARKUP LANGUAGE (XML) REFERENCE
IMPLEMENTATIONS RDBMS USE CASE .......................................................................................... 1
O-2.1
STRUCTURE OF THE DOCUMENT .................................................................................. 1
O-2.2
EXAMPLE 01. OBJECT-ITEM-ASSOCIATION AND OBJECT-ITEM-STATUS ............. 1
O-2.3
DATA PRESENTATION FOR THE END USER ........................................................................... 21
O-2.4
SUMMARY AND CONCLUSIONS ............................................................................................. 21
ANNEX O, APPENDIX 3 WS/OO XSD DESIGN DOCUMENT .......................................................... 1
O-1
V3.1.4
O-3.1
INTRODUCTION....................................................................................................................... 1
O-3.2.
NAMING CONVENTIONS .................................................................................................... 2
O-3.3.
DOMAINS ........................................................................................................................... 2
O-3.4.
ENTITIES AND ATTRIBUTES ............................................................................................... 3
O-3.5.
TRANSFORMATION RULES FOR RELATIONSHIPS ................................................................ 5
O-3.6
XML ROOT ELEMENT .......................................................................................................... 10
ANNEX O, APPENDIX 4 OO/WS USE CASE ...................................................................................... 1
O-4.1
INTRODUCTION....................................................................................................................... 1
O-4.2
OPERATIONAL SCENARIO ....................................................................................................... 1
O-4.3
JC3IEDM MODELLING .......................................................................................................... 2
O-4.4
INSTANCE XML DOCUMENTS ................................................................................................ 3
ANNEX O, APPENDIX 5 MULTILATERAL INTEROPERABILITY PROGRAMME OPEN
SOURCE LICENSE ................................................................................................................................. 1
ANNEX O, APPENDIX 6 XML TERMS AND REFERENCES ............................................................ 1
O-6.1
XML TERMS AND DEFINITIONS ............................................................................................. 1
O-6.2
W3C XML SPECIFICATIONS .................................................................................................. 3
O-6.3
OASIS AND UN/CEFACT SPECIFICATIONS .......................................................................... 3
O-6.4
ISO SPECIFICATIONS .............................................................................................................. 3
O-6.5
INTERNATIONAL XML NAMING AND DESIGN DOCUMENTS ................................................... 5
O-6.6
NATO XML DOCUMENTS ..................................................................................................... 5
O-6.7
WORLD WIDE WEB CONSORTIUM (W3C) .............................................................................. 5
ANNEX O, APPENDIX 7 BLUE FORCE POSITION REPORT SCHEMA (XSD) .............................. 1
O-2
V3.1.4
O1. BACKGROUND
O1.1 The use of the Extensible Mark-up Language (XML) for information
exchange and processing has reached a high degree of technical maturity, as well as
acceptance in the commercial world. XML provides a simple yet powerful mark-up
syntax that aids in making data more accessible, understandable and reusable.
O1.2 Although the XML features mentioned above are quite positive one
should never forget that automated, XML-based information exchange and processing
requires agreement on the semantics and format of the XML elements and their markup tags, as well as the clear specification of allowed instance XML document
structure and content.
O1.3 Fortunately, one of the XML technologies, namely the XML Schema
Definition (XSD), enables the specification of XML document content and structure.
This, coupled with specifications for the semantics of the data, such as the ones
provided by information models, offers the possibility of developing very robust
XML information exchange implementations.
O1.4 This Annex describes the approach taken in the Multilateral
Interoperability Programme (MIP) to leverage for the application of XML the results
achieved in the area of C2 and incorporated in the Joint Consultation, Command and
Control Information Exchange Data Model (JC3IEDM). National and programmatic
interest in using XML technology in applications and services has created an
opportunity for MIP partners to collaboratively produce and share capability to
implement XML-based data exchange solutions.
O1.5 The MIP information exchange data model enables command and
control system interoperability based on shared information exchange standards and
protocols developed through an international process that has built operational and
technical consensus. The JC3IEDM and its business rules define the MIP shared
vocabulary, grammar and business rules for information exchange and define the
required baseline semantics for implementing XML-based data exchange and
processing.
O1.6 The following sections of this Annex describe how any given version
of the MIP IEDM can be transformed to define XML Namespaces, in turn suitable for
building reference XSDs that can support XML-based consultation, command and
control (C3) information sharing within the MIP community.
O1.7 The contents of this Annex reflect a continuing effort centred on the
definition of XML use-cases, associated syntactic transformation patterns for XSD
design, Namespaces for the proposed XSDs, applications of the eXtensible Stylesheet
Language Transformations (XSLT), and prototype software tools. These components
provide a capability for MIP C3 information exchange services based on XML
technology and standards.
O-3
V3.1.4
O1.8 Table O-1 describes how XML technologies can be applied to support
the MIP Tactical C2IS Interoperability Requirements (MTIR Version 3.0.8).
Table O-1. XML Application to MIP Interoperability Requirements
MTIR Section
XML Contribution
3.1.2 – Information/Structured
Information
XML XSD enables the specification of predefined categories of
structured information in agreed to and understood formats.
Published XSDs enable storage of data in public formats and ease
reuse, validation and web service application implementation.
3.1.3 – Information
/Unstructured Information
XML XSD enables the specification of predefined categories of
information and metadata, e.g., metadata describing text, audio,
video, graphics, and tabular data typically not stored in databases.
Published XSDs enable storage of data in public formats, and ease
reuse, validation and web service application implementation.
3.1.4.1 – Information/
Information Exchange
/Automated Exchange without
Human Intervention
XML and XSD are core World Wide Web Consortium (W3C)
technologies for machine-to-machine information exchange on the
Internet. They are core technologies in a Service Oriented
Architecture (SOA) approach to the design of information services.
3.2.1 – Exchange Mechanism
/Information Pull
XML and XSD are widely used in the implementation of discovery,
web, and publish and subscribe services enabling enhanced
information discovery, access and presentation capability.
/Information Repository
XML technologies are widely used in on-line repositories providing
managed access to multiple national or multinational users at
distributed locations.
/Information Push
Document XSDs are the modern equivalent of electronic message
specifications. XML instance documents enable user and machinereadable messaging. XSDs enable machine validation of message
structure and content. Instance XML documents can be converted
using XSLT (Extensible Stylesheet Language Transformation) and
other technologies into alternative formats. XML-based Real Simple
Subscription (RSS) technology provides a common tailored service
for automated sender to receiver flow of structured information
(without user acknowledgement on the receiving side).
/Electronic Messaging
See 3.2.3.
/Online Collaboration
The real-time sharing and distributed editing of XML documents, in
addition to natural language text or voice exchanges, can serve as a
basis for improved online collaboration.
3.3.1 – Information
Management /Operational
Information Groups
Operational Information Groups (OIGs) are effectively predefined
electronic messages. See 3.2.3.
3.4.5 – Uninterruptible Support
to C2/”Moveability” of Static
Command Posts
XML-based services and server-side processing provide a
lightweight application framework that scales down to wireless
handheld devices and up to enterprise solutions. C2IS services and
applications using XML technologies are likely to enhance command
post’s mobility by enabling improved integrated access to C2
services and capabilities.
O2. PURPOSE OF THE ANNEX
This document describes how any MIP IEDM can be transformed to define an
XML Namespace XSD, in turn suitable for defining an XML document XSD,
enabling XML-based MIP C3 information sharing. It describes a model-driven
development approach, showing exemplar document XSD and XML instances to
O-4
V3.1.4
illustrate best practices. Reference MIP Namespace XSD and associated tools have
been developed to enable rapid harmonized implementation of MIP XML capabilities.
Additional information and resources are available at www.MIP-site.org. This Annex
and the associated technical artefacts are intended to:
a.
Simplify and accelerate the adoption of the MIP solution in ServiceOriented Architectures (SOAs) and web application development,
b.
Provide reference XML namespace implementations (to document
NDAG/MIP efforts in national and NATO registries),
c.
Reduce development costs and share / accelerate capability to the
warfighter,
d.
Promote commonality, interoperability, and community collaboration at
the operational and technical levels,
e.
Provide a basis for functional extensions to MIP’s Command and
Control core set of concepts and semantics, and
f.
Support the formal documentation of operational information groups
(OIG) and other standardized exchange documents.
O3. OPERATIONAL VIEW
Modern communications, computing, and information service technologies
have driven the military customer to reassess operational capability objectives for
future forces and caused considerable and ongoing modernization and reengineering
activities. An example is the NATO Network Enabled Capability (NNEC) concept. It
is an ambitious NATO command, control and communications endeavour that seeks
to align various components of the operational environment through a networked
information structure. Through improved sharing information, NECC is expected to
significantly enhance situational awareness in theatre, enabling better-informed
decision-making. In this section we consider a variety of operational and technical
factors that shape the definition of MIP XML capabilities, showing how they
contribute to information sharing across a network-enabled integrated force.
O3.1 Network-enabled Environment - Web Services
O3.1.1 Web services, like all other types of information systems, must deal
with the same familiar fundamental interface and processing challenges. This includes
agreeing on a protocol for interacting and moving bits from "entity" A to B and a
specification of what the payload bits mean. Effective robust automated information
sharing and processing only occurs when systems are able to reliably move and
interpret the bits that have been shared. These "fundamentals" show up in the World
Wide Web Consortium (W3C) definition of a Web service as shown in the steps in
Figure O-1 (Web Services Architecture reference document, URL:
http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/). In step 1, "parties 'become
known' to each other", i.e., two or more entities recognize they must exchange
information to accomplish their mission. Such groups are often referred to as
communities of interest. Step 2 requires that the entities agree on semantics (Sem),
what the payload bits mean, and protocol defining how the entities will interact and
O-5
V3.1.4
move bits (in the web service case - web service description, WSD). The semantic
specification captures the user domain information exchange requirements. These
technical agreements are used in step 3 as specifications for implementing the entity
software components (requester and provider agents) that interact in step 4.
“A Web service is a software system designed to support interoperable
machine-to-machine interaction over a network. It has an interface
described in a machine-processable format (specifically Web Service
Description Language - WSDL). Other systems interact with the Web service
in a manner prescribed by its description using SOAP messages, typically
conveyed using HTTP with an XML serialization in conjunction with other
Web-related standards.”
Figure O-1. Web Service Operational View
O3.1.2 The W3C high-level web service operational view in Figure O-1
directly correlates to the MIP Solution and its IEDM and IEM (analogous to the
semantics and WSD respectively). Thus, the MIP IEDM, expressed as a Namespace
XSD, can be directly leveraged to form the semantic basis for XML documents and
XML-based military web services.
O3.2 Communities of Interest (COI)
O3.2.1 Figure O-2 presents a high-level conceptual level view of two basic
approaches to information exchange between systems and services. The upper portion
(grey drop shadow) shows the typical "many-to-many" "point-to-point" semantic
O-6
V3.1.4
translation approach used when no shared community semantic standards exist1. Each
semantic translation introduces a degree of uncertainty, ambiguity, loss of precision or
context, i.e., the translation is lossy – each translation potentially degrading system
and operational performance. Lossy exchange cannot be fixed by technology, e.g.,
XML; it must be addressed by agreement on semantics. The MIP Solution is typical
of the desired functional community of interest (COI) approach (purple drop shadow)
that enforces a single semantic standard amongst the many systems and services that
must work together.
O3.2.2 Over time, nations interested in integrating many legacy capabilities in
a networked environment can expect to evolve from semantic translation amongst
systems and services (#1), to translation to semantic standards (#2), eventually to
reengineered capabilities that use standards for information exchange (#3). New
capabilities can be built to COI standards (#3).
Figure O-2. Conceptual View – Information Exchange
1
There are also instances of purely syntactic translation, i.e., the form but not the meaning are changed
– e.g., temperature conversions between ˚F and ˚C. This type of translation is not problematic.
Unfortunately, the majority of system-system, system-service, service-service translations today must
deal with semantic differences. The entire concept of an XML namespace is predicated on the need to
establish a common semantic basis for XML exchange. This is why legacy systems or services simply
publishing internal (i.e., semantically unique) information represented in XML does not improve
enterprise or community interoperability, although it may improve information access.
O-7
V3.1.4
O3.2.3 To achieve combined and joint integrated capabilities in the networkenabled environment, many functional communities must work together and share
information. As within a functional COI, semantic standards provide the critical basis
for inter-COI automated machine exchange and processing. Without semantic
harmonization in the overlaps, each functional COI communicates with other COIs
through lossy and expensive2 translation. Inter-COI C2 semantic harmonization will
enable functional and allied commanders to work together more effectively through
the accurate sharing and processing of planning, C2 and situational awareness
information. As shown conceptually in Figure O-3, the scope of each functional COI
and its shared semantics depends on the needs of the community and the scope of the
information that needs to be shared. Within the military, formatted messages (e.g.,
ADat-P3) are familiar. For any given military functional community, the set of
formatted messages used begins to scope the intra-COI data exchange requirements.
Each functional COI itself relies on C2, and thus, multinational C2 forms a core set of
semantics that provide a critical foundation for enabling integrated operational
capability. The MIP IEDM and its associated XML namespace provide this ready C2
core resource on which to build functional COIs.
Figure O-3. C2 Foundation for Communities of Interest
O3.2.4 Figure O-4 is a simplified view of Figure O-3 showing the MIP C2
COI and two other notional functional COIs, time sensitive targeting (TST) and global
2
Translation is expensive for a number of reasons. First it implies that the information being exchanged
has been represented differently in multiple systems/services, that means there have been multiple
engineering efforts funded to implement the same battlespace representation capability. Next there is a
need to fund the development of the translations between semantically disjoint pairs of systems/
services, and there may be many such translations required (this is the "n*n-1" problem). There are the
follow-on costs associated with maintaining each of these interfaces. Last, but not least, there are the
potential operational costs associated with misunderstanding the translated information. Extensible
Stylesheet Language Transformation (XSLT) XML technology can be used to implement both
syntactic and semantic translations, but does not change the fact that translation is expensive, to be
avoided when possible, and to be replaced by standards as the desired objective.
O-8
V3.1.4
strike (GS). It shows all possible sharing conditions and the associated semantic
overlaps. From the point of view of a functional COI, e.g., TST, a portion of MIP's
multinational C2 core semantics addresses TST’s functional COI information
exchange requirement (IERs). But clearly the MIP’s C2 core semantics may not meet
all of TST’s functional requirements. Additionally, some TST-extended semantic
requirements will be of interest to other functional COIs3. Thus, there are IERs shared
by C2 and TST, IERs shared by TST and other functional COIs (e.g., GS), and TSTunique IERs.
Figure O-4. Definition of COI Information Exchange Semantics
O3.2.5 The MIP IEDM solution anticipates the need for extensions. In fact the
history of developing the MIP IEDM has been a requirements driven process of
logical generalization and extension. Similarly, functional COI extensions built on the
C2 semantic core are practical. The C2 core has already been extended to meet
national, multinational and COI requirements4. This design and implementation
pattern of extending a shared C2 core to meet functional requirements will result in a
semantically integrated set of functional mission capabilities. For the warfighter this
creates the opportunity for improved automated information sharing and processing in
the joint and combined environment without the ambiguity and uncertainty introduced
by semantic translation. This Annex describes later how these operational and derived
implementation requirements can be supported using XML.
3
The rationale for shared extensions may be 1) that the functional COIs must exchange this
information, 2) that information is of use to both and thus, from an enterprise data management,
complexity and cost reduction point of view, should use a common representation, or both 1) and 2).
4
As an example, the Chemical, Biological, Radiological, Nuclear (CBRN) multinational COI (ATP45) has based its system and country independent logical data model directly on the JC3IEDM with
extensions. The community IER analysis resulted in the addition of some new CBRN C2 elements in
the core model as well as CBRN unique extensions. The CBRN COI uses the RDBMS XSD and
associated tools presented in this Annex.
O-9
V3.1.4
O3.3 Military Views - Business Objects
O3.3.1 The MIP IEDM is a namespace defined by aggregating multinational
C2 IERs. Selected views on the IEDM, appropriately chosen, constitute familiar
logical military messages. A database update, or query, must constitute a complete
logical military "thought" and thus be a legal IEDM view. Military messages are thus
military "views" that can also be thought of as data or business objects5. It follows that
they are exchanged between systems and services within and between COIs. These
business objects can be used to define information services, i.e. web services.
O3.3.2 Relevant to this Annex, business objects, and associated logical
military messages, can be formally represented using XML schema. Each business
object would have an associated document schema. Further, because each business
object is a view on the larger namespace schema its internal structures are already
defined and only its content bounds need to be determined. That is, a document
schema is a proper subview/subset of the namespace schema! This is shown in further
detail in section O3.4 below. Business objects may have additional COI-specific
semantics and business rules (e.g., Red_Assessment_Rpt_#1.xsd is a 24 hour enemy
summary type document and only sent by functional commanders once a day).
Document schema can be used to also validate the structure and content of XML
messages6.
O3.3.3 Business objects perform another important function. They can provide
the logical abstraction between the underlying persistent data store and the COI
systems and service layer. As shown in Figure O-5, the business object services layer
provides harmonized COI semantics and selected views as required for community
information sharing. This layering conforms to a classic software design pattern that
decouples the actual physical enterprise storage of data from the application. The
result is that applications and services can be written to the relatively stable business
object views that serve to isolate them from the actual physical data storage schema or
implementation. The business object access methods may also provide mediation if
required in order to present business objects in the preferred COI semantics and
syntax. As an example, a system may use business objects and not care if they are
stored in XML, or an RDBMS, or for that matter if the business object is populated
with OBJECT-TYPE data from an external authoritative source and OBJECT-ITEM
data from the local C2 system. This technical architecture does nothing to address the
previously discussed problems with translation. Note that metadata to support
discovery services can be generated as a view on the business object and stored
separately.
5
Business "objects" in the sense that they are collections of data, passed between entities, that have
"business" meaning. Not to be confused with programming "objects" that have both state and methods.
6
It is important to note that W3C XML Schema language is not capable of representing many types of
business rules, thus, representing business rules requires additional models or application level
methods. There are other schema languages, e.g., Schematron, and other modelling languages, e.g.,
Object Constraint Language (OCL), that can provide formal business rule modelling capability.
O-10
V3.1.4
Figure O-5. Three-tier Information Service Architecture
O3.3.4 COI business object schema, along with business rule models and
service profiles, can be used to define XML services. As an example, simple XSLTs
(with an embedded model of a stereotyped web service description) can be used to
transform a business object XSD into a web service description suitable for web
service implementation. Thus, community logical data models, community military
views, associated business rules, service models and policy models can be used in
combination to generate types of information services. In the following section a set
of useful information exchange services are identified.
O3.3.5
Military Views - Business Object Exemplar:
O3.3.5.1 A Blue Force Position (e.g., Warfighter Mission Area Position
Report) report can be easily constructed as a business object XSD based on the MIP
IEDM. The JC3IEDM view that supports this type of business object is shown below
in Figure O-6.
OBJECT-ITEM
OBJECT-TYPE
OBJECT-ITEM-LOCATION
LOCATION
OBJECT-ITEM-TYPE
OBJECT-ITEM-ALIAS
POINT
MATERIEL
LINE
SURFACE
ORGANISATION
LINE-POINT
UNIT
ABSOLUTE-POINT
POLYGON-AREA
REPORTING-DATA
VERTICAL-DISTANCE
CONTEXT
CONTEXT-ELEMENT
REPORTING-DATA-ABSOLUTE-TIMING
GEOGRAPHIC-POINT
Figure O-6. Blue Force Position JC3IEDM View
O-11
V3.1.4
O3.3.5.2 The WMAPositionReport example.xml, and associated
XSDs shown in Annex O - Appendix 7, capture the following business object pattern
shown in pseudo XML.
<ORGANIZATION>
<LOCATION LIST>
<LOCATION #1>
<LOCATION LAT&LONG>
<LOCATION DETAILS FOR ORGANIZATION, e.g., speed, heading>
</LOCATION #1>
<LOCATION #2>
<LOCATION LAT&LONG>
</LOCATION #2>
. . . . .
<LOCATION #n>
<LOCATION LAT&LONG>
</LOCATION #n>
</LOCATION LIST>
</ORGANIZATION>
O3.4 XML Use Case Overview
Inter-nation and intra-nation information exchange standards are set by
international agreement and national policy, respectively. The following section
defines XML use cases potentially suitable for both MIP multinational and national
purposes. The RDBMS and Web Services use cases form the basis for the reference
schemas presented in this Annex. Note that although some of the use case examples
call out for the application of Extensible Stylesheet Language Transformation
(XSLT), an XML technology for transforming the content and structure of XML
documents, other technical approaches may be used to accomplish these mediation/
transformation functions.
O3.4.1
Relational Data Base Management System (RDBMS)
O3.4.1.1 The use case is illustrated in Figure O-7. The purpose is to move
data between a MIP database and a non-MIP database.
National MIP System
JC3IEDM I/F
National Non-MIP System
EM
XML
(RDBMS)
EM
XSLT
Non-MIP DB I/F
Figure O-7. RDBMS Use Case
O3.4.1.2
The characteristics of this use case are:
a.
XML tag set aligns with the IEDM physical view
b.
XML documents capture the RDBMS structure of the IEDM
c.
XML documents have flat structure
d.
Referential integrity & business rules are ensured by the RDBMS or at
the application level
e.
National implementers are responsible for any required XSLT
O-12
V3.1.4
f.
XML schema definition does not need to be partitioned due to low
complexity.
O3.4.2
XML Exchange Mechanism (XEM)
O3.4.2.1 The use case is illustrated in Figure O-8. The potential application
is to base the MIP Common Interface (MCI) on XML exchanges directly related to
the physical schema of the MIP IEDM rather than formatted text messages. Because
both the sender and the receiver share the same IEDM there is no need to invoke any
transformations, as in the Use Case discussed in the preceding section.
MIP Common Interface (MCI)
XML
EM
EM
MIP Common Interface (MCI)
(RDBMS)
Figure O-8. XEM Use Case
O3.4.2.2
a.
MIP Common Interface with data sets based on XML
b.
XML tag set aligns with the IEDM Physical view
c.
XML documents capture the RDBMS structure of the IEDM
d.
e.
Referential integrity & business rules are ensured by the RDBMS or at
the application level
O3.4.3
Web Services/Object-Oriented (WS/OO)
is to provide information exchange services where the exchange payload has an object
oriented pattern. Service-specific schemas – derived from the general MIP Reference
WS/OO schema – define associated service capabilities and use and clarify their
semantics. The WS/OO XSD object oriented payload pattern is especially convenient
for web services, but, does not require a web services implementation, i.e., can be
used with other information exchange mechanisms and use cases.
MIP-capable Service
JC3IEDM
XSLT
Non-MIP system
Web
Services (EM)
XML
(OO)
XSLT
Figure O-9. Web Services/Object-Oriented Use Case
O3.4.3.2
a.
XML tag set is derived from the IEDM logical view
b.
XML documents capture the IEDM in an Object Oriented structure
O-13
V3.1.4
c.
XML documents have a nested structure
d.
XML schema ensures referential integrity and enforces some business
rules
e.
XML documents do not prescribe a MIP-compliant relational DB for
storage
O3.4.4
COI Business Object Exchange (WS/OO)
is to provide information exchange between COI member systems/services based on
community-defined business objects. Tailored schemas – derived from the general
MIP Reference WS/OO schema – for the business objects both facilitate their use and
clarify their semantics.
XML
(OO,
RDBMS)
COI System 1
System 1
Internal Model
XSLT
COI JC3IEDM XML
Business Object
Exchange
Mechanism
XML
(OO,
RDBMS)
COI System n
System n
Internal Model
XSLT
Figure O-10. Business Object Exchange Use Case
O3.4.4.2
a.
WS/OO XSD used to define community business objects expressed as
document XSD.
b.
XML documents capture the IEDM in an Object Oriented structure
c.
XML documents have a nested structure
d.
XML schema ensures referential integrity and enforces some business
rules
e.
XML documents do not prescribe a MIP-compliant relational DB for
storage
O3.4.5
Other Tactical Communications Interfaces
is to support tactical communication interfaces. Note that both the RDBMS and the
WS/OO schemas can be used here to control the structure and content of the instance
XML documents exchanged.
Alt Exchange
Standard/System
JC3IEDM I/F
EM1
XML
(RDBMS,
OO)
EM1
Transform
Technology
EM2
Non-MIP
Exchange
Figure O-11. Tactical Communications Interface Use Case
O-14
V3.1.4
O3.4.5.2
a.
Addresses
tactical
alternative
exchange
standards/system
communication interfaces: ADatP3, USMTF, Tactical Data Links (e.g.,
Link 16, Link 11, Link 22 and associated STANAGs)
b.
Transformation Technology: XSLT, others
c.
Typically this exchange will not be lossless
O3.4.6
Mediation
is to support backward and forward compatibility. Note that both the RDBMS and the
WS/OO schemas can be used here to validate the XSLT-based conversions from old
to new, or new to old IEDM specifications prior to loading the data into the target
database.
C2IEDM
EM1
XML
(RDBMS,
OO)
EM1
Mediation
Service or
XSLT
EM2
XML
(RDBMS,
OO)
EM2
JC3IEDM
Figure O-12. Mediation Use Case
O3.4.6.2
a.
Provides a service to mediate between different versions of the IEDM.
b.
Supports automated generation of the mediation services to solve
interoperability issues caused by model version changes.
c.
Uses Transformation Technology: XSLT, others
O4. XSD DESIGN OVERVIEW
O4.1 The MIP Common Interface (MCI) defines two types of Information
Exchange Mechanisms (IEMs): (a) the Data Exchange Mechanism (DEM), and (b)
the Message Exchange Mechanism (MEM). DEM uses database replication to
exchange information. The MEM, in contrast, provides for the exchange of
information using ADatP-3 formatted messages.
O4.2 The Relational Data Base Management Systems (RDBMS) and XML
Exchange Mechanism (XEM) Use Cases can be thought of as being “DEM-like”.
They use XML instance documents that reflect the entity-relationship (ER) nature of
the MIP IEDM database table structures. They are supported by the RDBMS XSD.
O4.3 The Web Services/Object-Oriented (WS/OO) Use Cases can be
thought of as being “MEM-like”. They are supported by the WS/OO XSD. It uses
XML instance documents that present the MIP IEDM in hierarchical, nested
structures that can be viewed as the analogue of standard messages. However, the
O-15
V3.1.4
MEM-like nature of the WS/OO does not preclude the use of the publish/subscribe
paradigm.
O4.4 Design considerations and the transformation rules for the two MIP
Reference XSDs, namely the RDBMS XSD and the WS/OO XSD, are described in
the appendices to this Annex. These transformation rules are generic. It is recognized
that an optimal XSD design (i.e., transformation choices) can only be realized in the
context of a specific use case. However, by choosing a generic approach one
minimizes the impact of IEDM changes across versions and facilitates the automation
of the XSD generation process.
O4.5 The two alternative representations are equivalent in terms of their
ability to convey information represented in the MIP IEDM. These XML schemas are
both derived under different transformation rules from the same reference entityrelationship model, i.e., the MIP IEDM. General considerations applied in developing
these XSDs include:
a.
Automatically Generated: The XML schemas should be automatically
derivable from the MIP Entity-Relationship model to ensure correctness
and minimize their production and maintenance cost.
b.
Syntactic Transformations Only: The procedures for generating the
XML schemas should use only syntactic transformations. This enables
the specification of transformation patterns that are independent of the
semantics in any given version of the MIP IEDM.
O4.6 As an overview to the appendices, two instance XML document
fragments, compliant with the RDBMS/XEM and WS/OO XML schemas, are shown
below:
a.
In Figure O-13 information regarding West Minefield in an instance
XML document, valid with respect to the RDBMS XSD, is distributed
across multiple “tables”. The same information in the WS/OO instance
document has been aggregated by inheritance into the MinefieldLand
element.
b.
In Figure O-13 and Figure O-14, the primary and foreign keys (e.g.,
<OBJ_ITEM_ID>, <MNFLD_LAND_ID> respectively) used for subtyping in the RDBMS/XEM instance document have been replaced by
an Object ID (OID) that applies to all nested/aggregated information
elements that have been inherited in the WS/OO instance document. To
simplify these figures the OID typing construct is not shown, neither is
the obligatory <CreatorId> nor the optional <UpdateSequenceNo>,
which follow the OID specification.
c.
In Figure O-14, nested structures create associations between
independent elements.
O-16
V3.1.4
RDBMS instance document fragment
WS/OO instance document fragment
<?xml version="1.0" encoding= "UTF8 "?>
<JC3IEDM_RDBMS>
<?xml version="1.0" encoding="UTF8"?>
<JC3IEDM>
Object ID
<OBJ_TYPE_TBL>
<MinefieldLand>
<OBJ_TYPE>
<OBJ_TYPE_ID>343545</OBJ_TYPE_ID>
<OID>223432</OID>
<CAT_CODE>FA</CAT_CODE>
<NameText>West Minefield</NameText>
<DUMMY_IND_CODE>NO</DUMMY_IND_CODE>
<ObjectItemTypeInObjectItem>
<NAME_TXT>LandMinefield</NAME_TXT>
<ObjectTypeRef>
</OBJ_TYPE>
</OBJ_TYPE_TBL>
<OID>343545</OID>
</ObjectTypeRef>
<ObjectItemType>
<ReportingDataRef>
<OID>RPTD001</OID>
</ReportingDataRef>
</ObjectItemType>
</ ObjectItemTypeInObjectItem >
<StatusList>…</StatusList>
<LengthDimension>300</LengthDimension>
<WidthDimension>105</WidthDimension>
<OBJ_ITEM_TBL>
Primary Key
<OBJ_ITEM>
<OBJ_ITEM_ID>223432</OBJ_ITEM_ID>
<NAME_TXT>West Minefield</NAME_TXT>
</OBJ_ITEM>
</OBJ_ITEM_TBL>
<FAC_TBL>
Foreign Key
<FAC>
<FAC_ID>223432</FAC_ID>
<CAT_CODE>MILOBS</CAT_CODE>
<LENGTH_DIM>300.000</LENGTH_DIM>
<WIDTH_DIM>105.000</WIDTH_DIM>
</FAC>
</FAC_TBL>
<MineSpacingDimension>10</MineSpacingDime
nsion>
<DepthPlacementCode>MIXED
</DepthPlacementCode>
<FunctionCode>NUISNC</FunctionCode>
<PatternCode>REGTHK</PatternCode>
<MIL_OBS_TBL>
<MIL_OBS>
Foreign Key
<MIL_OBS_ID>223432</MIL_OBS_ID>
<CAT_CODE>MNFLD</CAT_CODE>
</MIL_OBS>
</MIL_OBS_TBL>
<PersistenceCode>REMOTE</PersistenceCode>
<StoppingPowerCode>MEDIUM
</StoppingPowerCode>
</MinefieldLand>
<MNFLD_TBL>
<MNFLD>
Foreign Key
<MNFLD_ID>223432</MNFLD_ID>
<CAT_CODE>MNFLND</CAT_CODE>
<MINE_SPACING_DIM>10.000
</MINE_SPACING_DIM>
</MNFLD>
</MNFLD_TBL>
<MilitaryObstacleType>
<OID>343545</OID>
<DummyIndicatorCode>NO</DummyIndicatorCo
de>
<NameText>LandMinefield</NameText>
<CategoryCode>MINEFD</CategoryCode>
</MilitaryObstacleType>
<MNFLD_LAND_TBL>
<MNFLD_LAND>
<MNFLD_LAND_ID>223432</MNFLD_LAND_ID>
Foreign Key
<DEPTH_PLCMNT_CODE>MIXED
</DEPTH_PLCMNT_CODE>
<FUNC_CODE>NUISNC</FUNC_CODE>
<PATTERN_CODE>REGTHK</PATTERN_CODE>
<PERSISTENCE_CODE>REMOTE
</PERSISTENCE_CODE>
<STOPPING_POWER_CODE>MEDIUM
</STOPPING_POWER_CODE>
</MNFLD_LAND>
</MNFLD_LAND_TBL>
</JC3IEDM>
</JC3IEDM_RDBMS>
Figure O-13. Minefield Establishment Report
Distributed (ER) vs Aggregated (WS/OO) Information
O-17
V3.1.4
ER instance document fragment
WS/OO instance document fragment
<?xml version= »1.0 » encoding="UTF8" ?>
<JC3IEDM_RDBMS>
<?xml version="1.0" encoding="UTF8" ?>
<JC3IEDM>
<OBJ_ITEM_TBL>
Primary Key
<OBJ_ITEM>
<NAME_TXT> West Minefield </NAME_TXT>
</OBJ_ITEM>
Nested
</OBJ_ITEM_TBL>
structure
Flat
Structure
<OBJ_ITEM_STAT_TBL>
Foreign Key
<OBJ_ITEM_STAT>
<OBJ_ITEM_STAT_IX>1</OBJ_ITEM_STAT_IX>
<HSTLY_CODE>FR</HSTLY_CODE>
<RPTD_ID>222701</RPTD_ID>
</OBJ_ITEM_STAT>
</OBJ_ITEM_STAT_TBL>
Object ID
<MinefieldLand>
<OID>223432</OID>
< ObjectItemTypeInObjectItem>
<ObjectTypeRef>
<OID>343545</OID>
</ObjectTypeRef>
<ObjectItemType>
<ReportingDataRef>
<OID>RPTD001</OID>
</ReportingDataRef>
</ObjectItemType>
</ ObjectItemTypeInObjectItem>
Association by
<StatusList>
<Status xsi:type=”FacilityStatus”>
<HostilityCode>FR</HostilityCode>
<ReportingData
xsi:type=”ReportingDataAbsoluteTiming”>
<OID>222701</OID>
<CategoryCode>REP</CategoryCode>
<CredibilityCode>RPTFCT</CredibilityCode>
<ReportingDatetime>20031102094900.000
</ReportingDatetime>
<ReportingOrganisationRef>
<OID>OI6</OID>
</ReportingOrganisationRef>
<EntityCategoryCode>OISTAT
</EntityCategoryCode>
<EffectiveStartDatetime>20031102094500.000
</EffectiveStartDatetime>
</ReportingData>
</Status>
</ StatusList>
</MinefieldLand>
<RPTD_TBL>
<RPTD>
<ACC_CODE>1</ACC_CODE>
<CAT_CODE>REP</CAT_CODE>
<CREDIBILITY_CODE>RPTFCT
</CREDIBILITY_CODE>
<REP_DTTM>20031102094900.000</REP_DTTM>
<SOURCE_TYPE_CODE />
<TIMING_CAT_CODE>RDABST
</TIMING_CAT_CODE>
<REP_ORG_ID>5</REP_ORG_ID>
<ENT_CAT_CODE>OISTAT</ENT_CAT_CODE>
</RPTD>
</RPTD_TBL>
<RPTD_ABS_TIMING_TBL>
<RPTD_ABS_TIMING>
<RPTD_ABS_TIMING_RPTD_ID>222701
</RPTD_ABS_TIMING_RPTD_ID>
<EFFCTV_START_DTTM>20031102094500.000
</EFFCTV_START_DTTM>
</RPTD_ABS_TIMING>
</RPTD_ABS_TIMING_TBL>
Association via key
<OBJ_ITEM_TYPE_TBL>
<MilitaryObstacleType>
reference
<OBJ_ITEM_TYPE>
<OID>343545</OID>
<DummyIndicatorCode>NO</DummyIndicatorCode>
<NameText>LandMinefield</NameText>
<OBJ_ITEM_TYPE_IX>1</OBJ_ITEM_TYPE_IX>
<CategoryCode>MINEFD</CategoryCode>
</MilitaryObstacleType>
</OBJ_ITEM_TYPE>
</OBJ_ITEM_TYPE_TBL>
</JC3IEDM>
<OBJ_TYPE_TBL>
<OBJ_TYPE>
<NAME_TXT> LandMinefield </NAME_TXT>
</OBJ_TYPE>
</OBJ_TYPE_TBL>
…
</JC3IEDM_RDBMS>
Figure O-14. Minefield Status Report
Object IDs Supplant Keys and Associations Made through Nested References
O-18
V3.1.4
O4.7 Regardless of the XSD chosen, instance XML documents once passed
can be easily processed and rendered for the user (e.g., in a browser) using XSLT and
other techniques. This enables information exchanges with non-traditional MIP clients
(e.g., non-governmental organizations (NGOs)) that might only have connectivity to a
server via browsers on laptops. Emerging XML compression standards make this a
viable option, and will ensure that XML-based exchanges can be effectively used with
even limited network performance.
O5. SCHEMA DESIGN CONSIDERATIONS
O5.1 RDBMS XSD
O5.1.1
Introduction
O5.1.1.1 As noted in the preceding sections the RDBMS XSD supports a
DEM-like data exchange mechanism exemplified in two Use Cases, namely the
RDBMS Use Case (see Figure O-7 above) and the XEM Use Case (see Figure O-8
above). The only difference between these two use cases is that in the former one of
the systems is not MIP IEDM-compliant, and, therefore requires a transformation step
to either filter outgoing data or realign the incoming data with the internal semantics
of the non-MIP system. The underlying logic of the RDBMS use case is familiar to
many nations that maintain an internal database design optimised for national
applications and subsequently map their schema to the MIP IEDM in order to send
and receive data in conformance with the MIP Solution. Once a non-MIP system
implements these transformation steps – using a software interface or using an
external service – it is operationally indistinguishable from a MIP system. Therefore,
this section concentrates on the requirements associated with the subsequent data
exchange step, represented by the XEM Use Case.
O5.1.1.2 The RDBMS XSD will provide a DEM-like capability, albeit using
XML syntax. Furthermore, instance XML documents, once passed, easily can be
further processed with other XML technologies.
O5.1.2 Entity-Relationship Use Case: General Considerations
O5.1.2.1
a.
b.
The following assumptions underlie the RDBMS schema design:
Both the sender/receiver of the instance XML documents:
(1)
Maintain a MIP-compliant RDBMS
(2)
Rely on the RDBMS engine or an application within
the system to enforce referential integrity and internal
consistency. Therefore, the XML documents do not
need to contain this type of information
(3)
Are applications, not people, because the XML tag
naming conventions are optimised for the machine-tomachine interface
Communication procedures preserve referential integrity:
O-19
V3.1.4
(1)
O5.1.3
Replication-based methods preserve database keys
Entity-Relationship Use Case: Specific Considerations
O5.1.3.1 The RDBMS XSD is built according to the following set of
syntactic transformation rules:
a. For every entity specified in the logical MIP IEDM there is a specification
in the physical schema that corresponds to the RDBMS table. This specification is the
basis for the XML elements as indicated below.
b. Figure O-15 shows an example of this correspondence. The entity
ACTION in the logical view is represented in the physical view as the table ACT.
From this physical schema one can implement the table ACT in a database.
Figure O-15. XML Representation of Physical Tables and Columns
c. This generic syntactic transformation provides the following rules for the
generation of the XML representation:
(1)
For each physical table there is an XML element. The
name of the element is formed by appending to the physical table name
the string “_TBL”, e.g., <ACT_TBL>.
O-20
V3.1.4
(2)
For each record in the physical table there is an XML
element. The name of the element is identical with the name of the
physical table name, e.g., <ACT>.
(3)
For each column in the physical table there is an XML
element. The names of these elements are identical with the physical
column names, e.g., <ACT_ID>, <CAT_CODE>.
(4)
The RDBMS XSD does not use XML tag attributes. The
values of the columns in a physical table are represented as content of
the corresponding column XML elements.
(5)
Every instance XML document that conforms to the
RDBMS schema has the same root tag. The name of the root tag is
chosen to make explicit its type (physical, RDBMS-related, as opposed
to WS/OO), and the model whence it is built.
O5.2 WEB SERVICE/OBJECT-ORIENTED SCHEMA
O5.2.1 Introduction
O5.2.1.1 The Web Services/Object-Oriented (WS/OO) Use Case is defined
as an object-oriented view of the MIP data model. Its XSD presents a logical tree
structure. For ease of processing, the values and ranges of simple types comply with
the physical IEDM specifications. The resulting nested structure closely matches the
natural OO paradigm with regard to inheritance, object referencing,
composition/aggregation, and associations. Instance XML documents in this use case
are “denormalised” because of the OO design patterns. They are machine-readable but
can also be expected to be read by people. This is in contrast to the RDBMS-based
exchanges which are highly normalized and less easily understood by a person (e.g.,
relationships must be manually traced through the use of keys in contrast to the
WS/OO nesting of related information elements).
O5.2.1.2 The WS/OO schema is suitable for different kinds of
communication. For example, it would provide a MEM-like capability, albeit using
XML syntax. Like XEM, instance XML documents once passed can be easily
processed and rendered for the user using XSLT or other techniques. Again, this will
enable information exchange with thin non-database capable clients with limited
networking bandwidth.
O5.2.2 WS/OO Use Case General Considerations
O5.2.2.1
The following assumptions underlie the WS/OO XSD schema
design:
a.
Senders and receivers of WS/OO instance XML documents may be:
(1)
Systems that do not necessarily store their data in a
MIP-compliant RDBMS,
(2)
Systems that do not use the MIP DEM for data
exchange,
O-21
V3.1.4
b.
(3)
Systems that rely on XSD validation to enforce
business rules,
(4)
Gateways that mediate between MIP and Non-MIPcompliant systems,
(5)
People.
Communication procedures:
(1)
Instance documents may or may not be referentially
complete. The constraints of the WS/OO schema
ensure internal referential integrity.
(2)
Instance XML documents support “request-andanswer” exchanges. Referenced information must be
accessible but not necessarily embedded in the
instance document. The referencing mechanism
supports this way of communication by relaxing the
referential integrity constraints.
(3)
WS/OO instance documents when imported into a
MIP-compliant RDBMS may require the generation of
new RDBMS keys. Moreover, external OIDs must be
associated with RDBMS keys and RDBMS keys must
be preserved in an Object ID when generating a
WS/OO instance document.
O5.2.2.2 Figure O-16 shows the identifying relationship transformation
pattern implemented in the WS/OO XSD. The related appendix describes the
complete design rationale for a reference WS/OO XSD.
O-22
V3.1.4
Figure O-16 Identifying Relationship
O5.3 COIs Using JC3IEDM as a Foundation for COI BO
O5.3.1 WS/OO Use Case General Considerations
O5.3.1.1 Functional COIs can extend the MIP IEDM as a basis for a COI
logical data model. The MIP XSD tools enable the generation of COI namespace
XSD, and the subsequent definition of COI business objects. The ideal situation is for
the functional COI namespace to include the MIP COI namespace, reusing MIP
qualified tags (e.g., <JC3IEDM:ObjectItemType>) where there is a need for C2
semantics and functional COI-specific tags where there has been a need for extensions
(e.g., <MINE:AirMineFieldType>). If MIP JC3IEDM elements are redefined in the
functional community namespace (e.g., <MINE:ObjectItemType>) then additional
measures must be taken to document the semantic association (e.g.,
<JC3IEDM:ObjectItemType> "is the same as" <Mine:ObjectItemType>). This is
possible to do at the cost of additional processing and complexity. The following
additional assumptions underlie the WS/OO XSD schema design use for functional
COI use:
a.
b.
Senders and receivers of WS/OO instance XML documents may be:
(1)
Systems or services that are members of the same
functional COI.
(2)
Systems or services that are members of overlapping
but different functional COIs.
(3)
Functional COIs with XSDs that have documented the
functional COI XSD to MIP COI XSD mapping in a
form that supports automated processing and
transformation of community instance documents.
Communication procedures:
O-23
V3.1.4
(1)
Functional COI business objects (data) may be
exchanged through a web service capable of
supporting both COI XSD/business objects services.
O6. APPLICATION USE CONSIDERATIONS
A general discussion regarding the use of XML technologies in application
development is beyond the scope of this document. However, there are a number of
discussion points that merit attention.
O6.1 Transactions
O6.1.1 The referential integrity and completeness required by the MIP IEDM
has implications for the design of XML schemas and associated web services. In the
design patterns defined for both the RDBMS and WS/OO XSDs it is assumed that
instance documents could reference external information. This ensures that every
document need not contain all information and, accordingly, that periodic messages
(e.g., position report updates) need only contain the information that has changed.
O6.1.2 The external information reference capability also creates a
requirement that a web service should be able to provide more information on request.
For example, a Web client may request information on what units are in a given
geographic region. In response, the client receives a report that mentions unit Bravo is
at location Alpha as of time Tango. The user subsequently wants to know Bravo’s
current unit status. Thus, the user must be able to refer to Bravo’s identifier in order to
query for additional details. This just in time, interactive, pull for relevant data is
consistent with Web services concepts and complementary to the traditional MIP
smart push architecture.
O6.2 Validation
O6.2.1 As previously mentioned, W3C XML Schema language enables
machine validation of message structure and some types of content. However, it is not
capable of representing many types of JC3IEDM business rules regarding document
content. For example, content combination restrictions are expressed neither in the
WS/OO nor in the RDBMS XSDs; further, key content correctness cannot be checked
by the RDBMS schema. Thus, the necessary structure and content analysis required to
ensure that an XML instance document is correct cannot be accomplished by
document XSD validation alone. The business rule validation must be provided by
some other mechanism either during document construction or as a service.
O6.2.2 The JC3IEDM business rules can be represented using various
methods that provide for the formal expression of rules. It is possible to see these
rules implemented within a class, an application or as an external formal model used
by a rule engine. A prototype implementation of the business rules in Object
Constraint Language (OCL), part of the Unified Modeling Language (UML) 2.0
specification, has been developed and may at a future date become part of the MIP
JC3IEDM reference package. To date all business rule types that do not require any
O-24
V3.1.4
non-OCL operators have been successfully captured using OCL notation. For the
rules that require some type of geometric computation there is a draft proposal
whereby the expression of the OCL rules is coupled to the class methods that can
support an extended set of operators such as sin() and cos(). Evaluation of these
rules can be accomplished through implementation of rule engines or services that are
called during rule evaluation.
O6.3 XML Naming and Design Rules
O6.3.1
Rationale for XML Guidelines
O6.3.1.1 Fundamental to achieving multinational and joint network enabled
capability (net-centric operations) is a common structure and language for information
handling. At the international, multinational and national levels Naming and Design
Rules (NDR) are being developed. Their intent is to facilitate the discovery and use of
common data elements, and to provide additional rigor to the XML standards in order
to maximize interoperability and enhance supportability.
O6.3.1.2 The use of NATO Guidelines for XML Naming and Design
(GXND), which are based on the ISO 11179 and 15000-5 standards, is not mandatory
for the use of XML itself. However, XML will not support interoperability
automatically. Due to differences in both the syntax and the business context,
information cannot be exchanged without integration costs. Today there are hundreds
of XML “dialects” but limited improved interoperability. While XML provides new
tools for improving point-to-point translations the long-term objective and “big win”
comes through semantic harmonization. Guidelines for XML Naming and Design can
form a basis for coordinated XML schema design. In general, the application of the
GXND is expected to help with NATO data management and harmonization through
the standardization of XML vocabulary.
O6.3.2
GXND Compliance
The application of GXND to MIP XML XSD has been done where practical.
The RDBMS and WS/OO partial/practical voluntary compliance with the draft
GXND is documented in an Excel Spreadsheet on the MIP web page.
O6.4 JC3IEDM Business Object Specification
O6.4.1 The current WS/OO and RDBMS XSD elements are not all globally
defined. As a result XSD complex type definitions cannot be restricted or extended
while retaining a semantic reference to the JC3IEDM namespace. Making all
elements global has been considered but not implemented in this version of the
JC3IEDM reference XSDs. Other factors and methods need further assessment before
implementing this type of significant change.
O6.4.2 An alternative to complex type restrictions may be the use of business
rules applicable to specific business objects. For example, a PersonStatusReport
object could be specified as a more general ObjectItemStatusReport with a specific
business rule that requires the ObjectItemType content to be restricted to a
PersonType specification.
O-25
V3.1.4
O6.4.3 A functional community that reuses and extends the JC3IEDM
semantics would ideally use data modelling tools and then generate a community
namespace XSD. The community XSD would ideally include JC3IEDM namespacequalified elements as well as the community-specific qualified element. Current XSD
generation tools create a single JC3 community namespace specification. Future
versions of the tools may support generating a community-specific namespace (i.e.,
specified restrictions, extensions and additions) and include the JC3IEDM namespace.
O7. TOOLS OVERVIEW
O7.1 A number of tools and techniques have been developed and applied to
generate the reference materials referred to in this annex. Reference XSDs are
generated using open source tools that process equivalent renderings of the MIP
IEDM metadata, e.g., MIRD, ERwin XML, XMI. These tools and the XML products
that they generate are available at the MIP homepage. The tools are provided under
the BSD Open Source License.
O7.2
A list of available tools is as follows:
a.
A Java tool that enables the user to generate the RDBMS and WS/OO
XML schemas and the Java classes automatically from the ERwin XML
file of the MIP Information Exchange Data Model.
b.
A SAX-based XML parser for the WS/OO XSD that validates instance
XML documents and generates corresponding Java objects. In
combination with the model-specific Java classes, the XML parser
supports incremental updates.
c.
Other XML XSD generation tools, that use a developmental UML
Platform Independent Model of the JC3IEDM, have been developed but
are not currently approved MIP products.
O8. DELIVERY
The products of the MIP XML WP will be published on the XML page at the
MIP member web site. The MIP Data Modelling Working Group (DMWG) and
Programme Management Group (PMG) will approve public release of selected
products (e.g., XSDs) to the MIP public web page and to other international bodies.
MIP intends to make submissions to the NATO XML Registry. Nations may use
these products as they deem appropriate in their national efforts.
O9. ONGOING XML COLLABORATION
O9.1 The XML products described in this Annex present a reference
baseline suitable for supporting a broad scope of XML application and service
development work. They are being published to the public space to encourage use of
the MIP IEDM semantics and to serve as a catalyst for MIP capability development
using XML. From this public discourse alternative XSDs, XSLTs, RDBMS support
tools, web service components, XML document schemas, demonstration exemplars,
etc. will emerge. The XML WP will have its own specific continuing work plan and
products to contribute. The MIP XML WP will periodically elect to recommend to
O-26
V3.1.4
DMWG and PMG additional reference XML capabilities developed outside the MIP
XML WP.
O9.2 The explicit purpose of MIP continuing with the development of XML
reference capabilities is not to replace or dictate national development efforts, but
rather, to significantly lower the barrier for those interested in learning and implement
MIP-capable XML services and applications.
O-27
V3.1.4
ANNEX O, APPENDIX 1
ENTITY-RELATIONSHIP XSD DESIGN DOCUMENT
O-1.1 INTRODUCTION
O-1.1.1 The aim of the Multilateral Interoperability Programme (MIP) is to
enable interoperability among multinational military commanders. This requires
appropriate and adequate information exchange between national C2 systems
supporting the multinational operations. To enable the exchange of (structured) datain-context the MIP has defined an information exchange data model (IEDM) and
supporting information exchange mechanisms (IEM). These capabilities are well
documented, mature, and agreed to by 26 nations and institutions. The Data Exchange
Mechanism (DEM) is an RDBMS-based IEM. It enables data base replication through
the MIP Communications Interface (MCI). Similarly, the Message Exchange
Mechanism (MEM) is an ADatP3 message-based IEM that enables message passing
through the MCI.
O-1.1.2 The DEM is “preferred” over the MEM by most countries as a
more efficient and complete capability that is not limited to legacy text format
messages. As the popularity of the MEM has decreased, the utility and popularity of
Extensible Mark-up Language (XML) for creating and sharing structured documents
has been increasing. In some countries the use of XML is being mandated for national
information exchanges and web services. XML provides syntax for specifying and
creating structured documents. This alone does not enable or improve community
interoperability. Essential to interoperability is a shared community understanding of
the XML tags that define a Namespace. Namespace tags must capture community
concepts, terminology, and semantics. The MIP IEDM effectively serves the same
purpose as the XML Namespace. More importantly, the IEDM can be used to define
an XML Namespace, and thus, to immediately provide a basis for XML-based MIP
information exchange. The XML Namespace is specified by means of an XML
Schema Definition (XSD). Similarly, an XML instance document is specified and
validated by means of a specific XSD.
O-1.2 THE MIP XML EXCHANGE MECHANISM USE CASES AND THEIR
SCHEMA REQUIREMENTS
O-1.2.1 Six types of XML Use Cases are identified in the Annex main
document. Two of these are candidates for an XSD that preserves the natural entityrelationship structure of the underlying data model, specifically:
a.
XML Exchange Mechanism (exchange among MIP data bases via
XML), and
b.
RDBMS (exchange between a MIP data and a non-MIP data base via
XML).
O-1-1
V3.1.4
It should be noted that although the primary focus of these use cases is RDBMS-toRDBMS data exchange the associated XML can be processed and rendered on a
browser or processed by other type applications.
O-1.2.2 The main difference between the XEM and the RDBMS Use Cases
is that in the latter there will be a transformation step to either filter data or realign the
incoming data with the internal semantics of the non-MIP system. Essentially, this is
the current situation within the MIP community, where the nations are free to
maintain their national systems and need only send and receive data in conformance
with the MIP IEDM standard. Whereas now the exchanges occur via DEM or MEM,
the use of XML would make it possible to produce a network centric solution where
C2 data is published and the users subscribe to receive what they need.
O-1.2.3 Once a non-MIP system implements the transformation steps
needed to send and receive data in conformance with the MIP standards the target
non-MIP RDBMS is operationally indistinguishable from a MIP database. Therefore,
this document concentrates on the XEM Use Case requirements. The XEM Use Case
is shown in Figure O-17 and the RDBMS Use Case is shown in Figure O-18.
MIP Communication Interface
(MCI)
EM
XML
EM
(RDBMS)
MIP Communication Interface
(MCI)
Utility: MIP Communications Interface (MCI) using XML
•
MIP Communications Interface with XML “PDUs”
•
XML tag set aligns with JC3IEDM Physical view
•
XSD captures the RDBMS structure of the JC3IEDM
•
o
o
XML encoding instead of PDUs
Referential integrity & business rule validation ensured by RDBMS
Figure O-17. Use Case for the MIP XML Exchange Mechanism
O-1-2
V3.1.4
National MIP System
JC3IEDM I/F
National Non-MIP System
EM
XML
(RDBMS)
EM
XSLT
Non-MIP DB I/F
Utility: Move data between MIP DB and Non-MIP DB
•
•
XML tag set aligns with JC3IEDM Physical view
XSD captures the RDBMS structure of the JC3IEDM
o
•
Referential integrity & business rule validation ensured by RDBMS
•
National implementer is responsible for XSLT
•
XSD does not need to be partitioned due to low complexity
Figure O-18. Use Case for MIP DB to Non-MIP DB XML Exchange Mechanism
O-1.3 XEM USE CASE GENERAL CONSIDERATIONS
Since the focus of this document is an XML schema for the MIP data model,
the choice of transmission protocols (Web Service: SOAP; MIP: DEM; etc.) is not
relevant. The following factors have been considered as part of the RDBMS schema
design:
a.
b.
c.
Both the sender/receiver of the instance XML documents:
(1)
Maintain a MIP-compliant RDBMS
(2)
Are applications, not persons
Communication procedures preserve referential integrity:
(1)
Replication-based methods preserve database keys
(2)
Message/Document-based
external information
methods
can
refer
to
The applicable XML Standards are WWW Consortium XSD
Recommendations.
O-1.3.1 Requirements Derived from Sender/Receiver of XML Message
O-1.3.1.1 The XEM Use Case presupposes that all communicating systems
are MIP-compliant C2ISs. Under that scenario an XML schema is required that
allows for a simple mapping to and from the physical schema implemented in the
RDBMS resident within the C2ISs. Furthermore, one can assume that referential
integrity is ensured by the RDBMS in the MIP-compliant systems, and that,
furthermore, it is not necessary to perform a thorough and, potentially, timeconsuming XML validation before incoming data is loaded into the database.
O-1.3.1.2 From the above it also follows that an XML tag naming convention
can be adopted that is optimal for the machine-to-machine interface. If one also wants
to allow a human operator to perform spot checks, a direct XML tag transformation
from the physical to the logical tag names can be performed using XSLT for ease of
O-1-3
V3.1.4
readability and comprehension. Accordingly, the RDBMS XML tag names are
derived from the names of the physical tables and columns of the MIP IEDM.
O-1.3.2 Requirements Derived from Communication Procedures
O-1.3.2.1 In a replication-based scenario, such as the DEM, an initial
RDBMS data load must first be established. Information updates are then transmitted.
Each update may refer to information transmitted earlier. For example, for an instance
of OBJECT-ITEM it is valid to send only a status update provided that the appropriate
defining information on that instance has been transmitted before. Thus, replicationbased communication requires a mechanism to refer to previously transmitted data.
Ultimately, this means that for information exchanges that include an RDMBS-based
system the MIP data model synthetic keys must be preserved. Specifically, data
forwarding using XML documents will not work between MIP systems if all the
mandatory MIP keys are not exchanged.
O-1.3.2.2 When XML-based message communications are used to exchange
updates it is required that the XML documents be referentially complete, and thus
must be able to refer to information defined outside the current document. XML
message-based exchanges are appropriate when one communication partner is a nonMIP non-RDBMS-based system, when full synchronization is not required, and when
the dynamic request can be made for external information.
O-1.3.3 Applicable XML Standards
O-1.3.3.1 The valid tags and structure of instance XML documents are
specified formally by means of a schema which itself is specified in a schema
language. There are many different schema languages available with varying degrees
of expressiveness and complexity. Currently, the most widely used schema language
is the XML Schema Definition (XSD) and this is the one adopted for the MIP
RDBMS XML schema. The XSD specification is standardised by the World Wide
Web Consortium (W3C) and is supported by virtually all XML tool vendors. It is
based on an object-oriented model.
O-1.3.3.2 Additionally, there are multiple standards for XML naming and
design rules (NDRs). As noted above, since the main goal is to move data among MIP
C2ISs the optimal choice is to align the XML tags with the physical table and column
names, because that is the way in which most commercial RDBMSs support XMLbased I/O operations. Transformations using XSLT to recast the physical names into
logical names, and visa versa, are provided in materials.
O-1.4 GENERAL MIP RDBMS XML CONSIDERATIONS
O-1.4.1 An XEM would enable information exchange with clients (e.g.,
non-governmental organizations (NGOs)) that have little more than laptops,
connectivity to a server, and a browser. Supporting this capability are the emerging
XML compression standards that will ensure that XML-based exchanges can be
effectively used even in limited bandwidth and performance networks. An RDBMS
XSD should be:
O-1-4
V3.1.4
a.
Flat: Normalised relational databases strive to eliminate any kind of
data nesting. The linkage among the data classes is accomplished via
foreign keys. Therefore, a flat XML structure for the RDBMS XSD is
the optimal match.
b.
Monolithic: Although NDRs recommend modular XSDs to improve
maintenance, design and reuse, the specialised purpose of the RDBMS
XSD would warrant having a self-contained specification that handles
all possible combinations of tables, rather than specialised
combinations, such as those needed for an object oriented kind of
message.
c.
Community of Interest (COI) Driven: The MIP IEDM is systemindependent. It provides a COI (i.e., Command and Control) generic
view of information exchange requirements. In the same way, the
RDBMS XSD should provide a system-neutral representation suited for
exchange.
d.
Conformant with the Physical Model: The MIP IEDM physical schema
is specifically designed for an RDBMS implementation and, therefore,
the RDBMS XSD generation and maintenance can be more readily
accomplished when basing the specification on the MIP IEDM physical
model.
e.
Normalized: RDBMS-based exchanges are highly normalised as are the
source and target databases that are meant to exchange their data via the
XEM.
f.
Storage format independent: Although instance XML documents
conformant with the MIP RDBMS XSD are meant to be produced and
consumed by MIP C2IS databases they should support any type of
storage format.
O-1.5 SPECIFIC MIP RDBMS XML CONSIDERATIONS
O-1.5.1
Introduction
O-1.5.1.1 In addition to the general considerations listed in the preceding
section, the RDBMS XSD also should be:
a.
Automatically Generatable: The XML schema should be automatically
derivable from the MIP ERA IDEF1X model to ensure correctness and
minimize its production and maintenance cost. The simplest approach
maps each entity definition onto an XSD complex type where all
attributes are preserved and keep their original domains. Such a one-toone mapping ensures easy integration in MIP-compliant RDBMS
systems.
b.
Based on Syntactic Transformations Only: The use of only syntactic
transformations enables the specification of transformation patterns that
can be applied to any version of the MIP IEDM. In addition, this
approach ensures that the RDBMS XSD is not dependent structurally on
the semantics of the model.
O-1-5
V3.1.4
O-1.5.2 RDBMS XSD Syntactic Transformation Design Patterns
O-1.5.2.1 Syntactic transformations can be applied to automatically generate
the XML schema. Irrespective of the technical realization, the overall schema
generation should be generic. In other words, the transformation rules should not
change when the MIP data model changes.
O-1.5.2.2 An RDBMS XML schema does not need to abstract from the
underlying persistence mechanism. This matches the notion of defining an XML
exchange format targeted for I/O in RDBMS applications. One should also be able to
use the RDBMS XSD for code generation. When that is the case, stubs for Java
classes can be generated from an XML schema.
O-1.5.3
Transformation Patterns for Relationships
O-1.5.3.1 IDEF1X Relationships
All links among data classes in IDEF1X are expressed in the physical design
as a migrated foreign key (FK) in the corresponding child entity (See Figure O-19
below). Specifically, one or more columns in the child table are created to
accommodate the migrated FKs. This generic syntactic transformation provides the
following rules for the generation of the XML representation:
a.
The FK attribute in the child entity becomes another of its XML
elements
b.
The cardinality of the relationship is expressed via the minOccurs and
maxOccurs attributes of the XML element corresponding to the FK
c.
An FK arising from a non-identifying relation has minOccurs = "0"
Identifying
One-to-Many
A
B
Non-Identifying
One-to-Many
B
C
Foreign Key (FK) from A to B
Key of B depends on FK
Foreign Key (FK) from C to B
Key of B does not depend on FK
A
Foreign Key (FK) from A to D
Key of D is identical to FK
Sub-Type
Relationship
D
Figure O-19. Physical Representation of IDEF1X Relationships
O-1.5.3.2 Physical Tables and Columns
O-1.5.3.2.1 An entity specified in the logical MIP IEDM corresponds to a
specification in the physical schema from which the RDBMS table is implemented.
Figure O-20 shows an example of this correspondence. The entity ACTION in the
logical view is represented in the physical view as the table ACT. From this physical
schema one can implement the table ACT in a database.
O-1-6
V3.1.4
Figure O-20. XML Representation of Physical Tables and Columns
O-1.5.3.2.2 This generic syntactic transformation provides the following
rules for the generation of the XML representation:
a.
For each physical table there is an XML element defined in the XSD.
The name of the element is formed by appending to the physical table
name the string "_TBL", e.g., for the table ACT its corresponding XML
element is <ACT_TBL>.
b.
For each record in the physical table there is an XML element. The
name of the element is identical with the name of the physical table
name, e.g., <ACT>.
c.
For each column in the physical table there is an XML element. The
name of these elements is identical with the physical column names,
e.g., <ACT_ID>, <CAT_CODE>.
d.
The values of each of the columns in a physical table are represented as
content of the corresponding column XML elements. The RDBMS XSD
does not use attributes in its XML tags.
O-1-7
V3.1.4
O-1.6 CHARACTERISTICS OF THE BASELINE RDBMS XML SCHEMA
O-1.6.1 With regard to the requirements and technical criteria discussed
above, the RDBMS XML schema and its generation can be characterized as follows:
a.
Presents an XML schema:
(1)
Based on the RDBMS physical schema of the MIP
IEDM.
(2)
Focussed on data exchanges among C2ISs that
implement the MIP IEDM in their RDBMS systems.
b.
Retains the full complement of keys from the MIP IEDM to enable the
assertion of relationships among the tables.
c.
Contains semantic checks for all valid domain values,
optional/mandatory attributes, and referential integrity to support
database-to-database communication.
d.
Expresses relationships through the key structure of the MIP IEDM
e.
Supports an XML schema generation that is:
f.
(1)
Generic, i.e., independent from a particular version of
the MIP data model
(2)
Semi-automatic; comprises syntactic transformations
and uses knowledge about the subject/object role of
entities
Is modular and its components are:
(1)
The Root XSD, which specifies all the table elements
that can be child nodes of the XML root tag
(2)
The Tables XSD, which declares all the table elements
globally and specifies the XML element that can be
declared as the content in each of the tables (i.e., the
so-called record-delimiters)
(3)
The Entity Types XSD, which declares the content of
the record-delimiter XML elements. These are
basically the XML elements that correspond to each of
the columns in the pertinent database table
(4)
The Simple Types XSD. These are the XML
specifications corresponding to the physical data types
that have been assigned to each of the columns in the
database tables. Currently, their names are derived
from the logical data types defined in the given MIP
IEDM. The logical data types contain part of the
semantics of the model, e.g., optional versus
mandatory, etc.
(5)
The Codes XSD. These are the complex data types for
all the XML elements corresponding to the
enumerated domains in the MIP IEDM.
O-1-8
V3.1.4
O-1.6.2 In addition to facilitating reuse and maintenance the modular
design also enables commonality between the two MIP Reference XSD designs.
Specifically, the Simple Type XSD and the Codes XSD components are fully shared
between the RDBMS XSD and the WS/OO XSD. This makes it easier to implement
conversions between an instance XML document based on the RDBMS XSD to one
that conforms to the WS/OO XSD and vice versa. Finally, by componentising the
RDBMS XSD and having the coded domains and the simple types declared in this
fashion it is easier to support backwards compatibility. Instead of removing the old
blueprints any new data types and code specifications can be added with relatively
little cost in every subsequent release of the schema. That way legacy applications can
use the new releases of the Simple Type XSD and the Codes XSD components.
O-1.6.3 The RDBMS XML XSD reflects deterministic mapping rules from
the ER data model. Mapping rules are defined for the following MIP data model
concepts:
a.
Names: Names of simple types, codes, attributes, and entities are taken
directly from the physical schema of the MIP IEDM.
b.
Domains: Simple types are mapped onto XML simple types.
c.
Structural Elements: Mapping rules are defined for the following
structural elements:
d.
(1)
Entities
(2)
Attributes (optional and mandatory)
(3)
Relationships
(4)
Subtyping
(5)
Associations (taking into account their multiplicities)
Business Rules: Business rules are either resolved, i.e., encoded
implicitly, or stated explicitly.
O-1.7 RDBMS XSD STRUCTURE
O-1.7.1 Specification of the Root Tag
O-1.7.1.1 The root XML tag chosen in the MIP IEDM RDBMS schema is
currently the concatenation of the model name followed by a string that reflects its
type, e.g., RDBMS. For example, for the JC3IEDM the root tag is named
<JC3IEDM_RDBMS>.
O-1.7.1.2 The Root XSD declares this element as a complex type. The
fragment below shows the characteristics discussed here.
<element name="JC3IEDM_RDBMS">
<complexType>
<all>
<element ref="jc3iedm:ABS_POINT_TBL" minOccurs="0"/>
<element ref="jc3iedm:ACT_TBL" minOccurs="0"/>
<element ref="jc3iedm:ACT_ACFT_EMPLOY_TBL" minOccurs="0"/>
*
</complexType>
</element>
O-1-9
V3.1.4
O-1.7.1.3 The allowed elements are all the XML elements corresponding to
the tables in JC3IEDM. They can appear in any order. There can be at most one of
each such element in any instance XML document that conforms to the RDBMS
XSD. Finally, to conform to the NATO XML recommendations, the XML elements
corresponding to the tables in JC3IEDM are declared by reference in the Root XSD
because they are global elements.
O-1.7.2 Specification of XML Elements for Physical Tables
O-1.7.2.1 The application of the syntactic transformations discussed in
Section 5 for the XML elements corresponding to the MIP IEDM tables is captured in
the Tables XSD in the following fashion:
a.
Each XML tag corresponding to a table, e.g., <ACT_TBL>, is defined as
an element of type complex.
b.
The only content for this element is another XML element
corresponding to the record delimiter, e.g., <ACT>. The record-delimiter
element is always defined as being of a type whose name is derived
from the logical entity name and specified in the Entity Types XSD (see
below).
c.
Each XML tag corresponding to a table uses xs:sequence for its content
d.
The cardinality of the record delimiter tag, e.g., <ACT>, is always
maxOccurs="unbounded", since an instance XML document
conformant to the RDBMS XSD should be able to contain any number
of records per table.
O-1.7.2.2 The fragment below shows the section of the Tables XSD
corresponding to the XML element ACT_TBL. Similar specifications are given in the
RDBMS XSD for all the tables specified in the MIP IEDM.
<xs:element name="ACT_TBL">
<element name="ACT_TBL">
<complexType>
<sequence>
<element name="ACT" type="jc3iedm:Action" maxOccurs="unbounded" />
</sequence>
</complexType>
</element>
</xs:element>
O-1.7.3 Specification of XML Elements for Record Delimiters
O-1.7.3.1 The next component of the RDBMS XSD addresses the type for
the XML element that indicates the beginning and the end of each record in a table,
the so-called record-delimiter tags. Its characteristics are captured in the Entity Types
XSD in the following fashion:
a.
The XML type for every record delimiter tag is defined as a complex
type whose sole content are the XML elements corresponding to the
O-1-10
V3.1.4
columns of the physical table (see Figure O-19 above for the case where
the record delimiter is <ACT>).
b.
There is an annotation that gives the definition of the complex type. This
definition is identical to the one corresponding to the logical entity in
the MIP IEDM. For example the definition of the complex type Action
is identical to the definition of the logical entity ACTION.
c.
For each of the XML elements corresponding to the record delimiter
tags there is an annotation which gives the definition of the
corresponding logical attribute. For example for the XML element
ACT_ID the annotation gives the definition corresponding to the logical
attribute action-id in JC3IEDM.
d.
All the XML elements corresponding to the record delimiter tags use the
tag <all> to indicate that the order in which its content is listed in an
instance XML document is irrelevant. This is consistent with the usage
in most commercial RDBMSs and is equivalent to an SQL INSERT
command where the names of the fields is given explicitly, and, hence
can be in any order.
e.
All the XML elements corresponding to the columns of the physical
table are defined locally.
f.
Each of the XML elements corresponding to the columns of the physical
table has a type specified that is controlled by either the Simple Types
XSD or the Codes XSD.
O-1.7.3.2 The fragment below shows the section of the Entities XSD
corresponding to the complex type for the record delimiter <ACT> in the ACTION
table, i.e., ACT_TBL, and all the XML elements that form its content.
<complexType name="Action">
<annotation>
<documentation xml:lang="en">An activity, or the occurrence of an
activity, that may utilise resources and may be focused against an
objective.</documentation>
</annotation>
<all>
<element name="ACT_ID" type="jc3iedm:IdentifierType20" minOccurs="1"
maxOccurs="1">
<annotation>
<documentation
xml:lang="en">The
unique
value,
or
set
of
characters, assigned to represent a specific ACTION and to distinguish it
from all other ACTIONs.</documentation>
</annotation>
</element>
<element
name="CAT_CODE"
type="jc3iedm:ActionCategoryCode"
minOccurs="1" maxOccurs="1">
<annotation>
<documentation xml:lang="en">The specific value that represents
the class of ACTION. It serves as a discriminator that partitions ACTION
into subtypes.</documentation>
</annotation>
</element>
<element name="NAME_TXT" type="jc3iedm:TextTypeVar50" minOccurs="0"
maxOccurs="1">
<annotation>
O-1-11
V3.1.4
<documentation xml:lang="en">The character string assigned to
represent a specific ACTION.</documentation>
</annotation>
</element>
<element
name="CREATOR_ID"
type="jc3iedm:
IdentifierType20"
<annotation>
<documentation xml:lang="en">A value assigned to the row to
identify the organisation which created that row. This is referenced by an
application level business rule to an OBJ_ITEM entry with a cat_code = OR
and to a corresponding ORG subtype entry.</documentation>
</annotation>
</element>
<element
name="UPDATE_SEQNR"
type="jc3iedm:UpdateSeqnrType15"
<annotation>
<documentation xml:lang="en">An absolute sequence number, assigned
to represent the validity (in terms of seniority) of a certain data
item.</documentation>
</annotation>
</element>
</all>
</complexType>
O-1.7.3.3 The Simple Types XSD states the type for each of the XML
elements defined in the Entity Types XSD (see above) which are not enumerations.
For types corresponding to integer numeric content the Simple Types XSD captures
the specification in the following fashion:
a.
When the SQL data type for the element in the MIP IEDM is
NUMBER(N), the corresponding XML element is specified in the
RDBMS XSD using <restriction base="integer">.
b.
The restrictions are minInclusive, and maxInclusive. These values are
used to specify further constraints on the type, e.g., whether the value
must be ≥ 0, or whether the maximum value must be ≤ 90.
O-1.7.3.4 The fragment below shows the section of the Simple Types XSD
corresponding to the XML element UPDATE_SEQNR, whose SQL data type is
NUMBER(15), and how the restrictions on the numeric values are expressed.
<simpleType name="UpdateSeqnrType15">
<annotation>
<documentation xml:lang="en">An absolute sequence number, assigned to
represent the validity (in terms of seniority) of a certain data
item.</documentation>
</annotation>
<restriction base="integer">
<minInclusive value="-999999999999999" />
<maxInclusive value="999999999999999" />
</restriction>
</simpleType>
O-1.7.3.5 The characteristics of elements that have decimal numeric content
are captured in the Simple Types XSD in the following fashion:
O-1-12
V3.1.4
a.
When the SQL data type for the element in the MIP IEDM is
NUMBER(N,M), the corresponding XML element is specified in the
RDBMS XSD using <restriction base="decimal">.
b.
The restrictions are totalDigits, fractionDigits, minInclusive, and
maxInclusive. The value of totalDigits corresponds to the value of N in
NUMBER(N,M), whereas the value of fractionDigits corresponds to the
value of M in NUMBER(N,M). The values of minInclusive, and
maxInclusive are used to specify further restrictions, e.g., whether the
value must be ≥ 0.
O-1.7.3.6 The TemperatureTypeRangeTemperature fragment below shows a
section of the Simple Types XSD and how the NUMBER(5,1) is further restricted.
<simpleType name="TemperatureTypeRangeTemperature5_1">
<annotation>
<documentation xml:lang="en">A measure of degree of hotness or
coldness in an object or in space. This will be expressed in degrees
Celsius.</documentation>
</annotation>
<restriction base="decimal">
<totalDigits value="5" />
<fractionDigits value="1" />
<minInclusive value="-273.2" />
<maxInclusive value="9999.9" />
</restriction>
</simpleType>
O-1.7.3.7 The characteristics of the elements that have character string
content are captured in the Simple Types XSD in the following fashion:
a. When the SQL data type for the element in the MIP IEDM is either
CHAR(N) or VARCHAR(N), the corresponding XML element is specified in
the RDBMS XSD using <restriction base="string">.
b. The restrictions are minLength, and maxLength. These values are used to
specify further restrictions, e.g., the largest and the smallest number of
characters the string can have.
O-1.7.3.8 The fragment below shows the section of the Simple Types XSD
corresponding to the type is VARCHAR(2000), and how the restrictions on the
numeric values are expressed.
<simpleType name="TextTypeVar2000">
<annotation>
<documentation xml:lang="en">A character string (i.e. a finite set of
characters) generally in the form of words of a language. This embraces
notions such as description, name, comment etc.</documentation>
</annotation>
<restriction base="string">
<minLength value="0" />
<maxLength value="2000" />
</restriction>
</simpleType>
O-1-13
V3.1.4
O-1.8. RDBMS XSD GENERATION TOOLKIT
O-1.8.1 General
As indicated in Section O-1.5 above, the generation of the RDBMS XSD
should be automatic. This requirement is satisfied for the baseline RDBMS XSD
through a tool kit. The toolkit is written in Java and uses as input a file containing the
model specifications written in Erwin XML format.
O-1.9. RDBMS ALTERNATE REPRESENTATIONS
O-1.9.1 The style presented in the preceding sections for the instance XML
documents built in conformance with the MIP RDMBS XSD is optimal for database
input and output. However, since all the tables and columns are represented as
elements it causes the use of opening and closing XML tags for all content and makes
the document more verbose and somewhat harder for humans to read. A streamlined
version of the instance XML documents with the same information payload can be
achieved by using XML tag attributes instead of elements to represent the columns in
a record. The fragment below shows an example of that alternative representation:
<ACT_TBL>
<ACT ACT_ID="66366464" CAT_CODE="ACTTA" NAME="Operation Alpha Point"
CREATOR_ID="777474" UPDATE_SEQNR="0" />
</ ACT_TBL>
O-1.9.2 If the use of XML tag attributes is used in both the WS/OO and the
RDBMS documents it could be possible to increase the commonality between the two
specifications by adopting an RDBMS representation based on the XML tag and
attribute names of the WS/OO schema. Converting from this alternate style to the
original format is relatively straightforward and can be accomplished via either
XSLTs or programmatically, e.g., Perl scripts.
O-1-14
V3.1.4
ANNEX O, APPENDIX 2
Extensible Markup Language (XML) Reference Implementations
RDBMS Use Case
O-2.1 STRUCTURE OF THE DOCUMENT
O-2.1.1 This appendix documents a series of examples for how to serialize
data resident in an RDMBS that uses the physical schema of the MIP IEDM, so that
the resulting XML instance documents validate according to RDBMS XSD. The
examples are based on the current specification - JC3IEDM Edition-3.0.2.
O-2.1.2 Similarly, all numbering of the Sections is given with respect to the
JC3IEDM Edition-3.1c doc available in the members section of the MIP website. The
full listings for all the XML instance documents are part of the package available at
the MIP website.
O-2.1.3 All the SQL query examples are for MySQL (version 4.0.24). SQL
functions are vendor specific. That means that in order to reproduce the results of the
SQL query shown in Listing 18 one has to replace the functions shown with those
supported by the particular RDBMS.
O-2.2
EXAMPLE 01. OBJECT-ITEM-ASSOCIATION and OBJECT-ITEMSTATUS
This example shows how the JC3IEDM (a) uses OBJECT-ITEMASSOCIATION to relate various battlefield objects, and (b) how it handles the
changes in the status of these instances of OBJECT-ITEM as the result of an
operational situation. The use of OBJECT-ITEM-STATUS and its subtypes is
highlighted.
O-2.2.1 Description
O-2.2.1.1 Assume that there is a bridge, namely, the White Horse Bridge
across the Yukon River which initially serves as a passage between two minefields
located on the north side of the river, one on each side of the bridge. The contingency
plan is to use the bridge as part of an obstacle. If the units of the joint task force that
are now deployed on the north side of the river need to withdraw, the bridge will be
demolished to become part of the main obstacle. The general layout is illustrated in
Figure O-21 below where North is toward top of the page.
O-2-1
V3.1.4
N
Obstacle Alpha
White Horse
Bridge
West Minefield
East Minefield
Yukon River
S
Figure O-21. Sketch for the Scenario Used to Highlight the Use of OBJECT-ITEM-STATUS
O-2.2.1.2 The following sequence of actions and changes in operational
status now takes place:
a.
On 22 October 2003, 1 CA Brigade creates a contingency plan to set up
an Obstacle Alpha that consists of three components, namely, two
minefields and a demolished bridge.
b.
Minefield West is laid and activated on 2 November, followed by
Minefield East on 3 November.
c.
The White Horse Bridge is reported to be prepared for demolition on 3
November.
d.
On 7 November, the brigade elements north of the river cross to the
south. The bridge is demolished and Obstacle Alpha becomes
operational in its entirety.
e.
Table O-2 shows how this information would be captured in the using
JC3IEDM.
Table O-2. Data for Example 01
(a) OBJECT-ITEM
FACILITY
object-item-nametext
facilityid
West Minefield
1
East Minefield
2
Obstacle Alpha
3
White Horse Bridge
4
facility-categorycode
facilityheightdimension
facilitylengthdimension
facilitywidthdimension
MILITARYOBSTACLE
MILITARYOBSTACLE
MILITARYOBSTACLE
—
300
105
—
320
90
—
650
325
BRIDGE
—
200
10
(b) BRIDGE
bridge-id
bridge-longest-spanlength-dimension
bridge-spancount
bridge-usagecode
4
40
5
Railway/vehicle
O-2-2
V3.1.4
(c) MILITARY-OBSTACLE
military-obstacle-id
military-obstacle-category-code
1
2
3
MINEFIELD
MINEFIELD
NOS
(d) MINEFIELD
minefield
-id
minefieldcategory-code
minefieldidentification-text
minefieldminespacingdimension
1
2
MINEFIELD-LAND
MINEFIELD-LAND
MNFLD-WEST
MNFLD-EAST
10 (m)
10 (m)
minefielddestructiondatetime
—
—
(e) MINEFIELD-LAND
minefield
-land-id
minefield-landdepthplacement-code
minefield-landfunction-code
1
Mixed
Nuisance
2
Mixed
Nuisance
minefield-landpattern-code
minefieldlandpersistenc
e-code
minefieldlandstoppingpower-code
Regular minefield,
thickened with
scattered mines
Regular minefield,
thickened with
scattered mines
Remote
activated
destruction
Remote
activated
destruction
Medium
Medium
(f) OBJECT-ITEM-HOSTILITY-STATUS
object-item-id
object-item-hostilitystatus-index
object-item-hostilitystatus-code
reportingdata-id
1[Minefield West]
2 [Minefield East]
3 [Obstacle Alpha]
4 [White Horse Bridge]
1
1
1
1
Friend
Friend
Friend
Friend
700
700
700
700
(g) OBJECT-ITEM-STATUS
object-item-id
*index
*-category-code
*-booby-trappresencecode
1[Minefield West]
2 [Minefield East]
3 [Obstacle Alpha]
1
1
1
1
FACILITY-STATUS
FACILITY-STATUS
FACILITY-STATUS
FACILITY-STATUS
—
—
—
—
—
—
—
—
701
702
703
704
3 [Obstacle Alpha]
2
2
FACILITY-STATUS
—
FACILITY-STATUS
—
Note: * = "object-item-status"
—
—
705
705
O-2-3
*-emissioncontrolreportingcode
data-id
V3.1.4
(h) FACILITY-STATUS
objectitemstatusindex
facilitystatus-id
1[Minefield
West]
2 [Minefield
East]
3 [Obstacle
Alpha]
4 [White
Horse Bridge]
4 [White
Horse Bridge]
3 [Obstacle
Alpha]
1
1
1
1
2
2
**-categorycode
Not otherwise
specified
Not otherwise
specified
Not otherwise
specified
Not otherwise
specified
Not otherwise
specified
Not otherwise
specified
**demolitionstatus-code
**-minepresence
-code
**operationalstatus-code
**operationalstatusqualifiercode
—
Yes
Operational
—
Activated
—
Yes
Operational
—
Activated
—
Yes
No
Prepared for
execution
Passable
—
Prepared for
execution
Executed
Not
operational
Operational
—
No
Not
operational
Destroyed
—
—
Yes
Operational
—
Activated
**-usagestatus-code
Note: ** = “facility-status”
(i) OBJECT-ITEM-ASSOCIATION
***-subject-object-itemid
***-object-objectitem-id
***index
***-categorycode
***-subcategorycode
1[Minefield West]
3 [Obstacle Alpha]
1
Is part of
—
2 [Minefield East]
3 [Obstacle Alpha]
3 [Obstacle Alpha]
1
1
Is part of
Is part of
—
—
(j) OBJECT-ITEM-ASSOCIATION-STATUS
***-subjectobject-item-id
***-objectobject-item-id
1
2
4
1
2
4
3
3
3
3
3
3
***
-index
***-associationstatus-index
***-statuscategory-code
1
1
Start association
1
1
Start association
1
1
Start association
1
2
Start association
1
2
Start association
1
2
Start association
Note: *** = “object-item-association”
reportingdata-id
711
711
711
712
712
712
(k) REPORTING-DATA
*-id
*-categorycode
*-countingindicatorcode
*-credibility-code
*-reporting-datetime
700
701
702
703
Reported
Reported
Reported
Planned
—
—
—
—
Reported as a fact
Reported as a fact
Reported as a fact
Reported as a fact
20031022103000.000
20031102094900.000
20031103154200.000
20031022103000.000
704
Reported
—
Reported as a fact
20031103171000.000
705
711
Reported
Planned
—
—
Reported as a fact
Reported as a fact
20031107081000.000
20031022103000.000
712
Reported
—
Reported as a fact 20031107081000.000
Note: * = “reporting-data”
O-2-4
*-timingcategorycode
*-reportingorganisationid
[absolute]
[absolute]
[absolute]
Timing not
available
Timing not
available
[1 CA Bde]
[1 CA Bde]
[1 CA Bde]
[1 CA Bde]
[absolute]
Timing not
available
[absolute]
[1 CA Bde]
[1 CA Bde]
[1 CA Bde]
[1 CA Bde]
V3.1.4
(l) REPORTING-DATA-ABSOLUTE-TIMING
**reporting-data-id
700
701
702
705
712
**-effective-start-datetime
**-effective-end-datetime
20031022103000.000
20031102094500.000
20031103153000.000
20031107080000.000
20031107080000.000
Note: ** = “reporting-data-absolute-timing”
Note: The data for OBJECT-TYPE,
ORGANISATION has been omitted.
—
—
—
—
—
OBJECT-ITEM-TYPE,
and
O-2.2.2 Serialization Using the RDBMS XML Tag Set
O-2.2.2.1 As discussed in the RDBMS XSD Design Annex, the RDBMS
XSD has a structure that exactly parallels all the tables and attributes in the MIP
IEDM. Figure O-22 below shows the data structures needed to capture the
information provided in this example (taken from the JC3IEDM).
O-2.2.2.2 The XML serialization of Example 01 is, therefore, simply the
expression of the values shown in Table O-2 above, both explicitly and implied, using
the XML tags specified in the RDBMS XSD. The listings below show the XML
segments corresponding to the entries in Table O-2, subparts (a) through (l).
O-2-5
V3.1.4
OBJECT -ITEM
is-c lassified-as
objec t-item-id
is-the-subjec t-of
is-the-objec t-of
objec t-item-c ategory -c ode
objec t-item-name-text
OBJECT-ITEM -HOSTILITY-ST AT US
OBJECT-ITEM -ASSOCIATION
objec t-item-id (FK)
objec t-item-hostility -status-index
has /
is-asc ribed-to
objec t-item-assoc iation-subjec t-objec t-item-id (FK)
objec t-item-assoc iation-objec t-objec t-item-id (FK)
objec t-item-assoc iation-index
objec t-item-hostility -status-c ode
reporting-data-id (FK)
objec t-item-assoc iation-c ategory -c ode
objec t-item-assoc iation-subc ategory -c ode
ac tion-task-id (FK)
has /
is-asc ribed-to
provides-applic able-information-for /
is-referenc ed-to
objec t-item-c ategory -c ode
has /
is-asc ribed-to
FACILITY
P
OBJECT-ITEM -ASSOCIATION-ST ATUS
fac ility -id (FK)
objec t-item-assoc iation-subjec t-objec t-item-id (FK)
objec t-item-assoc iation-objec t-objec t-item-id (FK)
objec t-item-assoc iation-index (FK)
objec t-item-assoc iation-status-index
fac ility -c ategory -c ode
fac ility -primary -c onstruc tion-material-c ode
fac ility -base-identific ation-c ode-text
fac ility -height-dimension
fac ility -length-dimension
fac ility -width-dimension
fac ility -major-building-ty pe-id (FK)
objec t-item-assoc iation-status-c ategory -c ode
P
OBJECT-ITEM -STATUS
fac ility -c ategory -c ode
OBJECT-ITEM -T YPE
objec t-item-status-index
ORGANISATION
objec t-ty pe-id (FK)
objec t-item-ty pe-index
objec t-item-status-c ategory -c ode
objec t-item-status-booby -trap-presenc e-c ode
objec t-item-status-emission-c ontrol-c ode
organisation-id (FK)
organisation-c ategory -c ode
is-the-reporting-agent-for /
is-reported-by
object-item-status-category-code
BRIDGE
is-referenc ed-to
bridge-id (FK)
bridge-longest-span-length-dimension
bridge-span-c ount
bridge-usage-c ode
is-referenc ed-to
M ILITARY-OBSTACLE
OBJECT -T YPE
objec t-ty pe-id
is-referenc ed-to
military -obstac le-id (FK)
is-used-as-a-c lassific ation-for
objec t-ty pe-c ategory -c ode
objec t-ty pe-dec oy -indic ator-c ode
objec t-ty pe-name-text
military -obstac le-c ategory -c ode
REPORTING-DATA
FACILIT Y-STAT US
military -obstac le-c ategory -c ode
reporting-data-id
reporting-data-ac c urac y -c ode
reporting-data-c ategory -c ode
reporting-data-c ounting-indic ator-c ode
reporting-data-c redibility -c ode
reporting-data-reliability -c ode
reporting-data-reporting-datetime
reporting-data-sourc e-ty pe-c ode
reporting-data-timing-c ategory -c ode
reporting-data-real-data-exerc ise-use-only -c ode
referenc e-id (FK)
reporting-data-reporting-organisation-id (FK)
M INEF IELD
minefield-id (FK)
minefield-c ategory -c ode
minefield-identific ation-text
minefield-mine-spac ing-dimension
minefield-destruc tion-datetime
minefield-c ategory -c ode
fac ility -status-id (FK)
objec t-item-status-index (FK)
fac ility -status-c ategory -c ode
fac ility -status-demolition-status-c ode
fac ility -status-enemy -ac tivity -c ondition-c ode
fac ility -status-mine-presenc e-c ode
fac ility -status-oc c upation-program-indic ator-c ode
fac ility -status-operational-status-c ode
fac ility -status-operational-status-qualifier-c ode
fac ility -status-reserve-indic ator-c ode
fac ility -status-sec urity -status-c ode
fac ility -status-usage-status-c ode
M INEFIELD-LAND
minefield-land-id (FK)
reporting-data-timing-c ategory -c ode
minefield-land-depth-plac ement-c ode
minefield-land-func tion-c ode
minefield-land-pattern-c ode
minefield-land-persistenc e-c ode
minefield-land-stopping-power-c ode
REPORT ING-DATA-ABSOLUTE-TIM ING
reporting-data-absolute-timing-reporting-data-id (FK)
reporting-data-absolute-timing-effec tive-start-datetime
reporting-data-absolute-timing-effec tive-end-datetime
Figure O-22. MIP IEDM Data Structures Needed to Specify
the Use of OBJECT-ITEM-ASSOCIATION and OBJECT-ITEM-STATUS
Listing 1. XML Segment for the OBJECT-ITEM table
<OBJ_ITEM_TBL>
<OBJ_ITEM>
<NAME_TXT>WEST MINEFIELD</NAME_TXT>
<CREATOR_ID>121</CREATOR_ID>
<UPDATE_SEQNR>1</UPDATE_SEQNR>
</OBJ_ITEM>
<OBJ_ITEM>
O-2-6
V3.1.4
<NAME_TXT>EAST MINEFIELD</NAME_TXT>
</OBJ_ITEM>
<OBJ_ITEM>
<NAME_TXT>OBSTACLE ALPHA</NAME_TXT>
</OBJ_ITEM>
<OBJ_ITEM>
<NAME_TXT>WHITE HORSE BRIDGE</NAME_TXT>
</OBJ_ITEM>
<OBJ_ITEM>
<CAT_CODE>OR</CAT_CODE>
<NAME_TXT>1 CA BDE</NAME_TXT>
</OBJ_ITEM>
</OBJ_ITEM_TBL>
Listing 2. XML Segment for the OBJECT-TYPE table
<OBJ_TYPE_TBL>
<OBJ_TYPE>
<NAME_TXT>MINE</NAME_TXT>
</OBJ_TYPE>
<OBJ_TYPE>
<NAME_TXT>MILITARY OBSTACLE</NAME_TXT>
</OBJ_TYPE>
<OBJ_TYPE>
<NAME_TXT>BRIDGE</NAME_TXT>
</OBJ_TYPE>
<OBJ_TYPE>
<CAT_CODE>OR</CAT_CODE>
<NAME_TXT>BRIGADE</NAME_TXT>
</OBJ_TYPE>
</OBJ_TYPE_TBL>
O-2-7
V3.1.4
Listing 3. XML Segment for the FACILITY table
<FAC_TBL>
<FAC>
<FAC_ID>1</FAC_ID>
<PRIM_CONST_MATRL_CODE>EARTH</PRIM_CONST_MATRL_CODE>
<BASE_IDENTIFIC_CODE_TXT />
<HEIGHT_DIM>0.000</HEIGHT_DIM>
<FAC_MAJOR_BUILDING_TYPE_ID>NULL</FAC_MAJOR_BUILDING_TYPE_ID>
</FAC>
<FAC>
<FAC_ID>2</FAC_ID>
<PRIM_CONST_MATRL_CODE>EARTH</PRIM_CONST_MATRL_CODE>
</FAC>
<FAC>
<FAC_ID>3</FAC_ID>
<CAT_CODE>NOS</CAT_CODE>
<PRIM_CONST_MATRL_CODE>NOS</PRIM_CONST_MATRL_CODE>
</FAC>
<FAC>
<FAC_ID>4</FAC_ID>
<CAT_CODE>BRIDGE</CAT_CODE>
<PRIM_CONST_MATRL_CODE>STELMT</PRIM_CONST_MATRL_CODE>
</FAC>
</FAC_TBL>
Listing 4. XML Segment for the MILITARY-OBSTACLE table
<MIL_OBS_TBL>
<MIL_OBS>
</MIL_OBS>
<MIL_OBS>
O-2-8
V3.1.4
</MIL_OBS>
<MIL_OBS>
</MIL_OBS>
</MIL_OBS_TBL>
Listing 5. XML Segment for the MINEFIELD table
<MNFLD_TBL>
<MNFLD>
<IDENTIFIC_TXT>MNFLD-WEST</IDENTIFIC_TXT>
<MINE_SPACING_DIM>10.000</MINE_SPACING_DIM>
</MNFLD>
<MNFLD>
<IDENTIFIC_TXT>MNFLD-EAST</IDENTIFIC_TXT>
<MINE_SPACING_DIM>10.000</MINE_SPACING_DIM>
</MNFLD>
</MNFLD_TBL>
Listing 6. XML Segment for the MINEFIELD-LAND table
<MNFLD_LAND_TBL>
<MNFLD_LAND>
<DEPTH_PLCMNT_CODE>MIXED</DEPTH_PLCMNT_CODE>
<PERSISTENCE_CODE>REMOTE</PERSISTENCE_CODE>
<STOPPING_POWER_CODE>MEDIUM</STOPPING_POWER_CODE>
</MNFLD_LAND>
<MNFLD_LAND>
<DEPTH_PLCMNT_CODE>MIXED</DEPTH_PLCMNT_CODE>
<PERSISTENCE_CODE>REMOTE</PERSISTENCE_CODE>
<STOPPING_POWER_CODE>MEDIUM</STOPPING_POWER_CODE>
</MNFLD_LAND>
</MNFLD_LAND_TBL>
Listing 7. XML Segment for the BRIDGE table
<BRIDGE_TBL>
<BRIDGE>
<BRIDGE_ID>4</BRIDGE_ID>
<LONGEST_SPAN_LENGTH_DIM>40.000</LONGEST_SPAN_LENGTH_DIM>
<SPAN_CNT>5</SPAN_CNT>
<USAGE_CODE>RLWYVH</USAGE_CODE>
O-2-9
V3.1.4
</BRIDGE>
</BRIDGE_TBL>
Listing 8. XML Segment for the ORGANISATION table
<ORG_TBL>
<ORG>
<ORG_ID>5</ORG_ID>
</ORG>
</ORG_TBL>
Listing 9. XML Segment for the REPORTING-DATA table
<RPTD_TBL>
<RPTD>
<RPTD_ID>700/RPTD_ID>
<CNTG_IND_CODE>NO</CNTG_IND_CODE>
<CREDIBILITY_CODE>RPTFCT</CREDIBILITY_CODE>
<RELIABILITY_CODE />
<REP_DTTM>20031102093000.000</REP_DTTM>
<TIMING_CAT_CODE>RDABST</TIMING_CAT_CODE>
<REAL_DATA_EXER_USE_ONLY_CODE />
<REF_ID>NULL</REF_ID>
</RPTD>
<RPTD>
<REP_DTTM>20031102094900.000</REP_DTTM>
</RPTD>
<RPTD>
<REP_DTTM>20031103154200.000</REP_DTTM>
O-2-10
V3.1.4
</RPTD>
<RPTD>
<CAT_CODE>PLAN</CAT_CODE>
<REP_DTTM>20031022103000.000</REP_DTTM>
<TIMING_CAT_CODE>TIMNA</TIMING_CAT_CODE>
</RPTD>
<RPTD>
<REP_DTTM>20031103171000.000</REP_DTTM>
</RPTD>
<RPTD>
<REP_DTTM>20031107081000.000</REP_DTTM>
</RPTD>
<RPTD>
<CAT_CODE>PLAN</CAT_CODE>
<REP_DTTM>20031022103000.000</REP_DTTM>
O-2-11
V3.1.4
</RPTD>
<RPTD>
<REP_DTTM>20031107081000.000</REP_DTTM>
</RPTD>
<RPTD>
<REP_DTTM>20031101110000.000</REP_DTTM>
<ENT_CAT_CODE>OITYPE</ENT_CAT_CODE>
</RPTD>
</RPTD_TBL>
Listing 10. XML Segment for the REPORTING-DATA-ABSOLUTE-TIMING table
<RPTD_ABS_TIMING_TBL>
<RPTD_ABS_TIMING>
<RPTD_ABS_TIMING_RPTD_ID>701</RPTD_ABS_TIMING_RPTD_ID>
<EFFCTV_START_DTTM>20031102094500.000</EFFCTV_START_DTTM>
<EFFCTV_END_DTTM />
</RPTD_ABS_TIMING>
<RPTD_ABS_TIMING>
<EFFCTV_END_DTTM />
</RPTD_ABS_TIMING>
<RPTD_ABS_TIMING>
<EFFCTV_END_DTTM />
</RPTD_ABS_TIMING>
O-2-12
V3.1.4
<RPTD_ABS_TIMING>
<EFFCTV_END_DTTM />
</RPTD_ABS_TIMING>
</RPTD_ABS_TIMING_TBL>
Listing 11. XML Segment for the OBJECT-ITEM-TYPE table
<OBJ_ITEM_TYPE_TBL>
<OBJ_ITEM_TYPE>
</OBJ_ITEM_TYPE>
<OBJ_ITEM_TYPE>
</OBJ_ITEM_TYPE>
<OBJ_ITEM_TYPE>
</OBJ_ITEM_TYPE>
<OBJ_ITEM_TYPE>
</OBJ_ITEM_TYPE>
<OBJ_ITEM_TYPE>
</OBJ_ITEM_TYPE>
</OBJ_ITEM_TYPE_TBL>
Listing 12. XML Segment for the OBJECT-ITEM-STATUS table
<OBJ_ITEM_STAT_TBL>
<OBJ_ITEM_STAT>
<BOOBY_TRAP_PRSNC_CODE />
<EMSN_CTRL_CODE />
O-2-13
V3.1.4
</OBJ_ITEM_STAT>
<OBJ_ITEM_STAT>
<EMSN_CTRL_CODE />
</OBJ_ITEM_STAT>
<OBJ_ITEM_STAT>
<EMSN_CTRL_CODE />
</OBJ_ITEM_STAT>
<OBJ_ITEM_STAT>
<EMSN_CTRL_CODE />
</OBJ_ITEM_STAT>
<OBJ_ITEM_STAT>
<EMSN_CTRL_CODE />
</OBJ_ITEM_STAT>
<OBJ_ITEM_STAT>
<EMSN_CTRL_CODE />
</OBJ_ITEM_STAT>
</OBJ_ITEM_STAT_TBL>
Listing 13. XML Segment for the OBJECT-ITEM-HOSTILITY-STATUS table
<OBJ_ITEM_HSTLY_STAT_TBL>
<OBJ_ITEM_HSTLY_STAT>
<OBJ_ITEM_HSTLY_STAT_IX>1</OBJ_ITEM_HSTLY_STAT_IX>
<CODE>FR</CODE>
</OBJ_ITEM_HSTLY_STAT>
O-2-14
V3.1.4
<CODE>FR</CODE>
<CODE>FR</CODE>
<CODE>FR</CODE>
<CODE>FR</CODE>
<CODE>FR</CODE>
</OBJ_ITEM_HSTLY_STAT_TBL>
Listing 14. XML Segment for the FACILITY-STATUS table
<FAC_STAT_TBL>
<FAC_STAT>
<FAC_STAT_ID>1</FAC_STAT_ID>
<DMLTN_STAT_CODE />
<ENEMY_ACTV_COND_CODE />
<MINE_PRSNC_CODE>YES</MINE_PRSNC_CODE>
<OCPTN_PROG_IND_CODE />
<OPERAT_STAT_CODE>OPR</OPERAT_STAT_CODE>
<OPERAT_STAT_QUAL_CODE />
<RESERVE_IND_CODE />
<SECURITY_STAT_CODE />
<USAGE_STAT_CODE>ACTIVE</USAGE_STAT_CODE>
</FAC_STAT>
<FAC_STAT>
<DMLTN_STAT_CODE />
O-2-15
V3.1.4
</FAC_STAT>
<FAC_STAT>
<DMLTN_STAT_CODE />
<OPERAT_STAT_CODE>NOP</OPERAT_STAT_CODE>
<OPERAT_STAT_QUAL_CODE>PRPEXE</OPERAT_STAT_QUAL_CODE>
<USAGE_STAT_CODE />
</FAC_STAT>
<FAC_STAT>
<DMLTN_STAT_CODE />
<OPERAT_STAT_QUAL_CODE>PASABL</OPERAT_STAT_QUAL_CODE>
<USAGE_STAT_CODE />
</FAC_STAT>
<FAC_STAT>
<DMLTN_STAT_CODE>PRPEXE</DMLTN_STAT_CODE>
<MINE_PRSNC_CODE>NO</MINE_PRSNC_CODE>
<USAGE_STAT_CODE />
</FAC_STAT>
<FAC_STAT>
<DMLTN_STAT_CODE>EXECTD</DMLTN_STAT_CODE>
O-2-16
V3.1.4
<MINE_PRSNC_CODE>NO</MINE_PRSNC_CODE>
<OPERAT_STAT_CODE>NOP</OPERAT_STAT_CODE>
<OPERAT_STAT_QUAL_CODE>DSTRYD</OPERAT_STAT_QUAL_CODE>
</FAC_STAT>
</FAC_STAT_TBL>
Listing 15. XML Segment for the OBJECT-ITEM-ASSOCIATION table
<OBJ_ITEM_ASSOC_TBL>
<OBJ_ITEM_ASSOC>
<SUBJ_OBJ_ITEM_ID>1</SUBJ_OBJ_ITEM_ID>
<OBJ_OBJ_ITEM_ID>3</OBJ_OBJ_ITEM_ID>
<OBJ_ITEM_ASSOC_IX>1</OBJ_ITEM_ASSOC_IX>
<CAT_CODE>ISPART</CAT_CODE>
<SUBCAT_CODE />
<ACT_TASK_ID>NULL</ACT_TASK_ID>
</OBJ_ITEM_ASSOC>
<OBJ_ITEM_ASSOC>
<SUBCAT_CODE />
</OBJ_ITEM_ASSOC>
<OBJ_ITEM_ASSOC>
<SUBCAT_CODE />
</OBJ_ITEM_ASSOC>
</OBJ_ITEM_ASSOC_TBL>
O-2.2.3 Data Presentation for the End User
O-2.2.3.1 Both the instance tables, as well as the XML segments shown in
Listings 1 through 15 above are somewhat difficult to follow. In practice the user
would not be exposed to these low-level representations of the data as they exist in the
database, but would see the data through the result of a customized SQL query.
O-2.2.3.2 Example 02. ACTION-TEMPORAL-ASSOCIATION
O-2.2.4 Description
O-2.2.4.1 This example shows how the JC3IEDM handles Temporal
Relationships among instances of ACTION.
O-2-17
V3.1.4
O-2.2.4.2 Let's assume that there is an operation going on. For the sake of
this example let's name it Operation Alpha01. The actions listed below have been
specified as part of the main operation Alpha01.
O-2.2.4.3 The principal action is “Create minefield” (Action 7), which
includes several sub-actions: “Carry out reconnaissance” (Action 8 “Do recce”, for
short), “Move stores” (Action 9), “Lay minefield” (Action 10), and “Mark minefield”
(Action 11). Action 9 cannot start until Action 8 is completed, Action 10 cannot start
until Action 9 is at least partially completed, and so on. Figure O-23 depicts the
relations among these actions.
Figure O-23. Graphical Representation of Temporal Relationships Among Subactions
O-2.2.4.4 Although specific times are shown in the figure for purposes of
illustration, there is also a need to specify temporal relationships in a relative way
without recourse to a clock. Even though shown as such, the reader should assume
that the time scale is not marked.
O-2.2.4.5 One may wish to begin the sub-ACTION “Move stores” (Action 9)
60 minutes after the start of action “Create minefield” (Action 7). “Lay minefield”
(Action 10) is to start 60 minutes after “Move stores” (Action 9). The final illustrated
action “Mark minefield” (Action 11) is referenced for its start to Action 10 and its
conclusion is referenced to Action 7. Table O-3 below shows how this information
would be captured in the ACTION-TEMPORAL-ASSOCIATION of the JC3IEDM.
O-2-18
V3.1.4
Table O-3. Use of Temporal Relationships and Offset Intervals
ACTION
action-id
action-category-code
action-name-text
7
9
10
11
ACTION-TASK
ACTION-TASK
ACTION-TASK
ACTION-TASK
Create minefield
Move stores
Lay minefield
Mark minefield
ACTION-TEMPORAL-ASSOCIATION
action-temporalassociationsubject-action-id
action-temporalassociationobject-action-id
action-temporalassociationindex
action-temporalassociation-categorycode
action-temporalassociationreference-duration
9
(move stores)
10
(lay minefield)
11
(mark minefield)
11
(mark minefield)
7
(create minefield)
9
(move stores)
10
(lay minefield)
7
(create minefield)
1
Starts after start of
[60 minutes]
1
[60 minutes]
1
[180 minutes]
1
Ends after end of
[0 minutes]
O-2.2.5 Serialization Using the RDBMS XML Tag Set
O-2.2.5.1 As discussed in the RDBMS XSD Design Annex, the RDBMS
XSD has a structure that exactly parallels all the tables and attributes in the MIP
IEDM. Figure O-24 shows the data structures needed to capture the information
provided in this example (taken from the JC3IEDM).
ACTION
ACTION-TEMPORAL-ASSOCIATION
is-the-subject-of
action-id
action-category-code
action-name-text
is-the-object-of
action-temporal-association-subject-action-id (FK)
action-temporal-association-object-action-id (FK)
action-temporal-association-index
action-temporal-association-category-code
action-temporal-association-reference-duration
Figure O-24. MIP IEDM Data Structures Needed to Specify
Temporal Associations Among Instances of ACTION.
O-2.2.5.2 The XML serialization of Example 02 is, therefore, simply the
expression of the values shown Table O-3, both explicitly and implied, using the
XML tags specified in the RDBMS XSD. Listing 16 below shows the XML segment
corresponding to the entries in the ACTION table.
Listing 16. XML Segment for the ACTION table
<ACT_TBL>
<ACT>
<ACT_ID>7</ACT_ID>
<CAT_CODE>ACTTA</CAT_CODE>
<NAME_TXT>CREATE MINEFIELD</NAME_TXT>
</ACT>
<ACT>
<ACT_ID>8</ACT_ID>
<NAME_TXT>DO RECCE</NAME_TXT>
O-2-19
V3.1.4
</ACT>
<ACT>
<ACT_ID>9</ACT_ID>
<NAME_TXT>MOVE STORES</NAME_TXT>
</ACT>
<ACT>
<ACT_ID>10</ACT_ID>
<NAME_TXT>LAY MINEFIELD</NAME_TXT>
</ACT>
<ACT>
<ACT_ID>11</ACT_ID>
<NAME_TXT>MARK MINEFIELD</NAME_TXT>
</ACT>
</ACT_TBL>
O-2.2.5.3 Similarly, Listing 17 shows the XML segment for the ACTIONTEMPORAL-ASSOCIATION records as shown in Table O-3 above.
Listing 17. XML Segment for the ACTION-TEMPORAL-ASSOCIATION table
<ACT_TMPRL_ASSOC_TBL>
<ACT_TMPRL_ASSOC>
<SUBJ_ACT_ID>9</SUBJ_ACT_ID>
<OBJ_ACT_ID>7</OBJ_ACT_ID>
<ACT_TMPRL_ASSOC_IX>1</ACT_TMPRL_ASSOC_IX>
<CAT_CODE>STRSTR</CAT_CODE>
<REF_DUR>60</REF_DUR>
</ACT_TMPRL_ASSOC>
<ACT_TMPRL_ASSOC>
</ACT_TMPRL_ASSOC>
<ACT_TMPRL_ASSOC>
<CAT_CODE>ENDEND</CAT_CODE>
</ACT_TMPRL_ASSOC>
<ACT_TMPRL_ASSOC>
O-2-20
V3.1.4
</ACT_TMPRL_ASSOC>
</ACT_TMPRL_ASSOC_TBL>
O-2.3 Data Presentation for the End User
O-2.3.1 Both the ACTION-TEMPORAL-ASSOCIATION instance table,
as well as the XML segments shown in Listings 16 and 17 above, are somewhat
difficult to follow. In practice the user would not be exposed to these low-level
representations of the data as they exist in the database, but would see the data
through the result of a customized SQL query. Listing 18 below shows such a query
using the concat and CASE functions supported by MySQL.
Listing 18. Example of an SQL Query to Retrieve the Data from ACTION-TEMPORALASSOCIATION from a JC3IEDM Database Implemented in MySQL
select concat(a.act_id, '-',a.name) as subject_act,
CASE act_tmprl_assoc.cat_code
when 'STRSTR' then 'starts after start of'
when 'ENDEND' then 'ends after end of'
END as temporal_code,
concat(b.act_id, '-',b.name) as object_act,
concat(act_tmprl_assoc.ref_dur,' [min]') as ref_duration
from act as a, act as b, act_tmprl_assoc
where act_tmprl_assoc.subj_act_id = a.act_id and
act_tmprl_assoc.obj_act_id = b.act_id;
O-2.3.2 Table O-4 below shows in tabular form the output of the SQL
query from Listing 18.
Table O-4. Results of the User-Friendly SQL Query shown in Listing 18
SUBJECT_ACT
TEMPORAL_CODE
OBJECT_ACT
REF_DURATION
9-move stores
starts after start of
7-create minefield
60.000
[min]
10-lay minefield
9-move stores
60.000
[min]
11-mark minefield
ends after end of
7-create minefield
11-mark minefield
10-lay minefield
0.000
[min]
180.000
[min]
O-2.4 Summary and Conclusions
The XML instance documents discussed in this Appendix exemplify the use of
the RDBMS XSD specification. They highlight (a) the direct correspondence between
the data contained in the tables of a MIP IEDM-conformant database and its XML
serialization, and (b) the fact that any such instance XML document can be validated
using the RDBMS XSD.
O-2-21
V3.1.4
ANNEX O, APPENDIX 3
WS/OO XSD DESIGN DOCUMENT
O-3.1 Introduction
O-3.1.1 Based on the requirements listed in the previous section, we have
developed a reference MIP WS/OO XSD. Structures in instance XML documents
conforming to the WS/OO XSD closely match the typical OO concepts, e.g.,
inheritance and navigability. In particular, the representation of relationships and
associations via nesting greatly simplifies the adoption of the MIP IEDM in objectoriented applications. To describe (potentially cyclic) graph structures in the tree-like
XML notation, a simple mechanism for referencing objects is provided. Instance
XML documents exchanged in accordance with the WS/OO XSD do not prescribe
any specific storage format, i.e., the WS/OO XML schema abstracts from the
underlying persistence mechanism. This matches with the notion of defining an XML
exchange format. Developers are able to choose any persistence framework, API, or
tool, which simplifies integration. The WS/OO XSD provides an object oriented
payload pattern that is especially convenient for web services, but, does not require a
web services implementation, i.e., can be used with other information exchange
mechanisms.
O-3.1.2 The XML schema is fully automatically derivable from the MIP
IDEF1X model by applying syntactic transformations only. In that way, the
generation is independent from a particular version of the MIP data model. This
approach ensures correctness and minimizes XSD production and maintenance cost.
If we had relied on the specific semantics of a particular version of the MIP data
model to drive the transformations, we would have had to check the mapping rules as
the model changed over time. Moreover, transforms must be traceable – the more we
transform away from the relational model, the more difficult it becomes to specify and
apply the transformation rules and to prove their correctness.
O-3.1.3 The WS/OO XSD is primarily based on the logical view of the
MIP JC3IEDM. The physical view of the data model contains a few additional MIP
DEM-specific attributes and is designed for an RDBMS implementation. However, all
types of web services should be supportable by the WS/OO XSD, which is more
readily accomplished when basing the specification on the semantics of the logical
view of the MIP IEDM.
O-3.1.4 In this section, the mapping rules are described that are applied to
the MIP data model in order to produce the object-oriented XML schema. These rules
create a faithful representation of the model. The focus of the following description is
on what instance XML documents look like rather than on the technical details of the
XML schema definition. The WS/OO XSD comes along with a tool set, such that the
whole transformation process – starting with the MIP data model in ERwin XML
format and ending with the XML schema files – is traceable. The WS/OO XSD and
O-3-1
V3.1.4
the tool set are available at the MIP web site and considered a normative part of the
reference MIP WS/OO XSD specification.
O-3.1.5 For a complete mapping, transformation rules must be defined for
names, domains, entities, attributes, and relationships (including subtyping and
associative entities). Moreover, the root element of XML documents must be
specified. The mapping rules are described in detail in the following subsections. The
MIP XML Working Party worked through a process whereby entity-relationship (ER)
modelling constructs were interpreted into UML and then interpreted into an XML
design pattern.
O-3.2. Naming Conventions
To ensure consistency and reproducibility, naming conventions are needed for
entities, attributes, and the root element visible in instance XML documents, as well
as for simple types, codes, and entity types that only show up in the XML schema
definition. Naming of domains, entity types, and attributes in XML is based on the
logical view rather than on the physical view of the MIP data model. This enhances
readability and comprehension. In accordance with the NATO Naming Guidelines,
the UpperCamelCase convention is used for naming XML elements and XML types,
whereas the lowerCamelCase convention is used for naming XML attributes.
O-3.3. Domains
O-3.3.1 Domains in the ER model are mapped onto XML simple types. The
latter are derived from the pre-defined XML Schema types integer, decimal, and
string. Physical restrictions on JC3IEDM domains, i.e., the number of digits for
integers, the precision and scale of floating point numbers, and the
minimum/maximum length of character strings, are reflected in the XSD. Where
available, specific range restrictions (e.g., minimum temperature or non-negative
quantity) are regarded as well. The upper and lower boundary of numbers is modeled
by the XML Schema attributes minInclusive and maxInclusive. The minimum and
maximum length of strings is modelled by means of the attributes minLength and
maxLength.
O-3.3.2 Codes are represented as strings that are restricted by enumeration.
JC3IEDM code values are specified as physical values rather than display values in an
instance XML document. This is motivated by efficiency with regard to bandwidth,
software development and object persistency. The mapping from the physical values
to their corresponding display values is a matter of national language preference and
can be realized easily by means of an XSL-T script. The display values documented
by the MIP data model (international English) are included as annotations in the XSD
for convenience.
O-3-2
V3.1.4
O-3.4. Entities and Attributes
Figure O-25. Entities and Attributes
O-3.4.1 Entity types in the MIP IEDM are mapped onto complex types in
the XML schema definition. In conformance with the NATO XML Naming and
Design Rules, attributes in the ER model are specified as XML elements, not XML
attributes, exclusively. This simplified approach removes the arbitrary or even
semantic decision about when to use what. Accordingly, an entity is described by an
element with child elements for its attributes in an instance XML document (see
Figure O-25).
O-3.4.2 Optionality of attributes in the MIP IEDM is maintained by means
of the XML Schema minOccurs attribute.
O-3.4.3 Non-key attributes are mapped to XML elements by applying the
above-mentioned naming conventions. Whenever possible, the entity type name,
which is added as a prefix for the attribute names in the logical view, is truncated.
This rule conforms to the class and property conventions used in object-oriented
programming, i.e., the meaning of an XML element is derived from its context.
O-3.4.4 Primary and foreign key attributes (i.e., identifiers and indexes) are
not mapped directly. Instead, the transformation patterns for relationships (see next
section) are applied.
O-3.4.5 Object Identifiers. In the WS/OO XSD, globally unique object
identifiers (OIDs) replace the synthetic primary keys of the MIP data model. The
global uniqueness of OIDs simplifies integration into object-oriented applications. An
OID is a sequence of characters that allows an application locating and managing
(persistent) objects. An OID may be a key generated by some database engine. In the
O-3-3
V3.1.4
context of the world-wide web, an OID may be a URI (Uniform Resource Identifier).
In this case, the OID denotes a web address that can be used to refer and retrieve the
object, and the closure of all IEDM objects forms a localized semantic web of their
own.
O-3.4.5.1 The CreatorID metadata required by the JC3IEDM physical model
is retained as a mandatory element following the OID. While there is a general
understanding that CreatorID shall be used to represent the logical source
organization, there is no referential integrity requirement and thus each nation
implements it as it desires. Regardless, it is retained should a user need it and for
potential future use. A CreatorID is not used in a reference to an existing object, e.g.,
within type <Entity>Ref.
O-3.4.5.2 The UpdateSequenceNo metadata required by the JC3IEDM
physical model is retained as an optional attribute. Current MIR business rules require
it be set to zero, so when not included as part of the OID it is understood to be zero.
Regardless, it is retained for potential future use. An UpdateSequenceNo is not used
in a reference an existing object, e.g., within type <Entity>Ref.
O-3.4.5.3 A MIPKeyType OID subtype is defined to provide for the explicit
reuse and appropriate restriction of OIDs derived from MIP RDBMS systems,
typically when there is the need to refer to this OID at a later time when interacting
with the source data base.
O-3.4.6 In the WS/OO XSD, OIDs are defined for all complex types that
correspond to entity types in the ER model (both independent and dependent entity
types).
O-3.4.7 References. At any place in an instance XML document where it is
possible to specify an entity with an OID (inline), it is also possible to specify a
reference to that entity. Both options are included (a) to provide support for various
instance document styles, (b) to handle graph structures, and (c) to allow for both
referentially complete and incremental update information exchange methods.
O-3.4.8 References are indicated by adding suffix Ref to the name of the
XML element (e.g., UnitRef or ReportingOrganisationRef). Beside its OID, an entity
reference has neither elements (entity attributes) of simple type nor of code type.
However, an entity reference can be used to describe a new relationship of the
referred entity with another one. For instance, a new OrganisationStatus may be
specified inside a UnitRef element (see next section for the modelling of
relationships).
O-3.4.9 Note: XML binding tools/frameworks like JAXB, Castor, or
Commons Betwixt use XML’s ID/IDREF mechanism to serialize graph structures.
However, ID/IDREF can only be used as a referencing mechanism for referentially
complete documents but not when exchanging incremental updates.
O-3.4.10 The XML schema definition is available in two variants: with and
without identity constraints, i.e., checks for internal referential completeness. The
O-3-4
V3.1.4
WS/OO XSD that includes the identity constraints enforces a corresponding entity
definition for every reference. These entities must be defined by a child element of the
root element. The identity constraints are specified in a way that ensures type-safe
referential integrity of instance XML documents (ID/IDREF would not provide typesafety). The constraints are defined as part of the XML root element definition (see
Section O-3.6).
O-3.5. Transformation Rules for Relationships
O-3.5.1. Identifying and Non-Identifying Relationships
O-3.5.1.1 In IDEF1X, the modelling technique and notation used for the MIP
IEDM, there are two basic types of relationships: identifying and non-identifying
relationships. They correspond to one-to-one and one-to-many associations between
classes in UML where the associations may be navigable in either both directions or
one direction. In most cases, a link is established from the parent to its child only.
Figure O-26. Identifying Relationships
O-3.5.1.2 An identifying relationship means that the child cannot be uniquely
identified without the parent. For example, an OBJECT-ITEM-STATUS cannot exist
without its OBJECT-ITEM. In an ER model, an identifying relationship is modelled
by a primary key in the child that is also a foreign key referring to the parent.
O-3.5.1.3 Identifying relationships are modelled in the WS/OO XSD
according to the design pattern shown in Figure O-26: Multiple B and/or BRef
elements are embedded into the parent entity. The cardinality of identifying
O-3-5
V3.1.4
relationships (zero-one-or-more, one-or-more, zero-or-one) is ensured by adding
minOccurs and maxOccurs attributes to the corresponding element definitions in the
XSD.
O-3.5.1.4 If possible, the name of the parent is stripped from the names of the
elements. Example: The one-to-many relationship between an OBJECT-ITEM and an
OBJECT-ITEM-STATUS is modelled in XML by zero, one, or more Status elements.
O-3.5.1.5 Please note that elements that establish a relationship may also
occur within entity references (e.g., within ObjectItemRef). This allows adding
information on new relationships to entities that have been defined/exchanged before.
In entity references, minOccurs is always set to 0.
Figure O-27. Non-Identifying Relationships
O-3.5.1.6 A non-identifying relationship is one where the child can be
identified independently of the parent. For instance, an Organisation can exist
independently from a ReportingData that refers to it as the reporting organization. The
transformation of non-identifying relationships is shown in Figure O-27. The
optionality (null allowed vs. no null) of non-identifying relationships is expressed by
minOccurs attributes in the WS/OO XSD.
O-3-6
V3.1.4
O-3.5.2. Subtype Relationships
Figure O-28. Subtype Relationships
O-3.5.2.1 In instance XML documents, subtyping relationships are
represented by embedding all the attributes from a subtype hierarchy within the tag
corresponding to the leaf entity (see Figure O-28). In the WS/OO XML schema
definition, the complex type for the super entity A is called AbstractA and marked as
abstract, i.e., abstract="true" is added as attribute/value pair to the
complexType element in the XML schema.. The complex types for its sub-entities are
derived from the complex type of the super entity by means of the extension method
of XML Schema. Functional COIs may tailor individual types either by further
extension or by restriction.
O-3.5.2.2 In IDEF1X, the subtype is indicated by a discriminator code
(category code) in the super type. In WS/OO instance XML documents, category
codes do not have to be specified in general, as they are implied by the subtype tag
itself.
O-3.5.2.3 For the incomplete subtyping concept of IDEF1X, there is no direct
counter-part in the OO world. In the case of incomplete subtyping, the discriminator
in the super type may have a code that does not correspond to any of the existing subentities (this holds for codes like NOS – Not Otherwise Specified). Keeping the
discriminator code in the super type would severely limit the use of the WS/OO XSD
for other COIs, because they were not able to add new subtypes to the existing
schema (the set of discriminator codes in the super type is fixed and there is no way to
extend it without redefining the super entity). Therefore, each incomplete subtype
O-3-7
V3.1.4
relationship is transformed into a complete subtype relationship first. This is achieved
by adding a new subentity, called Other<SuperEntityName>, which takes the
discriminator attribute of the super entity. Moreover, to avoid confusion, each super
entity is labeled Abstract<SuperEntityName>.
O-3.5.3. Many-to-Many Relationships – Associative Entities
O-3.5.3.1 In relational models, a many-to-many relationship between two
entities A and B is expressed by an associative entity A-B-ASSOC that is the child of
both A and B via identifying relationships. In the MIP IEDM, all many-to-manyrelationships are binary. Nevertheless, we can distinguish three cases:
•
•
•
Associative entities with only primary key attributes
Associative entities with non-primary key attributes
Double-associative entities
Figure O-29. Associative Entities with PK Attributes Only
O-3.5.3.2 An associative entity with only primary key (PK) attributes is
equivalent in UML to a simple association between the two parent classes. Each
parent may have a multiple references to instances of the other class. This view is also
reflected in the design pattern given in Figure O-29. Associative entities without nonPK attributes are not mapped onto the XML schema. The relationships from parent A
to A-B-ASSOC and from parent B to A-B-ASSOC are mapped as if they were
identifying relationships from A to B and vice versa. Note that since there is no
preferred direction in the association, either entity can be nested inside the other in
XML.
O-3-8
V3.1.4
Figure O-30. Associative Entities with Non-PK Attributes
O-3.5.3.3 If the associative entity has non-primary key attributes, it
corresponds in UML to an attributed association with an association class that
contains the attributes. There are several ways to represent such many-to-many
relationships in XML. For the WS/OO XSD, a design pattern is applied that allows
embedding the association into either parent (see Figure O-30). For that purpose an
element in introduced that consists of the associated second parent of type B and the
associative entity that holds the association attributes.
O-3.5.3.4 The ability to describe associations by nesting rather than by a toplevel element avoids information scattering throughout XML documents and
enhances readability. Moreover, the WS/OO XSD supports object-to-association
reasoning rather than association-to-object reasoning. This is considered as an
important prerequisite for the compact definition of community-specific message
formats that are derived from the generic XSD by tailoring.
O-3.5.3.5 It should be noted that the representation of associations in XML
documents may differ from the internal representation in applications. For instance,
the XML parser of the XML SDK generates Java objects that support navigability in
either directions (A → ABAssoc → B and B →ABAssoc → A).
O-3-9
V3.1.4
Figure O-31. Double-Associative Entities
O-3.5.3.6 There are also associations in which both relationships come from
the same entity type. The generic syntactic transformations for such associations are
similar to the transformations for associative entities with non-PK attributes given
above. The only difference is that the element names include generic role names for
the associated entities (see Figure O-31). Subject and Object are used as (modelindependent) role names. The suffixes are necessary, because in an XML document
the object may be embedded in the subject and vice versa.
O-3.6
XML Root Element
O-3.6.1 The root XML tag is equivalent to the model name in capital letters
(<JC3IEDM>). The distinction between different model versions is made by means of
the name space, whose URN is composed of the following elements separated by
colons:
1.
2.
3.
4.
5.
A MIP/NATO prefix: urn:int:nato:standard:mip
Data model name in lower case: jc3iedm
Data model version
XSD type: oo or rdbms
Schema version
For the JC3IEDM 3.0.2, the WS/OO XSD namespace URN is:
urn:int:nato:standard:mip:jc3iedm:3.0.2:oo:1.0
O-3-10
V3.1.4
O-3.6.2 The root XML element has an arbitrary number of unordered XML
entity definitions as child elements. The names of the child elements are identical to
the
names
of
the
corresponding
entity
types
(e.g.,
Unit
or
ReportingDataAbsoluteTiming).
O-3.6.3 Each child refers to a non-abstract type, i.e., a type that does not
have a subtype. For instance, ObjectItem is abstract whereas MinefieldLand is not. (In
case of incomplete subtyping, the super type can be regarded as non-abstract as well).
References to associations are permitted as top-level elements to allow for status
updates. However, the definition of new associations is only allowed within
identifying entities.
O-3-11
V3.1.4
(This page intentionally left blank)
O-3-12
V3.1.4
ANNEX O, APPENDIX 4
OO/WS USE CASE
O-4.1
Introduction
O-4.1.1 In the following, the use of the object-oriented XML schema is
illustrated by the operational scenario described in chapter 9.6 of the JC3IEDM main
document. For convenience, it is recapitulated in section O-4.2. The modelling of the
vignette by means of the JC3IEDM is described in section O-4.3. Excerpts from the
corresponding instance XML documents are explained in section O-4.4.
O-4.2
Operational Scenario
O-4.2.1 The JC3IEDM main document defines an operational scenario in
which the 1st Canadian Brigade is located near a bridge across the Yukon River. Its
contingency plan is to use this bridge as part of a larger military obstacle, called
Obstacle Alpha.
O-4.2.2 "The White Horse Bridge across the Yukon River initially serves
as a passage between two minefields located on the north side of the river, one on
each side of the bridge. [...] If the units of the joint task force that are now deployed
on the north side of the river need to withdraw, the bridge will be demolished to
become part of the main obstacle."
The operational picture is shown in Figure O-32.
N
Obstacle Alpha
West Minefield
White Horse
East Minefield
Bridge
Yukon
S
Figure O-32. Obstacle Alpha
During the hostilities, the 1st CA Brigade is attacked and the contingency plan is put
into action. The complete course of actions is as follows:
O-4-1
V3.1.4
Reporting Time
22 Oct 2003, 10:30
Action
1 CA Brigade creates the contingency plan to set up Obstacle
Alpha which consists of the two minefields and the bridge to
be demolished.
02 Nov 2003, 09:49 Minefield West is laid and activated.
03 Nov 2003, 15:42 Minefield East is laid and activated.
03 Nov 2003, 17:10 The White Horse Bridge is prepared for demolition.
07 Nov 2003, 08:10
The brigade elements north of the river cross to the south.
The bridge is demolished and Obstacle Alpha becomes
operational in its entirety.
O-4.3 JC3IEDM Modelling
O-4.3.1 In the JC3IEDM, the two minefields are modelled by means of
entity type MINEFIELD-LAND. The White Horse Bridge is an instance of entity type
BRIDGE and Obstacle Alpha is a MILITARY-OBSTACLE.
O-4.3.2 Since all entities are facilities, their statuses are described by means
of entity types OBJECT-ITEM-HOSTILITY-STATUS and FACILITY-STATUS.
Both the White Horse Bridge and Obstacle Alpha have two status objects of each type
assigned to them, because their statuses change over time. Initially, the bridge is
operational and prepared for plan execution while Obstacle Alpha is merely planned.
Once White Horse Bridge is demolished, Obstacle Alpha is declared as operational
and active. All status information is associated with either a REPORTING-DATA or
a REPORTING-DATA-ABSOLUTE-TIMING. The composition of Obstacle Alpha is
modelled by instances of OBJECT-ITEM-ASSOCIATION and OBJECT-ITEMASSOCIATION-STATUS.
O-4.3.3 In JC3IEDM Main, chapter 9.6, only the most relevant entities are
shown. In order to make the example referentially complete, we also model the 1st
CA Brigade (entity UNIT) and associate each OBJECT-ITEM with a suitable type.
Moreover, since OBJECT-ITEM-TYPE relationships are established by a reporting
organization, we assume that there is an intelligence unit that initially registered the
White Horse Bridge on 2 January 2004.
O-4.3.4 The granularity and expressive richness of the JC3IEDM can be
seen by this example. In total, the vignette is modelled by 52 objects. With a
JC3IEDM-compliant RDBMS, the effective number of database records would even
be significantly higher, since, e.g., the information for a land minefield is physically
stored in five different tables (OBJECT-ITEM, FACILITY, MILITARYOBSTACLE, MINEFIELD, and MINEFIELD-LAND).
O-4-2
V3.1.4
O-4.4 Instance XML Documents
Listing 19. Top-Level Elements
<?xml version="1.0" encoding="UTF-8"?>
<JC3IEDM xmlns="urn:int:nato:standard:mip:jc3iedm:3.0.2:oo:1.0" … >
<MinefieldLand>
<OID xsi:type="MIPKeyType">18077000000000000001</OID>
<CreatorId>18077000000000000001</CreatorId>
<UpdateSequenceNo />
...
<IdentificationText>Minefield West</IdentificationText>
<MineSpacingDimension>10</MineSpacingDimension>
<DepthPlacementCode>MIXED</DepthPlacementCode>
<FunctionCode>NUISNC</FunctionCode>
<PatternCode>REGTHK</PatternCode>
<PersistenceCode>REMOTE</PersistenceCode>
<StoppingPowerCode>MEDIUM</StoppingPowerCode>
</MinefieldLand>
<MinefieldLand>
<OID>OI2</OID>
<UpdateSequenceNo>1</UpdateSequenceNo>
<NameText>East Minefield</NameText>
...
</MinefieldLand>
<Bridge>
<OID>OI3</OID>
<NameText>White Horse Bridge</NameText>
...
</Bridge>
<OtherMilitaryObstacle>
<OID>OI4</OID>
<NameText>Obstacle Alpha</NameText>
...
</OtherMilitaryObstacle>
<ReportingDataAbsoluteTiming>
<OID>RPTD695</OID>
...
</ReportingDataAbsoluteTiming>
...
</JC3IEDM>
O-4.4.1 The overall structure of an XML document for the abovementioned vignette is shown in Listing 19 above. It is a referentially complete
document that covers the whole history of Obstacle Alpha.
O-4.4.2 On the top level, the main objects of the operational scenario, i.e.,
West Minefield, East Minefield, White Horse Bridge, Obstacle Alpha, etc. are
defined. Each object is described coherently by a single element rather than by
records in multiple tables as when using the MIP DEM. For instance, all attributes of
a MinefieldLand – including those inherited from entity types Facility and ObjectItem
– are specified at a single place in the document (lines 3–16).
O-4-3
V3.1.4
O-4.4.3 All objects shown above have a globally unique object identifier
(OID). This allows referring to them from a different object in the same XML
document or from another XML document in order to establish an association.
Listing 20. Status Information
<MinefieldLand>
<OID>OI1</OID>
<HostilityStatus>
<OID>HS1</OID>
<Code>FR</Code>
<ReportingDataRef>
<OID>RPTD695</OID>
</ReportingDataRef>
</HostilityStatus>
<ObjectItemTypeInObjectItem>
<ObjectTypeRef>
<OID>OT1</OID>
</ObjectTypeRef>
<ObjectItemType>
<OID>OI1-OT1</OID>
<ReportingDataRef>
<OID>RPTD001</OID>
</ReportingDataRef>
</ObjectItemType>
</ObjectItemTypeInObjectItem>
<Status xsi:type="OtherFacilityStatus">
<OID>FS1</OID>
<ReportingData xsi:type="ReportingDataAbsoluteTiming">
<OID>RPTD701</OID>
<ReportingDataCategoryCode>REP</ReportingDataCategoryCode>
<CredibilityCode>RPTFCT</CredibilityCode>
<ReportingDatetime>20031102094900.000</ReportingDatetime>
...
</ReportingData>
<MinePresenceCode>YES</MinePresenceCode>
<OperationalStatusCode>OPR</OperationalStatusCode>
<UsageStatusCode>ACTIVE</UsageStatusCode>
<CategoryCode>NOS</CategoryCode>
</Status>
...
</MinefieldLand>
O-4.4.4 In the previous excerpt, only the basic attributes were listed for the
West Minefield. In reality, its definition also includes two statuses and a type. In the
JC3IEDM ER model, they are linked to the minefield by means of identifying
relationships and associative entities.
O-4.4.5 The relationship between the West Minefield and its
hostility/facility status is established by embedding the latter into the definition of the
former (lines 6–14 and 28–43). A MinefieldLand can have multiple statuses (one-to-
O-4-4
V3.1.4
zero-one-or-more relationship). In this case, the XML document contains an
unordered sequence of consecutive status elements.
O-4.4.6 By means of nesting, it is not necessary to specify the OID of the
West Minefield within the status definition as required by the JC3IEDM ER model –
the link between both entities is derived implicitly from the document structure.
O-4.4.7 Listing 20 also indicates that all elements have an OID. The
minefield may get a new status later and thus there must be a way to refer to it. In case
of the status objects, the OID may support query-on-demand communication.
Listing 21. References
<MinefieldLand>
<OID>OI1</OID>
...
<OID>FS1</OID>
<OID>RPTD701</OID>
...
<OID>OI6</OID>
...
</ReportingData>
...
</Status>
...
</MinefieldLand>
<Unit>
<OID>OI6</OID>
...
<NameText>1 CA Bde</NameText>
...
<FormalAbbreviatedNameText>1 CA Bde</FormalAbbreviatedNameText>
</Unit>
O-4.4.8 Finally, Listing 21 illustrates the application of the polymorphism
concept. According to the JC3IEDM entity-relationship model (disregarding business
rules), an object item can be associated with any record of the status hierarchy, e.g., a
MedicalFacilityStatus, a PersonStatus, or an (Other)FacilityStatus. Similarly, we can
refer to different kinds of ReportingData (ReportingDataAbsoluteTiming,
ReportingDataRelativeTiming, and (Other)ReportingData) within a status. In order to
support document validation, one has to specify the concrete type that is actually
used. This is done by means of attribute xsi:type (XSI = XML Schema Instance). For
instance, in line 24, we specify xsi:type="ReportingDataAbsoluteTiming” to define a
ReportingData with absolute timing information.
O-4.4.9 Nesting of entities is not restricted to a certain level. In Listing 21,
ReportingData is embedded in the Status element, which again is part of the West
Minefield definition. In principle, structures may become very deeply nested or – in
O-4-5
V3.1.4
case of cyclic dependencies between objects – even infinitely. In these cases, the
reference mechanism can be used which is revealed in Listing 21.
O-4.4.10 For every status update, the reporting organization must be
specified as part of the reporting data. The status of the West Minefield is reported by
the 1st Canadian Brigade. Rather than embedding the ReportingOrganisation inside
the MinefieldLand/StatusList/Status/ ReportingData structure, a reference is made by
means of a ReportingOrganisationRef element (lines 10–12) that only contains the
OID of the organization to which it refers. The unit is defined as a separate top-level
element in the XML document (lines 19–24). In case of a reference, there is no need
to specify the concrete subtype. In the example above, no xsi:type attribute is required
in line 10, although the ReportingOrganisationRef is in fact a reference to a Unit. In
the given example, the 1st Canadian Brigade is specified at the end of the XML
document. However, the XML schema makes no assumptions on the order of toplevel elements, i.e., an object may be defined ahead of its reference.
O-4.4.11 As explained before, there are several possible ways in which
communication may take place. The generic WS/OO XML schema is designed in a
way that it can be used in all scenarios described above.
Listing 22. Incremental Update
<JC3IEDM
xmlns="urn:int:nato:standard:mip:jc3iedm:3.0.2:oo:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:int:nato:standard:mip:jc3iedm:3.0.2:oo:1.0
..\..\schema\JC3IEDM-3.1-Root-20061208.xsd">
<MinefieldLandRef>
<OID>OI1</OID>
<OID>FS1</OID>
...
</ReportingData>
<MinePresenceCode>YES</MinePresenceCode>
<OperationalStatusCode>OPR</OperationalStatusCode>
<UsageStatusCode>ACTIVE</UsageStatusCode>
<CategoryCode>NOS</CategoryCode>
</Status>
</MinefieldLandRef>
</JC3IEDM>
O-4.4.12 In message-based communication, the constraints in the WS/OO
XSD ensure referential integrity within a single XML document: whenever a
reference is made, a corresponding definition must be given. For instance, an XSD
validation tool is able to check that there is indeed a reporting organization for the
minefield status. The corresponding constraints are type-safe, i.e., the schema
validator will complain if you refer to a non-Organization object accidentally.
O-4.4.13 For incremental updates and incomplete queries, the referencing
mechanism can be used to refer to information defined externally. This is illustrated in
Listing 22. In this document, a status update is reported for the object with OID OI1
(= West Minefield). In addition to an OID, an <Entity>Ref element may contain an
O-4-6
V3.1.4
arbitrary number of elements that establish a one-to-many relationship. In that way,
you
can
establish
new
associations
with
existing
objects.
O-4-7
V3.1.4
ANNEX O, APPENDIX 5
MULTILATERAL INTEROPERABILITY PROGRAMME
OPEN SOURCE LICENSE
Copyright © 2009, Multilateral Interoperability Programme (MIP),
https://mipsite.lsec.dnd.ca/Pages/Default.aspx
All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are
permitted provided that the following conditions are met:
Redistributions of source code must retain the above copyright notice, this list
of conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this
list of conditions and the following disclaimer in the documentation and/or
other materials provided with the distribution.
Neither the name of the Multilateral Interoperability Programme nor the
names of its contributors may be used to endorse or promote products derived
from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
OF SUCH DAMAGE.
O-5-1
V3.1.4
O-5-2
V3.1.4
ANNEX O, APPENDIX 6
XML TERMS AND REFERENCES
O-6.1
XML Terms and Definitions
Term
DTD
PIM
UML
XForms
XHTML
XInclude
XML
XML Attribute
XML Base
XML Element
XML Namespace
XML Namespace
identifier (NID)
Definition
Document Type Definition; Schema specification method for
SGML and XML documents. DTDs are either contained in the
document or belong to its external subset and are then referenced
from within the documents DTD per URI.
Platform Independent Models are a foundation for the Object
Management Group’s Model Driven Architecture approach to
system and process definition and forward engineering.
[http://www.omg.org/mda/]
Unified Modeling Language is a specification developed and
maintained by the Object Management Group and is used to model
not only application structure, behavior, and architecture, but also
business process and data structure. [http://www.uml.org/]
Traditional HTML Web forms don't separate the purpose from the
presentation of a form. XForms, in contrast, are comprised of
separate sections that describe what the form does, and how the
form looks.
The Extensible HyperText Markup Language (XHTML™) is a
family of current and future document types and modules that
reproduce, subset, and extend HTML, reformulated in XML.
This specification introduces a generic mechanism for merging
XML documents (as represented by their information sets) for use
by applications that need such a facility.
Extensible Markup Language (XML) is a simple, very flexible text
format derived from SGML (ISO 8879).
XML attribute types are of three kinds: a string type, a set of
tokenized types, and enumerated types.
The attribute xml:base may be inserted in XML documents to
specify a base URI other than the base URI of the document or
external entity. The value of this attribute is interpreted as a URI
Reference as defined in RFC 2396 [IETF RFC 2396].
The element structure of an XML document MAY, for validation
purposes, be constrained using element type and attribute-list
declarations. An element type declaration constrains the element's
content.
See definition above.
For example, URNs begin with two colon-delimited fields, the first
of which is the string urn and the second is the "namespace
identifier" (NID). The Namespace ID determines the syntactic
interpretation of the Namespace Specific String.
O-6-1
V3.1.4
XML Namespace
name
XML Namespace
prefix
XML Namespace
specific string
(NSS)
XML Schema
XPath
XQuery
XSL
XSL-FO
Identifies the namespace; see above.
See definition above.
As required by RFC 1737, there is a single canonical representation
of the NSS portion of an URN.
Specification used to describe the structure of XML documents.
XML Schemas express shared vocabularies and allow machines to
carry out rules made by people. They provide a means for defining
the structure, content and semantics of XML documents. More
powerful than DTDs, because it includes facilities to specify the
data type of elements and it is based on XML.
XPath is a language for addressing parts of an XML document,
designed to be used by both XSLT and XPointer.
Xquery is a query language, which is designed to be broadly
applicable across many types of XML data sources.
XSL is a family of recommendations for defining XML document
transformation and presentation. It consists of three parts: XSLT,
XPath and XSL-FO.
This specification defines the features and syntax for the Extensible
Stylesheet Language (XSL), a language for expressing style sheets.
It consists of two parts:
1. a language for transforming XML documents, and
2. an XML vocabulary for specifying formatting semantics.
XSLT
XSLT is designed for use as part of XSL, which is a stylesheet
language for XML.
O-6-2
V3.1.4
O-6.2 W3C XML Specifications
The following list shows the most important ones in which automatic links are
provided by W3C to other related documents. Another alternative is provided through
search capabilities given directly on the W3C Homepage (http://www.w3.org):
XML Namespaces 1.1
http://www.w3.org/TR/xml-names11
XML 1.1 Specifications
http://www.w3.org/TR/xml11
XML 1.0 Specifications (3rd Edition)
http://www.w3.org/TR/REC-xml
XML Schema Part 0: Primer Second Edition
http://www.w3.org/TR/xmlschema-0/
XML Schema Part 1: Structures Second Edition
XML Schema Part 2: Datatypes Second Edition
O-6.3 OASIS and UN/CEFACT Specifications
Additional open standards (especially regarding ebXML and UBL) are given by:
OASIS ebXML (all documents except the Core Components Technical
Specification - CTTS)
http://www.oasis-open.org
UN/CEFACT CCTS V2.01
http://www.unece.org/cefact/ebxml/CCTS_V2-01_Final.pdf
which is also referred as to be approved ISO/PRF TS 15000-5 Standard (”ISO/PRF
TS 15000-5 ebXML Core Components Technical Specifications V2.01”)
Universal Business Language (UBL 1.0)
http://docs.oasis-open.org/ubl/cd-UBL-1.0/
Universal Business Language Naming and Design Rules
http://www.oasis-open.org/committees/download.php/10323/cd-UBL-NDR1.0Rev1c.pdf
O-6.4
ISO Specifications
O-6.4.1 ISO 11179 - Information Technology – Metadata Registries
(MDR)
ISO/IEC 11179-1:2004(E) (2nd edition)
O-6-3
V3.1.4
Part 1: Framework
ISO/IEC 11179-2:2000(E)
Specification and standardization of data elements -- Part 2: Classification of
data elements.
ISO/IEC 11179-3:2003/Cor 1:2004 – Corrections to ISO/IEC 11179-3:
2003(E)
Part 3: Registry metamodel and basic attributes.
ISO/IEC 11179-4: 2004(E) (2nd edition)
Part 4: Formulation of data definitions
ISO/IEC 11179-5: 2005(E) (2nd edition)
Part 5: Naming and identification principle
ISO/IEC 11179-6:2005 (2nd edition)
Part 6: Registration
All ISO/IEC 11179 standards (hyperlinked to ISO) are available for free at
http://www.metadata-standards.org
O-6.4.2 ISO 15000 - Electronic business eXtensible Markup Language
(ebXML)
ISO/TS 15000-1:2004
Part 1: Collaboration-protocol profile and agreement specification (ebCPP)
(available in English only).
ISO/TS 15000-2:2004
Part 2: Message service specification (ebMS) (available in English only).
ISO/TS 15000-3:2004
Part 3: Registry information model specification (ebRIM) (available in
English only).
ISO/TS 15000-4:2004
Part 4: Registry services specification (ebRS) (available in English only).
The ISO/TS 15000 standards (hyperlinked to ISO) Part 1 - 4 are available for
free at http://www.oasis-open.org
ISO/TS 15000-5:2005.
Part 5: ebXML Core Components Technical Specifications V2.01 (ebCCTS,
see above).
O-6-4
V3.1.4
O-6.5 International XML Naming and Design Documents
DON XML Naming and Design Rules 2.0 (2005).
http://www.doncio.navy.mil/StoreFront/Uploads/0128YRM15241.pdf
UN/CEFACT XML Naming and Design Rules 1.1 (2005, Draft).
http://xml.coverpages.org/ATG2-NamingAndDesignRules200501.pdf
UN/CEFACT XML Naming and Design Rules 1.1a (2005, Draft).
http://www.disa.org/cefactroups/atg/downloads/NamingAndDesignRules_1.1a.pdf
O-6.6 NATO XML Documents
Guidance for XML Registration and Namespace Management within NATO.
Configuration Management Plan for XML Registration and Namespaces within
NATO (V0.6, approved by ISSC).
Quality Assurance Plan for XML Registration and Namespaces within NATO (V0.6,
approved by ISSC).
Guidance for XML Naming and Design within NATO (V0.3.3, Draft under
construction).
The NATO documents can be referred at http://nhqc3s.nato.int/ +Subcommittees
+ISSC XML NMF (Namespace Managers Forum). Userid and password required
from [email protected].
O-6.7 World Wide Web Consortium (W3C)
Web Services Architecture, Working Group Note 11 Feb 2004, at
http://www.w3.org/TR/wsarch/
O-6-5
V3.1.4
O-6-6
V3.1.4
ANNEX O, APPENDIX 7
BLUE FORCE POSITION REPORT SCHEMA (XSD)
Source: Bruce Montgomery, Data Architect, [email protected]
US Army TRADOC Program Integration Office-Battle Command (TPIO-BC). Note: The
XSD patterns shown in the example below are consistent with a deprecated version of the
JC3IEDM WS/OO XSD.
O-7.1 Business Object Schema
O-7.1.1 The concept of defining C2 business objects XSDs as proper subsets of
the JC3IEDM namespace is illustrated below. For example, the relevant XSDs to define a
Blue Force (WMA) Position Report, as a proper subset of the JC3IEDM namespace XSD,
are illustrated by the Figure O-33.
Figure O-33. WMA Position Report XSD relationship to JC3IEDM XSD
O-7.1.2 The WMAPositionReport example XML instance document is shown in
the Listing 23 below (note JC3IEDM xmlns & <OID> details not fully shown):
Listing 23. WMAPositionReport.xml
<JC3IEDM xmlns="urn:int:nato:standard:mip:jc3iedm3.X:oo:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:int:nato:standard:mip:jc3iedm3.X:oo:1
WMAPositionReport.xsd">
<ObjectItemRef>
<OID>ORG2</OID>
<ObjectItemLocationInObjectItemList>
<ObjectItemLocationInObjectItem>
<Location xsi:type="GeographicPoint">
O-7-1
V3.1.4
<OID>POINT1</OID>
<VerticalDistance>
<OID>POINT1</OID>
<ReferenceCode>MNSLVL</ReferenceCode>
<Dimension>-100</Dimension>
</VerticalDistance>
<LatitudeCoordinate>40.36917</LatitudeCoordinate>
<LongitudeCoordinate>74.0008</LongitudeCoordinate>
</Location>
<ObjectItemLocation>
<VerticalAccuracyDimension>10</VerticalAccuracyDimension>
<HorizontalAccuracyDimension>10</HorizontalAccuracyDimension>
<BearingAngle>245</BearingAngle>
<BearingAccuracyAngle>10</BearingAccuracyAngle>
<InclinationAngle>15</InclinationAngle>
<InclinationAccuracyAngle>10</InclinationAccuracyAngle>
<SpeedRate>10</SpeedRate>
<SpeedAccuracyRate>1</SpeedAccuracyRate>
<OID>RPT20</OID>
<CategoryCode>REP</CategoryCode>
<ReportingDatetime>2006-04-25T23:17:55Z</ReportingDatetime>
<OID>ORG2</OID>
</ReportingData>
</ObjectItemLocation>
</ObjectItemLocationInObjectItem>
</ObjectItemLocationInObjectItemList>
</ObjectItemRef>
</JC3IEDM>
O-7.1.3
The WMAPositionReport XSDs documents shown in Listing 24 and 25
below.
Listing 24. WMAPositionReport.xsd
<schema targetNamespace="urn:int:nato:standard:mip:jc3iedm3.X:oo:1.4"
xmlns:jc3iedm="urn:int:nato:standard:mip:jc3iedm3.X:oo:1.4"
xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
attributeFormDefault="unqualified">
<annotation>
<documentation xml:lang="en">XML schema defined by the Multilateral
Interoperability Programme (MIP) - Editor: Dr. Michael Gerz, [email protected], FGAN
FKIE, Germany - Fri Mar 17 01:28:15 CET 2006</documentation>
</annotation>
<include schemaLocation="WMAPositionReportEntities.xsd"/>
<element name="JC3IEDM">
<annotation>
<documentation xml:lang="en">This element MUST be conveyed as the root
element in any instance document based on this schema expression.</documentation>
</annotation>
<complexType>
<choice maxOccurs="unbounded">
<element name="ObjectItemRef" type="jc3iedm:ObjectItemRef"/>
</choice>
</complexType>
</element>
</schema>
O-7-2
V3.1.4
Listing 25. WMAPositionReportEntities.xsd
<schema targetNamespace="urn:int:nato:standard:mip:jc3iedm3.X:oo:1.4"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:jc3iedm="urn:int:nato:standard:mip:jc3iedm3.X:oo:1.4"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<annotation>
<documentation xml:lang="en">XML schema defined by the WMA IWG
DASG</documentation>
</annotation>
<include schemaLocation="JC3IEDMSimpleTypes.xsd"/>
<include schemaLocation="JC3IEDMCodes.xsd"/>
<complexType name="IncSubReportingData" abstract="true">
<annotation>
<documentation xml:lang="en">The specification of source, quality and
timing that applies to reported data.</documentation>
</annotation>
<sequence>
<element name="OID" type="jc3iedm:OIDType">
<annotation>
<documentation xml:lang="en">The globally unique object
identifier.</documentation>
</annotation>
</element>
<element name="AccuracyCode" type="jc3iedm:ReportingDataAccuracyCode"
minOccurs="0">
<annotation>
<documentation xml:lang="en">The specific value that represents, for
intelligence purpose, the general appraisal of the subject matter in graded terms
to indicate the extent or degree to which it has been judged to be free from
mistake or error or to conform to truth or some recognised standard
value.</documentation>
</annotation>
</element>
<element name="CategoryCode" type="jc3iedm:ReportingDataCategoryCode">
<annotation>
usual operational purposes, the nature of a specific REPORTINGDATA.</documentation>
</annotation>
</element>
<element name="CountingIndicatorCode"
type="jc3iedm:ReportingDataCountingIndicatorCode" minOccurs="0">
<annotation>
<documentation xml:lang="en">The specific value that denotes whether
the data referred to by a specific REPORTING-DATA is based on a count of
objects.</documentation>
</annotation>
</element>
<element name="CredibilityCode" type="jc3iedm:ReportingDataCredibilityCode"
minOccurs="0">
<annotation>
normal operational use, the degree of trustworthiness of the data referenced by a
specific REPORTING-DATA.</documentation>
</annotation>
</element>
<element name="ReliabilityCode" type="jc3iedm:ReportingDataReliabilityCode"
minOccurs="0">
<annotation>
intelligence purpose, the general appraisal of the source in graded terms to
indicate the extent to which it has been proven it can be counted on or trusted
in to do as expected.</documentation>
O-7-3
V3.1.4
</annotation>
</element>
<element name="ReportingDatetime" type="jc3iedm:DatetimeTypeFix18">
<annotation>
<documentation xml:lang="en">The character string representing a point
in time that designates when the data referenced by the REPORTING-DATA is
provided.</documentation>
</annotation>
</element>
<element name="SourceTypeCode" type="jc3iedm:ReportingDataSourceTypeCode"
minOccurs="0">
<annotation>
<documentation xml:lang="en">The specific value that identifies the
source type from which intelligence information is obtained and which is referred
to by a specific REPORTING-DATA.</documentation>
</annotation>
</element>
<element name="RealDataExerciseUseOnlyCode"
type="jc3iedm:ReportingDataRealDataExerciseUseOnlyCode" minOccurs="0">
<annotation>
<documentation xml:lang="en">The specific value that determines whether
a specific REPORTING-DATA refers to real data in an exercise
scenario.</documentation>
</annotation>
</element>
<choice>
<element name="ReportingOrganisationRef"
type="jc3iedm:IncSubOrganisationRef">
<annotation>
<documentation xml:lang="en">The ORGANISATION that is responsible for
providing the data that is referenced by the specific REPORTINGDATA.</documentation>
</annotation>
</element>
</choice>
</sequence>
<attribute name="typeCategoryCode" type="NMTOKEN" fixed="Entity"/>
</complexType>
<complexType name="ReportingData">
<annotation>
<documentation xml:lang="en">The specification of source, quality and
timing that applies to reported data.</documentation>
</annotation>
<complexContent>
<extension base="jc3iedm:IncSubReportingData">
<sequence>
<element name="TimingCategoryCode"
type="jc3iedm:ReportingDataTimingCategoryCode">
<annotation>
<documentation xml:lang="en">The specific value that represents the
absolute, uncertain or relative timing for a specific REPORTING-DATA. It serves
as a discriminator that partitions REPORTING-DATA into subtypes.</documentation>
</annotation>
</element>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="VerticalDistance">
<annotation>
<documentation xml:lang="en">A specification of the altitude or height of a
point or a level as measured with respect to a specified reference datum in the
direction normal to the plane that is tangent to the WGS84 ellipsoid of
revolution.</documentation>
</annotation>
O-7-4
V3.1.4
<sequence>
<annotation>
</annotation>
</element>
<element name="ReferenceCode" type="jc3iedm:VerticalDistanceReferenceCode">
<annotation>
reference system for a specific VERTICAL-DISTANCE.</documentation>
</annotation>
</element>
<element name="Dimension" type="jc3iedm:DimensionType12_3">
<annotation>
<documentation xml:lang="en">The one-dimensional linear distance
representing the distance with respect to the specified vertical
datum.</documentation>
</annotation>
</element>
<element name="PrecisionCode" type="jc3iedm:DistancePrecisionCode"
minOccurs="0">
<annotation>
<documentation xml:lang="en">The specific value that denotes the
precision of specifying a VERTICAL-DISTANCE.</documentation>
</annotation>
</element>
<element name="DatumText" type="jc3iedm:TextTypeVar50" minOccurs="0">
<annotation>
<documentation xml:lang="en">The character string assigned to represent
a specific vertical reference datum.</documentation>
</annotation>
</element>
</sequence>
</complexType>
<complexType name="IncSubLocation" abstract="true">
<annotation>
<documentation xml:lang="en">A specification of position and geometry with
respect to a specified horizontal frame of reference and a vertical distance
measured from a specified datum.</documentation>
</annotation>
<sequence>
<annotation>
</annotation>
</element>
</sequence>
</complexType>
<complexType name="Point" abstract="true">
<annotation>
<documentation xml:lang="en">A zero dimensional LOCATION.</documentation>
</annotation>
<complexContent>
<extension base="jc3iedm:IncSubLocation">
<sequence/>
</extension>
</complexContent>
</complexType>
<complexType name="AbsolutePoint" abstract="true">
<annotation>
<documentation xml:lang="en">A POINT in a geodetic system.</documentation>
</annotation>
O-7-5
V3.1.4
<complexContent>
<extension base="jc3iedm:Point">
<sequence>
<choice minOccurs="0">
<element name="VerticalDistance" type="jc3iedm:VerticalDistance">
<annotation>
<documentation xml:lang="en">The vertical distance for a specific
ABSOLUTE-POINT.</documentation>
</annotation>
</element>
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="GeographicPoint">
<annotation>
<documentation xml:lang="en">An ABSOLUTE-POINT that has its position
specified with respect to the surface of the World Geodetic System 1984 (WGS 84)
ellipsoid.</documentation>
</annotation>
<complexContent>
<extension base="jc3iedm:AbsolutePoint">
<sequence>
<element name="LatitudeCoordinate"
type="jc3iedm:LatitudeCoordinateTypeRangeLatitude9_6">
<annotation>
<documentation xml:lang="en">The numeric value that represents the
angle between the plane of the equator and a line perpendicular to the ellipsoid
surface and passing through the GEOGRAPHIC-POINT.</documentation>
</annotation>
</element>
<element name="LongitudeCoordinate"
type="jc3iedm:LongitudeCoordinateTypeRangeLongitude10_6">
<annotation>
<documentation xml:lang="en">The numeric value that represents the
angle between the initial (zero or Greenwich) meridian and the meridian of the
GEOGRAPHIC-POINT measured in the plane of the Equator.</documentation>
</annotation>
</element>
<element name="LatitudePrecisionCode" type="jc3iedm:AnglePrecisionCode"
minOccurs="0">
<annotation>
resolution used for the expression of a value of a latitude
coordinate.</documentation>
</annotation>
</element>
<element name="LongitudePrecisionCode"
type="jc3iedm:AnglePrecisionCode" minOccurs="0">
<annotation>
resolution used for the expression of a value of a longitude
coordinate.</documentation>
</annotation>
</element>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="IncSubObjectItemRef">
<annotation>
<documentation xml:lang="en">A reference to some ObjectItem - An
individually identified object that has military or civilian
significance.</documentation>
O-7-6
V3.1.4
</annotation>
<sequence>
<annotation>
</annotation>
</element>
<element name="ObjectItemLocationInObjectItemList" minOccurs="0">
<complexType>
<annotation>
<documentation xml:lang="en">A list of Location/ObjectItemLocation
pairs.</documentation>
</annotation>
<sequence>
<element name="ObjectItemLocationInObjectItem" maxOccurs="unbounded">
<complexType>
<annotation>
<documentation xml:lang="en">Location/ObjectItemLocation pair.
Location is the child in a 'is-geometrically-defined-through' relationship;
ObjectItemLocation provides additional information on the
relationship.</documentation>
</annotation>
<sequence>
<choice>
<element name="Location" type="jc3iedm:IncSubLocation"/>
</choice>
<element name="ObjectItemLocation"
type="jc3iedm:ObjectItemLocation"/>
</sequence>
<attribute name="typeCategoryCode" type="NMTOKEN"
fixed="Association"/>
</complexType>
</element>
</sequence>
<attribute name="typeCategoryCode" type="NMTOKEN"
fixed="AssociationList"/>
</complexType>
</element>
</sequence>
</complexType>
<complexType name="IncSubOrganisationRef">
<annotation>
<documentation xml:lang="en">A reference to some Organisation - An OBJECTITEM that is an administrative or functional structure.</documentation>
</annotation>
<complexContent>
<extension base="jc3iedm:IncSubObjectItemRef">
<sequence/>
</extension>
</complexContent>
</complexType>
<complexType name="ObjectItemLocation">
<annotation>
<documentation xml:lang="en">An association of an OBJECT-ITEM with a
LOCATION that enables the geographic position of the OBJECT-ITEM to be specified.
The operational meaning of geometry may also be specified.</documentation>
</annotation>
<sequence>
<element name="VerticalAccuracyDimension" type="jc3iedm:DimensionType12_3"
minOccurs="0">
<annotation>
representing the uncertainty in terms of probable error range for the vertical
axis of a specific OBJECT-ITEM-LOCATION.</documentation>
O-7-7
V3.1.4
</annotation>
</element>
<element name="HorizontalAccuracyDimension"
type="jc3iedm:DimensionType12_3" minOccurs="0">
<annotation>
representing the uncertainty in the horizontal plane in terms of probable
circular error for a specific OBJECT-ITEM-LOCATION.</documentation>
</annotation>
</element>
<element name="BearingAngle" type="jc3iedm:AngleTypeRangeAngle7_4"
minOccurs="0">
<annotation>
<documentation xml:lang="en">The rotational measurement clockwise from
the line of true North to the direction of motion in the horizontal plane of a
specific OBJECT-ITEM at a specific LOCATION.</documentation>
</annotation>
</element>
<element name="BearingAccuracyAngle" type="jc3iedm:AngleTypeRangeAngle7_4"
minOccurs="0">
<annotation>
<documentation xml:lang="en">The rotational measurement of a sector
that represents the uncertainty range in the estimate of the bearing at a
specific OBJECT-ITEM-LOCATION. The sector is bisected by the
bearing.</documentation>
</annotation>
</element>
<element name="BearingPrecisionCode" type="jc3iedm:AnglePrecisionCode"
minOccurs="0">
<annotation>
maximum resolution used for the expression of a bearing angle.</documentation>
</annotation>
</element>
<element name="InclinationAngle" type="jc3iedm:AngleTypeRangeAngle7_4"
minOccurs="0">
<annotation>
<documentation xml:lang="en">The rotational measurement from the
horizontal plane to the direction of motion of a specific OBJECT-ITEM at a
specific LOCATION (point or shape), where the positive angle is vertically
upward.</documentation>
</annotation>
</element>
<element name="InclinationAccuracyAngle"
type="jc3iedm:AngleTypeRangeAngle7_4" minOccurs="0">
<annotation>
<documentation xml:lang="en">The rotational measurement of a vertical
sector that represents the uncertainty range in the estimate of the inclination
at a specific OBJECT-ITEM-LOCATION. The sector is bisected by the
inclination.</documentation>
</annotation>
</element>
<element name="InclinationPrecisionCode" type="jc3iedm:AnglePrecisionCode"
minOccurs="0">
<annotation>
maximum resolution used for the expression of an inclination
angle.</documentation>
</annotation>
</element>
<element name="SpeedRate" type="jc3iedm:RateType8_4" minOccurs="0">
<annotation>
<documentation xml:lang="en">The numeric value that denotes the motion
of a specific OBJECT-ITEM at a specific LOCATION in terms of distance per unit
time. The unit of measure is kilometres per hour.</documentation>
O-7-8
V3.1.4
</annotation>
</element>
<element name="SpeedAccuracyRate" type="jc3iedm:RateType8_4" minOccurs="0">
<annotation>
<documentation xml:lang="en">The numeric value that denotes the
uncertainty range in the estimate for the speed at a specific OBJECT-ITEMLOCATION where the speed estimate falls at the centre of the accuracy range. The
unit of measure is kilometres per hour.</documentation>
</annotation>
</element>
<element name="SpeedPrecisionCode" type="jc3iedm:SpeedPrecisionCode"
minOccurs="0">
<annotation>
maximum resolution used for the expression of speed.</documentation>
</annotation>
</element>
<element name="MeaningCode" type="jc3iedm:ObjectItemLocationMeaningCode"
minOccurs="0">
<annotation>
meaning of the LOCATION geometry as it pertains to the OBJECTITEM.</documentation>
</annotation>
</element>
<choice>
<element name="ReportingData" type="jc3iedm:IncSubReportingData">
<annotation>
<documentation xml:lang="en">The REPORTING-DATA.</documentation>
</annotation>
</element>
</choice>
</sequence>
</complexType>
<complexType name="ObjectItemRef">
<annotation>
<documentation xml:lang="en">A reference to some ObjectItem - An
individually identified object that has military or civilian
significance.</documentation>
</annotation>
<complexContent>
<extension base="jc3iedm:IncSubObjectItemRef">
<sequence/>
</extension>
</complexContent>
</complexType>
</schema>
O-7-9

JC3IEDM-Annex O-XML-3.1.4.doc

Transcription

Similar documents

Batch Production of Driving Distances and Times Using SAS® and

FHA Update for REALTORS

TOURISTIC BROCHURE 2015

jc3iedm overview - MIP Public Home

information exchange policy vocabulary (iepv)

LavaCon Final Program.book

How I learned to love XML! (FME Certified Professional, Peter

gs, and XSL - Université de Moncton

JC3IEDM Metamodel

Mahsa - Department of Computer Science

with the cover page - École des Mines de Saint

Register File Generation - uni

Improving network mobility in HAP networks

JC3IEDM-Main-3.1.4

trident - URBA 2000