annex o. extensible markup language (xml ... document library/99...2009/05/14 · jc3iedm - annex o...

JC3IEDM - Annex O - DMWG 20090514

Edition 3.0.2

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


Edition 3.0.2

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


Edition 3.0.2

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 mark-up 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


Edition 3.0.2

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.

3.2.2 – Exchange Mechanism /Information Repository

XML technologies are widely used in on-line repositories providing managed access to multiple national or multinational users at distributed locations.

3.2.3 – Exchange Mechanism /Information Push

Document XSDs are the modern equivalent of electronic message specifications. XML instance documents enable user and machine-readable 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).

3.2.4 – Exchange Mechanism /Electronic Messaging

See 3.2.3.

3.2.5 – Exchange Mechanism /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


Edition 3.0.2

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 Service-Oriented 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


Edition 3.0.2

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


Edition 3.0.2

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


Edition 3.0.2

O3.2.3 To achieve combined and joint integrated capabilities in the network-enabled 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


Edition 3.0.2

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 TST-unique 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 (ATP-45) 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


Edition 3.0.2

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


Edition 3.0.2

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-TYPE OBJECT-ITEM-LOCATION

OBJECT-ITEM-TYPE

OBJECT-ITEM-ALIAS

ORGANISATION

UNIT

REPORTING-DATA

REPORTING-DATA-ABSOLUTE-TIMING

LOCATION

POINT

ABSOLUTE-POINT

GEOGRAPHIC-POINT

VERTICAL-DISTANCE

LINE

LINE-POINT

SURFACE

POLYGON-AREA

OBJECT-ITEM

MATERIEL

CONTEXT

CONTEXT-ELEMENT

Figure O-6. Blue Force Position JC3IEDM View

O-11


Edition 3.0.2

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 DETAILS FOR ORGANIZATION, e.g., speed, heading> </LOCATION #2> . . . . . <LOCATION #n> <LOCATION LAT&LONG> <LOCATION DETAILS FOR ORGANIZATION, e.g., speed, heading> </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

XML(RDBMS)

National Non-MIP System

JC3IEDM I/F EMEM Non-MIP DB I/FXSLT

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


Edition 3.0.2

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) MIP Common Interface (MCI) EM EM XML

(RDBMS)

Figure O-8. XEM Use Case


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. XML documents have flat structure e. Referential integrity & business rules are ensured by the RDBMS or at

the application level

O3.4.3 Web Services/Object-Oriented (WS/OO) O3.4.3.1 The use case is illustrated in Figure O-9. The potential application

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

JC3IEDMWeb

Services (EM)

Non-MIP system

XML(OO)

XSLT XSLT

Figure O-9. Web Services/Object-Oriented Use Case


a. XML tag set is derived from the IEDM logical view b. XML documents capture the IEDM in an Object Oriented structure

O-13


Edition 3.0.2

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) O3.4.4.1 The use case is illustrated in Figure O-10. The potential application

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.

COI JC3IEDM XML Business Object

Exchange Mechanism

COI System n

System n Internal Model

COI System 1

System 1 Internal Model XSLT XSLT

XML (OO,

RDBMS)

XML (OO,

RDBMS)

Figure O-10. Business Object Exchange Use Case


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 O3.4.5.1 The use case is illustrated in Figure O-11. The potential application

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 ExchangeStandard/System

JC3IEDM I/F Non-MIPExchange

TransformTechnology

XML(RDBMS,

OO)

EM1 EM2EM1

Figure O-11. Tactical Communications Interface Use Case

O-14


Edition 3.0.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 O3.4.6.1 The use case is illustrated in Figure O-12. The potential application

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.

C2IEDMMediationService or

XSLTXML

(RDBMS,OO)

EM1 JC3IEDMEM1 XML(RDBMS,

OO)

EM2 EM2

Figure O-12. Mediation Use Case


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


Edition 3.0.2

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 entity-relationship 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 sub-typing 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


Edition 3.0.2

RDBMS instance document fragment WS/OO instance document fragment <?xml version="1.0" encoding= "UTF8 "?> <JC3IEDM_RDBMS> <OBJ_TYPE_TBL> <OBJ_TYPE> <OBJ_TYPE_ID>343545</OBJ_TYPE_ID> <CAT_CODE>FA</CAT_CODE> <DUMMY_IND_CODE>NO</DUMMY_IND_CODE> <NAME_TXT>LandMinefield</NAME_TXT> </OBJ_TYPE> </OBJ_TYPE_TBL> <OBJ_ITEM_TBL> <OBJ_ITEM> <OBJ_ITEM_ID>223432</OBJ_ITEM_ID> <CAT_CODE>FA</CAT_CODE> <NAME_TXT>West Minefield</NAME_TXT> </OBJ_ITEM> </OBJ_ITEM_TBL> <FAC_TBL> <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> <MIL_OBS_TBL> <MIL_OBS> <MIL_OBS_ID>223432</MIL_OBS_ID> <CAT_CODE>MNFLD</CAT_CODE> </MIL_OBS> </MIL_OBS_TBL> <MNFLD_TBL> <MNFLD> <MNFLD_ID>223432</MNFLD_ID> <CAT_CODE>MNFLND</CAT_CODE> <MINE_SPACING_DIM>10.000 </MINE_SPACING_DIM> </MNFLD> </MNFLD_TBL> <MNFLD_LAND_TBL> <MNFLD_LAND> <MNFLD_LAND_ID>223432</MNFLD_LAND_ID> <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_RDBMS>

<?xml version="1.0" encoding="UTF8"?> <JC3IEDM> <MinefieldLand> <OID>223432</OID> <NameText>West Minefield</NameText> <ObjectItemTypeInObjectItem> <ObjectTypeRef> <OID>343545</OID> </ObjectTypeRef> <ObjectItemType> <ReportingDataRef> <OID>RPTD001</OID> </ReportingDataRef> </ObjectItemType> </ ObjectItemTypeInObjectItem > <StatusList>…</StatusList> <LengthDimension>300</LengthDimension> <WidthDimension>105</WidthDimension> <MineSpacingDimension>10</MineSpacingDimension> <DepthPlacementCode>MIXED </DepthPlacementCode> <FunctionCode>NUISNC</FunctionCode> <PatternCode>REGTHK</PatternCode> <PersistenceCode>REMOTE</PersistenceCode> <StoppingPowerCode>MEDIUM </StoppingPowerCode> </MinefieldLand> <MilitaryObstacleType> <OID>343545</OID> <DummyIndicatorCode>NO</DummyIndicatorCode> <NameText>LandMinefield</NameText> <CategoryCode>MINEFD</CategoryCode> </MilitaryObstacleType> </JC3IEDM>

Object ID

Primary Key

Foreign Key

Foreign Key

Foreign Key

Foreign Key

Figure O-13. Minefield Establishment Report Distributed (ER) vs Aggregated (WS/OO) Information

O-17


Edition 3.0.2

ER instance document fragment WS/OO instance document fragment <?xml version= »1.0 » encoding="UTF8" ?> <JC3IEDM_RDBMS> <OBJ_ITEM_TBL> <OBJ_ITEM> <OBJ_ITEM_ID>223432</OBJ_ITEM_ID> <CAT_CODE>FA</CAT_CODE> <NAME_TXT> West Minefield </NAME_TXT> </OBJ_ITEM> </OBJ_ITEM_TBL> <OBJ_ITEM_STAT_TBL> <OBJ_ITEM_STAT> <OBJ_ITEM_ID>223432</OBJ_ITEM_ID> <OBJ_ITEM_STAT_IX>1</OBJ_ITEM_STAT_IX> <CAT_CODE>FA</CAT_CODE> <HSTLY_CODE>FR</HSTLY_CODE> <RPTD_ID>222701</RPTD_ID> </OBJ_ITEM_STAT> </OBJ_ITEM_STAT_TBL> <RPTD_TBL> <RPTD> <RPTD_ID>222701</RPTD_ID> <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> <OBJ_ITEM_TYPE_TBL> <OBJ_ITEM_TYPE> <OBJ_ITEM_ID>223432</OBJ_ITEM_ID> <OBJ_TYPE_ID>343545</OBJ_TYPE_ID> <OBJ_ITEM_TYPE_IX>1</OBJ_ITEM_TYPE_IX> <RPTD_ID>714</RPTD_ID> </OBJ_ITEM_TYPE> </OBJ_ITEM_TYPE_TBL> <OBJ_TYPE_TBL> <OBJ_TYPE> <OBJ_TYPE_ID>343545</OBJ_TYPE_ID> <CAT_CODE>FA</CAT_CODE> <DUMMY_IND_CODE>NO</DUMMY_IND_CODE> <NAME_TXT> LandMinefield </NAME_TXT> </OBJ_TYPE> </OBJ_TYPE_TBL> … </JC3IEDM_RDBMS>

<?xml version="1.0" encoding="UTF8" ?> <JC3IEDM> <MinefieldLand> <OID>223432</OID> <NameText>West Minefield</NameText> < ObjectItemTypeInObjectItem> <ObjectTypeRef> <OID>343545</OID> </ObjectTypeRef> <ObjectItemType> <ReportingDataRef> <OID>RPTD001</OID> </ReportingDataRef> </ObjectItemType> </ ObjectItemTypeInObjectItem> <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> <MilitaryObstacleType> <OID>343545</OID> <DummyIndicatorCode>NO</DummyIndicatorCode> <NameText>LandMinefield</NameText> <CategoryCode>MINEFD</CategoryCode> </MilitaryObstacleType> </JC3IEDM>

Nested structure

Primary Key

Foreign Key

Object ID

Association by

Flat Structure

Association via key reference

Figure O-14 Minefield Status Report Object IDs Supplant Keys and Associations Made through Nested References

O-18


Edition 3.0.2

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 The following assumptions underlie the RDBMS schema design:

a. 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-to-machine interface

b. Communication procedures preserve referential integrity:

O-19


Edition 3.0.2

(1) Replication-based methods preserve database keys

O5.1.3 Entity-Relationship Use Case: Specific Considerations

O5.1.3.1 The RDBMS XSD is built according to the following set of syntactic transformation rules:

(1) 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.

(2) 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

(3) 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. The name of the element is formed by appending to the physical table name the string “_TBL”, e.g., <ACT_TBL>.

O-20


Edition 3.0.2

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 names of these elements are identical with the physical column names, e.g., <ACT_ID>, <CAT_CODE>.

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

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


Edition 3.0.2

(3) Systems that rely on XSD validation to enforce business rules,

(4) Gateways that mediate between MIP and Non-MIP-compliant systems,

(5) People. b. 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-and-answer” 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


Edition 3.0.2

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

b. Communication procedures:

O-23


Edition 3.0.2

(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


Edition 3.0.2

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


Edition 3.0.2

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 namespace-qualified 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


Edition 3.0.2

O-27

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.


Edition 3.0.2

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) data-in-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 entity-relationship 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


Edition 3.0.2

It should be noted that although the primary focus of these use cases is RDBMS-to-RDBMS 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)

MIP Communication Interface(MCI)EMEM XML

(RDBMS)

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 XML documents have flat structure

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


Edition 3.0.2

National Non-MIP SystemNational MIP System

XML(RDBMS)JC3IEDM I/F EMEM Non-MIP DB I/FXSLT

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 XML documents have flat structure • 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. Both the sender/receiver of the instance XML documents: (1) Maintain a MIP-compliant RDBMS (2) Are applications, not persons b. Communication procedures preserve referential integrity: (1) Replication-based methods preserve database keys (2) Message/Document-based methods can refer to

external information c. 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, time-consuming 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


Edition 3.0.2

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, replication-based 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 non-MIP 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 XML-based 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


Edition 3.0.2

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 system-independent. 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-to-one 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


Edition 3.0.2

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

Foreign Key (FK) from A to B Key of B depends on FK

Non-Identifying One-to-Many

B C

Foreign Key (FK) from C to B Key of B does not depend on FK

Sub-Type Relationship

A

D

Foreign Key (FK) from A to D Key of D is identical to FK

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


Edition 3.0.2

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


Edition 3.0.2

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: (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

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


Edition 3.0.2

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: (1) Entities (2) Attributes (optional and mandatory) (3) Relationships (4) Subtyping (5) Associations (taking into account their multiplicities) d. 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


Edition 3.0.2

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


Edition 3.0.2

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


Edition 3.0.2

<documentation xml:lang="en">The character string assigned to represent a specific ACTION.</documentation> </annotation> </element> <element name="CREATOR_ID" type="jc3iedm: IdentifierType20" minOccurs="1" maxOccurs="1"> <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" minOccurs="1" maxOccurs="1"> <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


Edition 3.0.2

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


Edition 3.0.2

O-1-14

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.


Edition 3.0.2

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-ITEM-

STATUS

This example shows how the JC3IEDM (a) uses OBJECT-ITEM-ASSOCIATION 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


Edition 3.0.2

Yukon River

West Minefield East MinefieldWhite Horse

Bridge

Obstacle Alpha

S

N

Yukon River

West Minefield East MinefieldWhite Horse

Bridge

Obstacle Alpha

S

N

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-name-text facility-

id facility-category-

code facility-height-

dimension

facility-length-

dimension

facility-width-

dimension

West Minefield 1 MILITARY-OBSTACLE — 300 105

East Minefield 2 MILITARY-OBSTACLE — 320 90

Obstacle Alpha 3 MILITARY-OBSTACLE — 650 325

White Horse Bridge 4 BRIDGE — 200 10

(b) BRIDGE

bridge-id bridge-longest-span-length-dimension

bridge-span-count

bridge-usage-code

4 40 5 Railway/vehicle

O-2-2


Edition 3.0.2

(c) MILITARY-OBSTACLE military-obstacle-id military-obstacle-category-code

1 MINEFIELD 2 MINEFIELD 3 NOS

(d) MINEFIELD

minefield-id

minefield-category-code

minefield-identification-text

minefield-mine-

spacing-dimension

minefield-destruction-

datetime

1 MINEFIELD-LAND MNFLD-WEST 10 (m) — 2 MINEFIELD-LAND MNFLD-EAST 10 (m) —

(e) MINEFIELD-LAND

minefield-land-id

minefield-land-depth-

placement-code minefield-land-function-code

minefield-land-pattern-code

minefield-land-

persistence-code

minefield-land

stopping-power-code

1 Mixed Nuisance Regular minefield, thickened with

scattered mines

Remote activated

destruction

Medium

2 Mixed Nuisance Regular minefield, thickened with

scattered mines

Remote activated

destruction

Medium

(f) OBJECT-ITEM-HOSTILITY-STATUS

object-item-id object-item-index

object-item-hostility-status-code

reporting data-id

1[Minefield West] 1 Friend 700 2 [Minefield East] 1 Friend 700 3 [Obstacle Alpha] 1 Friend 700

4 [White Horse Bridge] 1 Friend 700

(g) OBJECT-ITEM-STATUS

object-item-id *-index *-category-code

*-booby-trap-presence-

code

*-emission-control-

code

reporting data-id

1[Minefield West] 1 FACILITY-STATUS — — 701 2 [Minefield East] 1 FACILITY-STATUS — — 702 3 [Obstacle Alpha] 1 FACILITY-STATUS — — 703

4 [White Horse Bridge] 1 FACILITY-STATUS — — 704 4 [White Horse Bridge] 2 FACILITY-STATUS — — 705

3 [Obstacle Alpha] 2 FACILITY-STATUS — — 705 Note * = “object-item-status”

O-2-3


Edition 3.0.2

(h) FACILITY-STATUS

facility-status-id

object-item-

status-index

**-category-code

**-demolition-status-code

**-mine-presence

-code

**-operational-status-code

**-operational-

status-qualifier-

code

**-usage-status-code

1[Minefield West] 1 Not otherwise

specified — Yes Operational — Activated

2 [Minefield East] 1 Not otherwise


3 [Obstacle Alpha] 1 Not otherwise

specified — Yes Not

operational Prepared for

execution —

4 [White Horse Bridge] 1 Not otherwise

specified Prepared for

execution No Operational Passable —

4 [White Horse Bridge] 2 Not otherwise

specified Executed No Not

operational Destroyed —

3 [Obstacle Alpha] 2 Not otherwise


Note: ** = “facility-status”

(i) OBJECT-ITEM-ASSOCIATION ***-subject-object-item-

id ***-object-object-

item-id ***-

index ***-category-

code ***-subcategory-

code

1[Minefield West] 3 [Obstacle Alpha] 1 Is part of — 2 [Minefield East] 3 [Obstacle Alpha] 1 Is part of —

4 [White Horse Bridge] 3 [Obstacle Alpha] 1 Is part of —

(j) OBJECT-ITEM-ASSOCIATION-STATUS ***-subject-

object-item-id ***-object-

object-item-id ***

-index ***-association-

status-index ***-status-

category-code reporting-

data-id 1 3 1 1 Start association 711 2 3 1 1 Start association 711 4 3 1 1 Start association 711 1 3 1 2 Start association 712 2 3 1 2 Start association 712 4 3 1 2 Start association 712

Note: *** = “object-item-association”

(k) REPORTING-DATA

*-id *-category-code

*-counting-indicator-

code *-credibility-code *-reporting-datetime

*-timing-category-

code *-reporting-

organisation-id

700 Reported — Reported as a fact 20031022103000.000 [absolute] [1 CA Bde] 701 Reported — Reported as a fact 20031102094900.000 [absolute] [1 CA Bde] 702 Reported — Reported as a fact 20031103154200.000 [absolute] [1 CA Bde] 703 Planned — Reported as a fact 20031022103000.000 Timing not

available [1 CA Bde]

704 Reported — Reported as a fact 20031103171000.000 Timing not available

[1 CA Bde]

705 Reported — Reported as a fact 20031107081000.000 [absolute] [1 CA Bde] 711 Planned — Reported as a fact 20031022103000.000 Timing not

available [1 CA Bde]

712 Reported — Reported as a fact 20031107081000.000 [absolute] [1 CA Bde] Note: * = “reporting-data”

O-2-4


Edition 3.0.2

(l) REPORTING-DATA-ABSOLUTE-TIMING **reporting-data-id **-effective-start-datetime **-effective-end-datetime

700 20031022103000.000 — 701 20031102094500.000 — 702 20031103153000.000 — 705 20031107080000.000 — 712 20031107080000.000 —

Note: ** = “reporting-data-absolute-timing”

Note: The data for OBJECT-TYPE, OBJECT-ITEM-TYPE, and ORGANISATION has been omitted.

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


Edition 3.0.2

object-item-category-code

facility-category-code

military-obstacle-category-code

minefield-category-code

object-item-status-category-code

reporting-data-timing-category-code

OBJECT-ITEM

object-item-id

object-item-category-codeobject-item-name-text OBJECT-ITEM-HOSTILITY-STATUS

object-item-id (FK)object-item-hostility-status-index

object-item-hostility-status-codereporting-data-id (FK)

BRIDGE

bridge-id (FK)

bridge-longest-span-length-dimensionbridge-span-countbridge-usage-code

FACILITY

fac ility-id (FK)

facility-category-codefacility-primary-construction-material-codefacility-base-identification-code-textfac ility-height-dimensionfacility-length-dimensionfacility-width-dimensionfacility-major-building-type-id (FK)

MILITARY-OBSTACLE

military-obstacle-id (FK)

military-obstacle-category-code

MINEFIELD

minefield-id (FK)

minefield-category-codeminefield-identification-textminefield-mine-spacing-dimensionminefield-destruction-datetime

MINEFIELD-LAND

minefield-land-id (FK)

minefield-land-depth-placement-codeminefield-land-function-codeminefield-land-pattern-codeminefield-land-persistence-codeminefield-land-stopping-power-code

FACILITY-STATUS

fac ility-status-id (FK)object-item-status-index (FK)

facility-status-category-codefacility-status-demolition-status-codefacility-status-enemy-activity-condition-codefacility-status-mine-presence-codefacility-status-occupation-program-indicator-codefacility-status-operational-status-codefacility-status-operational-status-qualifier-codefacility-status-reserve-indicator-codefacility-status-security-status-codefacility-status-usage-status-code

OBJECT-ITEM-ASSOCIATION-STATUS

object-item-association-subject-object-item-id (FK)object-item-association-object-object-item-id (FK)object-item-association-index (FK)object-item-association-status-index

object-item-association-status-category-codereporting-data-id (FK)

OBJECT-ITEM-ASSOCIATION

object-item-association-subject-object-item-id (FK)object-item-association-object-object-item-id (FK)object-item-association-index

object-item-association-category-codeobject-item-association-subcategory-codeaction-task-id (FK)

REPORTING-DATA

reporting-data-id

reporting-data-accuracy-codereporting-data-category-codereporting-data-counting-indicator-codereporting-data-credibility-codereporting-data-reliability-codereporting-data-reporting-datetimereporting-data-source-type-codereporting-data-timing-category-codereporting-data-real-data-exerc ise-use-only-codereference-id (FK)reporting-data-reporting-organisation-id (FK)

REPORTING-DATA-ABSOLUTE-T IMING

reporting-data-absolute-timing-reporting-data-id (FK)

reporting-data-absolute-timing-effective-start-datetimereporting-data-absolute-timing-effective-end-datetime

OBJECT-ITEM-TYPE

object-item-id (FK)object-type-id (FK)object-item-type-index

reporting-data-id (FK)

OBJECT-TYPE

object-type-id

object-type-category-codeobject-type-decoy-indicator-codeobject-type-name-text

ORGANISATION

organisation-id (FK)

organisation-category-code

OBJECT-ITEM-STATUS

object-item-id (FK)object-item-status-index

object-item-status-category-codeobject-item-status-booby-trap-presence-codeobject-item-status-emission-control-codereporting-data-id (FK)

is-c lassified-as

P

has /is-ascribed-to

is-the-object-ofis-the-subject-of

has /is-ascribed-to

provides-applicable-information-for /is-referenced-to has /

is-ascribed-to P

provides-applicable-information-for /is-referenced-to

is-the-reporting-agent-for /is-reported-by



is-used-as-a-c lassification-for

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> <OBJ_ITEM_ID>1</OBJ_ITEM_ID> <CAT_CODE>FA</CAT_CODE> <NAME_TXT>WEST MINEFIELD</NAME_TXT> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </OBJ_ITEM> <OBJ_ITEM> <OBJ_ITEM_ID>2</OBJ_ITEM_ID>

O-2-6


Edition 3.0.2

<CAT_CODE>FA</CAT_CODE> <NAME_TXT>EAST MINEFIELD</NAME_TXT> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </OBJ_ITEM> <OBJ_ITEM> <OBJ_ITEM_ID>3</OBJ_ITEM_ID> <CAT_CODE>FA</CAT_CODE> <NAME_TXT>OBSTACLE ALPHA</NAME_TXT> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </OBJ_ITEM> <OBJ_ITEM> <OBJ_ITEM_ID>4</OBJ_ITEM_ID> <CAT_CODE>FA</CAT_CODE> <NAME_TXT>WHITE HORSE BRIDGE</NAME_TXT> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </OBJ_ITEM> <OBJ_ITEM> <OBJ_ITEM_ID>5</OBJ_ITEM_ID> <CAT_CODE>OR</CAT_CODE> <NAME_TXT>1 CA BDE</NAME_TXT> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </OBJ_ITEM> </OBJ_ITEM_TBL>

Listing 2. XML Segment for the OBJECT-TYPE table <OBJ_TYPE_TBL> <OBJ_TYPE> <OBJ_TYPE_ID>1</OBJ_TYPE_ID> <CAT_CODE>FA</CAT_CODE> <DUMMY_IND_CODE>NO</DUMMY_IND_CODE> <NAME_TXT>MINE</NAME_TXT> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </OBJ_TYPE> <OBJ_TYPE> <OBJ_TYPE_ID>2</OBJ_TYPE_ID> <CAT_CODE>FA</CAT_CODE> <DUMMY_IND_CODE>NO</DUMMY_IND_CODE> <NAME_TXT>MILITARY OBSTACLE</NAME_TXT> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </OBJ_TYPE> <OBJ_TYPE> <OBJ_TYPE_ID>3</OBJ_TYPE_ID> <CAT_CODE>FA</CAT_CODE> <DUMMY_IND_CODE>NO</DUMMY_IND_CODE> <NAME_TXT>BRIDGE</NAME_TXT> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </OBJ_TYPE> <OBJ_TYPE> <OBJ_TYPE_ID>4</OBJ_TYPE_ID> <CAT_CODE>OR</CAT_CODE> <DUMMY_IND_CODE>NO</DUMMY_IND_CODE> <NAME_TXT>BRIGADE</NAME_TXT> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </OBJ_TYPE> </OBJ_TYPE_TBL>

O-2-7


Edition 3.0.2

Listing 3. XML Segment for the FACILITY table <FAC_TBL> <FAC> <FAC_ID>1</FAC_ID> <CAT_CODE>MILOBS</CAT_CODE> <PRIM_CONST_MATRL_CODE>EARTH</PRIM_CONST_MATRL_CODE> <BASE_IDENTIFIC_CODE_TXT /> <HEIGHT_DIM>0.000</HEIGHT_DIM> <LENGTH_DIM>300.000</LENGTH_DIM> <WIDTH_DIM>105.000</WIDTH_DIM> <FAC_MAJOR_BUILDING_TYPE_ID>NULL</FAC_MAJOR_BUILDING_TYPE_ID> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </FAC> <FAC> <FAC_ID>2</FAC_ID> <CAT_CODE>MILOBS</CAT_CODE> <PRIM_CONST_MATRL_CODE>EARTH</PRIM_CONST_MATRL_CODE> <BASE_IDENTIFIC_CODE_TXT /> <HEIGHT_DIM>0.000</HEIGHT_DIM> <LENGTH_DIM>320.000</LENGTH_DIM> <WIDTH_DIM>90.000</WIDTH_DIM> <FAC_MAJOR_BUILDING_TYPE_ID>NULL</FAC_MAJOR_BUILDING_TYPE_ID> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </FAC> <FAC> <FAC_ID>3</FAC_ID> <CAT_CODE>NOS</CAT_CODE> <PRIM_CONST_MATRL_CODE>NOS</PRIM_CONST_MATRL_CODE> <BASE_IDENTIFIC_CODE_TXT /> <HEIGHT_DIM>0.000</HEIGHT_DIM> <LENGTH_DIM>650.000</LENGTH_DIM> <WIDTH_DIM>325.000</WIDTH_DIM> <FAC_MAJOR_BUILDING_TYPE_ID>NULL</FAC_MAJOR_BUILDING_TYPE_ID> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </FAC> <FAC> <FAC_ID>4</FAC_ID> <CAT_CODE>BRIDGE</CAT_CODE> <PRIM_CONST_MATRL_CODE>STELMT</PRIM_CONST_MATRL_CODE> <BASE_IDENTIFIC_CODE_TXT /> <HEIGHT_DIM>0.000</HEIGHT_DIM> <LENGTH_DIM>200.000</LENGTH_DIM> <WIDTH_DIM>10.000</WIDTH_DIM> <FAC_MAJOR_BUILDING_TYPE_ID>NULL</FAC_MAJOR_BUILDING_TYPE_ID> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </FAC> </FAC_TBL>

Listing 4. XML Segment for the MILITARY-OBSTACLE table <MIL_OBS_TBL> <MIL_OBS> <MIL_OBS_ID>1</MIL_OBS_ID> <CAT_CODE>MNFLD</CAT_CODE> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </MIL_OBS> <MIL_OBS> <MIL_OBS_ID>2</MIL_OBS_ID> <CAT_CODE>MNFLD</CAT_CODE> <CREATOR_ID>121</CREATOR_ID>

O-2-8


Edition 3.0.2

<UPDATE_SEQNR>1</UPDATE_SEQNR> </MIL_OBS> <MIL_OBS> <MIL_OBS_ID>3</MIL_OBS_ID> <CAT_CODE>NOS</CAT_CODE> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </MIL_OBS> </MIL_OBS_TBL>

Listing 5. XML Segment for the MINEFIELD table <MNFLD_TBL> <MNFLD> <MNFLD_ID>1</MNFLD_ID> <CAT_CODE>MNFLND</CAT_CODE> <IDENTIFIC_TXT>MNFLD-WEST</IDENTIFIC_TXT> <MINE_SPACING_DIM>10.000</MINE_SPACING_DIM> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </MNFLD> <MNFLD> <MNFLD_ID>2</MNFLD_ID> <CAT_CODE>MNFLND</CAT_CODE> <IDENTIFIC_TXT>MNFLD-EAST</IDENTIFIC_TXT> <MINE_SPACING_DIM>10.000</MINE_SPACING_DIM> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </MNFLD> </MNFLD_TBL>

Listing 6. XML Segment for the MINEFIELD-LAND table <MNFLD_LAND_TBL> <MNFLD_LAND> <MNFLD_LAND_ID>1</MNFLD_LAND_ID> <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> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </MNFLD_LAND> <MNFLD_LAND> <MNFLD_LAND_ID>2</MNFLD_LAND_ID> <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> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </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> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR>

O-2-9


Edition 3.0.2

</BRIDGE> </BRIDGE_TBL>

Listing 8. XML Segment for the ORGANISATION table <ORG_TBL> <ORG> <ORG_ID>5</ORG_ID> <CAT_CODE>NOS</CAT_CODE> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </ORG> </ORG_TBL>

Listing 9. XML Segment for the REPORTING-DATA table <RPTD_TBL> <RPTD> <RPTD_ID>700/RPTD_ID> <ACC_CODE>1</ACC_CODE> <CAT_CODE>REP</CAT_CODE> <CNTG_IND_CODE>NO</CNTG_IND_CODE> <CREDIBILITY_CODE>RPTFCT</CREDIBILITY_CODE> <RELIABILITY_CODE /> <REP_DTTM>20031102093000.000</REP_DTTM> <SOURCE_TYPE_CODE /> <TIMING_CAT_CODE>RDABST</TIMING_CAT_CODE> <REAL_DATA_EXER_USE_ONLY_CODE /> <REF_ID>NULL</REF_ID> <REP_ORG_ID>5</REP_ORG_ID> <ENT_CAT_CODE>OISTAT</ENT_CAT_CODE> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </RPTD> <RPTD> <RPTD_ID>701</RPTD_ID> <ACC_CODE>1</ACC_CODE> <CAT_CODE>REP</CAT_CODE> <CNTG_IND_CODE>NO</CNTG_IND_CODE> <CREDIBILITY_CODE>RPTFCT</CREDIBILITY_CODE> <RELIABILITY_CODE /> <REP_DTTM>20031102094900.000</REP_DTTM> <SOURCE_TYPE_CODE /> <TIMING_CAT_CODE>RDABST</TIMING_CAT_CODE> <REAL_DATA_EXER_USE_ONLY_CODE /> <REF_ID>NULL</REF_ID> <REP_ORG_ID>5</REP_ORG_ID> <ENT_CAT_CODE>OISTAT</ENT_CAT_CODE> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </RPTD> <RPTD> <RPTD_ID>702</RPTD_ID> <ACC_CODE>1</ACC_CODE> <CAT_CODE>REP</CAT_CODE> <CNTG_IND_CODE>NO</CNTG_IND_CODE> <CREDIBILITY_CODE>RPTFCT</CREDIBILITY_CODE> <RELIABILITY_CODE /> <REP_DTTM>20031103154200.000</REP_DTTM> <SOURCE_TYPE_CODE /> <TIMING_CAT_CODE>RDABST</TIMING_CAT_CODE> <REAL_DATA_EXER_USE_ONLY_CODE /> <REF_ID>NULL</REF_ID> <REP_ORG_ID>5</REP_ORG_ID> <ENT_CAT_CODE>OISTAT</ENT_CAT_CODE> <CREATOR_ID>121</CREATOR_ID>

O-2-10


Edition 3.0.2

<UPDATE_SEQNR>1</UPDATE_SEQNR> </RPTD> <RPTD> <RPTD_ID>703</RPTD_ID> <ACC_CODE>1</ACC_CODE> <CAT_CODE>PLAN</CAT_CODE> <CNTG_IND_CODE>NO</CNTG_IND_CODE> <CREDIBILITY_CODE>RPTFCT</CREDIBILITY_CODE> <RELIABILITY_CODE /> <REP_DTTM>20031022103000.000</REP_DTTM> <SOURCE_TYPE_CODE /> <TIMING_CAT_CODE>TIMNA</TIMING_CAT_CODE> <REAL_DATA_EXER_USE_ONLY_CODE /> <REF_ID>NULL</REF_ID> <REP_ORG_ID>5</REP_ORG_ID> <ENT_CAT_CODE>OISTAT</ENT_CAT_CODE> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </RPTD> <RPTD> <RPTD_ID>704</RPTD_ID> <ACC_CODE>1</ACC_CODE> <CAT_CODE>REP</CAT_CODE> <CNTG_IND_CODE>NO</CNTG_IND_CODE> <CREDIBILITY_CODE>RPTFCT</CREDIBILITY_CODE> <RELIABILITY_CODE /> <REP_DTTM>20031103171000.000</REP_DTTM> <SOURCE_TYPE_CODE /> <TIMING_CAT_CODE>TIMNA</TIMING_CAT_CODE> <REAL_DATA_EXER_USE_ONLY_CODE /> <REF_ID>NULL</REF_ID> <REP_ORG_ID>5</REP_ORG_ID> <ENT_CAT_CODE>OISTAT</ENT_CAT_CODE> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </RPTD> <RPTD> <RPTD_ID>705</RPTD_ID> <ACC_CODE>1</ACC_CODE> <CAT_CODE>REP</CAT_CODE> <CNTG_IND_CODE>NO</CNTG_IND_CODE> <CREDIBILITY_CODE>RPTFCT</CREDIBILITY_CODE> <RELIABILITY_CODE /> <REP_DTTM>20031107081000.000</REP_DTTM> <SOURCE_TYPE_CODE /> <TIMING_CAT_CODE>RDABST</TIMING_CAT_CODE> <REAL_DATA_EXER_USE_ONLY_CODE /> <REF_ID>NULL</REF_ID> <REP_ORG_ID>5</REP_ORG_ID> <ENT_CAT_CODE>OISTAT</ENT_CAT_CODE> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </RPTD> <RPTD> <RPTD_ID>711</RPTD_ID> <ACC_CODE>1</ACC_CODE> <CAT_CODE>PLAN</CAT_CODE> <CNTG_IND_CODE>NO</CNTG_IND_CODE> <CREDIBILITY_CODE>RPTFCT</CREDIBILITY_CODE> <RELIABILITY_CODE /> <REP_DTTM>20031022103000.000</REP_DTTM> <SOURCE_TYPE_CODE /> <TIMING_CAT_CODE>TIMNA</TIMING_CAT_CODE> <REAL_DATA_EXER_USE_ONLY_CODE /> <REF_ID>NULL</REF_ID>

O-2-11


Edition 3.0.2

<REP_ORG_ID>5</REP_ORG_ID> <ENT_CAT_CODE>OISTAT</ENT_CAT_CODE> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </RPTD> <RPTD> <RPTD_ID>712</RPTD_ID> <ACC_CODE>1</ACC_CODE> <CAT_CODE>REP</CAT_CODE> <CNTG_IND_CODE>NO</CNTG_IND_CODE> <CREDIBILITY_CODE>RPTFCT</CREDIBILITY_CODE> <RELIABILITY_CODE /> <REP_DTTM>20031107081000.000</REP_DTTM> <SOURCE_TYPE_CODE /> <TIMING_CAT_CODE>RDABST</TIMING_CAT_CODE> <REAL_DATA_EXER_USE_ONLY_CODE /> <REF_ID>NULL</REF_ID> <REP_ORG_ID>5</REP_ORG_ID> <ENT_CAT_CODE>OISTAT</ENT_CAT_CODE> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </RPTD> <RPTD> <RPTD_ID>714</RPTD_ID> <ACC_CODE>1</ACC_CODE> <CAT_CODE>REP</CAT_CODE> <CNTG_IND_CODE>NO</CNTG_IND_CODE> <CREDIBILITY_CODE>RPTFCT</CREDIBILITY_CODE> <RELIABILITY_CODE /> <REP_DTTM>20031101110000.000</REP_DTTM> <SOURCE_TYPE_CODE /> <TIMING_CAT_CODE>TIMNA</TIMING_CAT_CODE> <REAL_DATA_EXER_USE_ONLY_CODE /> <REF_ID>NULL</REF_ID> <REP_ORG_ID>5</REP_ORG_ID> <ENT_CAT_CODE>OITYPE</ENT_CAT_CODE> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </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 /> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </RPTD_ABS_TIMING> <RPTD_ABS_TIMING> <RPTD_ABS_TIMING_RPTD_ID>702</RPTD_ABS_TIMING_RPTD_ID> <EFFCTV_START_DTTM>20031103153000.000</EFFCTV_START_DTTM> <EFFCTV_END_DTTM /> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </RPTD_ABS_TIMING> <RPTD_ABS_TIMING> <RPTD_ABS_TIMING_RPTD_ID>705</RPTD_ABS_TIMING_RPTD_ID> <EFFCTV_START_DTTM>20031107080000.000</EFFCTV_START_DTTM> <EFFCTV_END_DTTM /> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </RPTD_ABS_TIMING>

O-2-12


Edition 3.0.2

<RPTD_ABS_TIMING> <RPTD_ABS_TIMING_RPTD_ID>712</RPTD_ABS_TIMING_RPTD_ID> <EFFCTV_START_DTTM>20031107080000.000</EFFCTV_START_DTTM> <EFFCTV_END_DTTM /> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </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_ID>1</OBJ_ITEM_ID> <OBJ_TYPE_ID>1</OBJ_TYPE_ID> <OBJ_ITEM_TYPE_IX>1</OBJ_ITEM_TYPE_IX> <RPTD_ID>714</RPTD_ID> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </OBJ_ITEM_TYPE> <OBJ_ITEM_TYPE> <OBJ_ITEM_ID>2</OBJ_ITEM_ID> <OBJ_TYPE_ID>1</OBJ_TYPE_ID> <OBJ_ITEM_TYPE_IX>1</OBJ_ITEM_TYPE_IX> <RPTD_ID>714</RPTD_ID> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </OBJ_ITEM_TYPE> <OBJ_ITEM_TYPE> <OBJ_ITEM_ID>3</OBJ_ITEM_ID> <OBJ_TYPE_ID>2</OBJ_TYPE_ID> <OBJ_ITEM_TYPE_IX>1</OBJ_ITEM_TYPE_IX> <RPTD_ID>714</RPTD_ID> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </OBJ_ITEM_TYPE> <OBJ_ITEM_TYPE> <OBJ_ITEM_ID>4</OBJ_ITEM_ID> <OBJ_TYPE_ID>3</OBJ_TYPE_ID> <OBJ_ITEM_TYPE_IX>1</OBJ_ITEM_TYPE_IX> <RPTD_ID>714</RPTD_ID> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </OBJ_ITEM_TYPE> <OBJ_ITEM_TYPE> <OBJ_ITEM_ID>5</OBJ_ITEM_ID> <OBJ_TYPE_ID>4</OBJ_TYPE_ID> <OBJ_ITEM_TYPE_IX>1</OBJ_ITEM_TYPE_IX> <RPTD_ID>714</RPTD_ID> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </OBJ_ITEM_TYPE> </OBJ_ITEM_TYPE_TBL>

Listing 12. XML Segment for the OBJECT-ITEM-STATUS table <OBJ_ITEM_STAT_TBL> <OBJ_ITEM_STAT> <OBJ_ITEM_ID>1</OBJ_ITEM_ID> <OBJ_ITEM_STAT_IX>1</OBJ_ITEM_STAT_IX> <CAT_CODE>FA</CAT_CODE> <BOOBY_TRAP_PRSNC_CODE /> <EMSN_CTRL_CODE /> <RPTD_ID>701</RPTD_ID> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR>

O-2-13


Edition 3.0.2

</OBJ_ITEM_STAT> <OBJ_ITEM_STAT> <OBJ_ITEM_ID>2</OBJ_ITEM_ID> <OBJ_ITEM_STAT_IX>1</OBJ_ITEM_STAT_IX> <CAT_CODE>FA</CAT_CODE> <BOOBY_TRAP_PRSNC_CODE /> <EMSN_CTRL_CODE /> <RPTD_ID>702</RPTD_ID> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </OBJ_ITEM_STAT> <OBJ_ITEM_STAT> <OBJ_ITEM_ID>3</OBJ_ITEM_ID> <OBJ_ITEM_STAT_IX>1</OBJ_ITEM_STAT_IX> <CAT_CODE>FA</CAT_CODE> <BOOBY_TRAP_PRSNC_CODE /> <EMSN_CTRL_CODE /> <RPTD_ID>703</RPTD_ID> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </OBJ_ITEM_STAT> <OBJ_ITEM_STAT> <OBJ_ITEM_ID>3</OBJ_ITEM_ID> <OBJ_ITEM_STAT_IX>2</OBJ_ITEM_STAT_IX> <CAT_CODE>FA</CAT_CODE> <BOOBY_TRAP_PRSNC_CODE /> <EMSN_CTRL_CODE /> <RPTD_ID>705</RPTD_ID> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </OBJ_ITEM_STAT> <OBJ_ITEM_STAT> <OBJ_ITEM_ID>4</OBJ_ITEM_ID> <OBJ_ITEM_STAT_IX>1</OBJ_ITEM_STAT_IX> <CAT_CODE>FA</CAT_CODE> <BOOBY_TRAP_PRSNC_CODE /> <EMSN_CTRL_CODE /> <RPTD_ID>704</RPTD_ID> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </OBJ_ITEM_STAT> <OBJ_ITEM_STAT> <OBJ_ITEM_ID>4</OBJ_ITEM_ID> <OBJ_ITEM_STAT_IX>2</OBJ_ITEM_STAT_IX> <CAT_CODE>FA</CAT_CODE> <BOOBY_TRAP_PRSNC_CODE /> <EMSN_CTRL_CODE /> <RPTD_ID>705</RPTD_ID> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </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_ID>1</OBJ_ITEM_ID> <OBJ_ITEM_HSTLY_STAT_IX>1</OBJ_ITEM_HSTLY_STAT_IX> <CODE>FR</CODE> <RPTD_ID>701</RPTD_ID> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </OBJ_ITEM_HSTLY_STAT> <OBJ_ITEM_HSTLY_STAT>

O-2-14


Edition 3.0.2

<OBJ_ITEM_ID>2</OBJ_ITEM_ID> <OBJ_ITEM_HSTLY_STAT_IX>1</OBJ_ITEM_HSTLY_STAT_IX> <CODE>FR</CODE> <RPTD_ID>702</RPTD_ID> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </OBJ_ITEM_HSTLY_STAT> <OBJ_ITEM_HSTLY_STAT> <OBJ_ITEM_ID>3</OBJ_ITEM_ID> <OBJ_ITEM_HSTLY_STAT_IX>1</OBJ_ITEM_HSTLY_STAT_IX> <CODE>FR</CODE> <RPTD_ID>703</RPTD_ID> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </OBJ_ITEM_HSTLY_STAT> <OBJ_ITEM_HSTLY_STAT> <OBJ_ITEM_ID>3</OBJ_ITEM_ID> <OBJ_ITEM_HSTLY_STAT_IX>1</OBJ_ITEM_HSTLY_STAT_IX> <CODE>FR</CODE> <RPTD_ID>705</RPTD_ID> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </OBJ_ITEM_HSTLY_STAT> <OBJ_ITEM_HSTLY_STAT> <OBJ_ITEM_ID>4</OBJ_ITEM_ID> <OBJ_ITEM_HSTLY_STAT_IX>1</OBJ_ITEM_HSTLY_STAT_IX> <CODE>FR</CODE> <RPTD_ID>704</RPTD_ID> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </OBJ_ITEM_HSTLY_STAT> <OBJ_ITEM_HSTLY_STAT> <OBJ_ITEM_ID>4</OBJ_ITEM_ID> <OBJ_ITEM_HSTLY_STAT_IX>1</OBJ_ITEM_HSTLY_STAT_IX> <CODE>FR</CODE> <RPTD_ID>705</RPTD_ID> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </OBJ_ITEM_HSTLY_STAT> </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> <OBJ_ITEM_STAT_IX>1</OBJ_ITEM_STAT_IX> <CAT_CODE>NOS</CAT_CODE> <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> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </FAC_STAT> <FAC_STAT> <FAC_STAT_ID>2</FAC_STAT_ID> <OBJ_ITEM_STAT_IX>1</OBJ_ITEM_STAT_IX> <CAT_CODE>NOS</CAT_CODE> <DMLTN_STAT_CODE />

O-2-15


Edition 3.0.2

<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> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </FAC_STAT> <FAC_STAT> <FAC_STAT_ID>3</FAC_STAT_ID> <OBJ_ITEM_STAT_IX>1</OBJ_ITEM_STAT_IX> <CAT_CODE>NOS</CAT_CODE> <DMLTN_STAT_CODE /> <ENEMY_ACTV_COND_CODE /> <MINE_PRSNC_CODE>YES</MINE_PRSNC_CODE> <OCPTN_PROG_IND_CODE /> <OPERAT_STAT_CODE>NOP</OPERAT_STAT_CODE> <OPERAT_STAT_QUAL_CODE>PRPEXE</OPERAT_STAT_QUAL_CODE> <RESERVE_IND_CODE /> <SECURITY_STAT_CODE /> <USAGE_STAT_CODE /> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </FAC_STAT> <FAC_STAT> <FAC_STAT_ID>3</FAC_STAT_ID> <OBJ_ITEM_STAT_IX>2</OBJ_ITEM_STAT_IX> <CAT_CODE>NOS</CAT_CODE> <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>PASABL</OPERAT_STAT_QUAL_CODE> <RESERVE_IND_CODE /> <SECURITY_STAT_CODE /> <USAGE_STAT_CODE /> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </FAC_STAT> <FAC_STAT> <FAC_STAT_ID>4</FAC_STAT_ID> <OBJ_ITEM_STAT_IX>1</OBJ_ITEM_STAT_IX> <CAT_CODE>NOS</CAT_CODE> <DMLTN_STAT_CODE>PRPEXE</DMLTN_STAT_CODE> <ENEMY_ACTV_COND_CODE /> <MINE_PRSNC_CODE>NO</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 /> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </FAC_STAT> <FAC_STAT> <FAC_STAT_ID>4</FAC_STAT_ID> <OBJ_ITEM_STAT_IX>2</OBJ_ITEM_STAT_IX> <CAT_CODE>NOS</CAT_CODE> <DMLTN_STAT_CODE>EXECTD</DMLTN_STAT_CODE> <ENEMY_ACTV_COND_CODE />

O-2-16


Edition 3.0.2

<MINE_PRSNC_CODE>NO</MINE_PRSNC_CODE> <OCPTN_PROG_IND_CODE /> <OPERAT_STAT_CODE>NOP</OPERAT_STAT_CODE> <OPERAT_STAT_QUAL_CODE>DSTRYD</OPERAT_STAT_QUAL_CODE> <RESERVE_IND_CODE /> <SECURITY_STAT_CODE /> <USAGE_STAT_CODE>ACTIVE</USAGE_STAT_CODE> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </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> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </OBJ_ITEM_ASSOC> <OBJ_ITEM_ASSOC> <SUBJ_OBJ_ITEM_ID>2</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> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </OBJ_ITEM_ASSOC> <OBJ_ITEM_ASSOC> <SUBJ_OBJ_ITEM_ID>4</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> <CREATOR_ID>121</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </OBJ_ITEM_ASSOC> </OBJ_ITEM_ASSOC_TBL>

O-2.2.3 Data Presentation for the End User 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.3 Example 02. ACTION-TEMPORAL-ASSOCIATION

O-2.3.1 Description O-2.3.1.1 This example shows how the JC3IEDM handles Temporal

Relationships among instances of ACTION.

O-2-17


Edition 3.0.2

O-2.3.1.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.3.1.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.3.1.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.3.1.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


Edition 3.0.2

Table O-3. Use of Temporal Relationships and Offset Intervals ACTION

action-id action-category-code action-name-text 7 ACTION-TASK Create minefield 9 ACTION-TASK Move stores

10 ACTION-TASK Lay minefield 11 ACTION-TASK Mark minefield

ACTION-TEMPORAL-ASSOCIATION

action-temporal-association-

subject-action-id


object-action-id


index

action-temporal-association-category-

code


reference-duration 9

(move stores) 7

(create minefield) 1 Starts after start of [60 minutes]

10 (lay minefield)

9 (move stores)

1 Starts after start of [60 minutes]

11 (mark minefield)

10 (lay minefield)

1 Starts after start of [180 minutes]

11 (mark minefield)

7 (create minefield)

1 Ends after end of [0 minutes]

O-2.3.2 Serialization Using the RDBMS XML Tag Set O-2.3.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-24 shows the data structures needed to capture the information provided in this example (taken from the JC3IEDM).

is-the-subject-of

is-the-object-of

ACTIONaction-id

action-category-codeaction-name-text

ACTION-TEMPORAL-ASSOCIATIONaction-temporal-association-subject-action-id (FK)action-temporal-association-object-action-id (FK)action-temporal-association-index

action-temporal-association-category-codeaction-temporal-association-reference-duration

Figure O-24. MIP IEDM Data Structures Needed to Specify Temporal Associations Among Instances of ACTION.

O-2.3.2.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> <CREATOR_ID>122</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </ACT> <ACT> <ACT_ID>8</ACT_ID> <CAT_CODE>ACTTA</CAT_CODE> <NAME_TXT>DO RECCE</NAME_TXT> <CREATOR_ID>122</CREATOR_ID>

O-2-19


Edition 3.0.2

<UPDATE_SEQNR>1</UPDATE_SEQNR> </ACT> <ACT> <ACT_ID>9</ACT_ID> <CAT_CODE>ACTTA</CAT_CODE> <NAME_TXT>MOVE STORES</NAME_TXT> <CREATOR_ID>122</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </ACT> <ACT> <ACT_ID>10</ACT_ID> <CAT_CODE>ACTTA</CAT_CODE> <NAME_TXT>LAY MINEFIELD</NAME_TXT> <CREATOR_ID>122</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </ACT> <ACT> <ACT_ID>11</ACT_ID> <CAT_CODE>ACTTA</CAT_CODE> <NAME_TXT>MARK MINEFIELD</NAME_TXT> <CREATOR_ID>122</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </ACT> </ACT_TBL>

O-2.3.2.3 Similarly, Listing 17 shows the XML segment for the ACTION-TEMPORAL-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> <CREATOR_ID>122</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </ACT_TMPRL_ASSOC> <ACT_TMPRL_ASSOC> <SUBJ_ACT_ID>10</SUBJ_ACT_ID> <OBJ_ACT_ID>9</OBJ_ACT_ID> <ACT_TMPRL_ASSOC_IX>1</ACT_TMPRL_ASSOC_IX> <CAT_CODE>STRSTR</CAT_CODE> <REF_DUR>60</REF_DUR> <CREATOR_ID>122</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </ACT_TMPRL_ASSOC> <ACT_TMPRL_ASSOC> <SUBJ_ACT_ID>11</SUBJ_ACT_ID> <OBJ_ACT_ID>7</OBJ_ACT_ID> <ACT_TMPRL_ASSOC_IX>1</ACT_TMPRL_ASSOC_IX> <CAT_CODE>ENDEND</CAT_CODE> <REF_DUR>0</REF_DUR> <CREATOR_ID>122</CREATOR_ID> <UPDATE_SEQNR>1</UPDATE_SEQNR> </ACT_TMPRL_ASSOC> <ACT_TMPRL_ASSOC> <SUBJ_ACT_ID>11</SUBJ_ACT_ID> <OBJ_ACT_ID>10</OBJ_ACT_ID> <ACT_TMPRL_ASSOC_IX>1</ACT_TMPRL_ASSOC_IX> <CAT_CODE>STRSTR</CAT_CODE> <REF_DUR>180</REF_DUR> <CREATOR_ID>122</CREATOR_ID>

O-2-20


Edition 3.0.2

O-2-21

<UPDATE_SEQNR>1</UPDATE_SEQNR> </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-TEMPORAL-ASSOCIATION 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 starts after start of 9-move stores 60.000 [min]

11-mark minefield ends after end of 7-create minefield 0.000 [min]

11-mark minefield starts after start of 10-lay minefield 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.


Edition 3.0.2

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 object-oriented 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


Edition 3.0.2

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


Edition 3.0.2

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


Edition 3.0.2

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


Edition 3.0.2

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 type-safety). 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


Edition 3.0.2

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


Edition 3.0.2

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 sub-entities (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


Edition 3.0.2

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-many-relationships 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 non-PK 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


Edition 3.0.2

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 top-level 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


Edition 3.0.2

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 (model-independent) 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. A MIP/NATO prefix: urn:int:nato:standard:mip 2. Data model name in lower case: jc3iedm 3. Data model version 4. XSD type: oo or rdbms 5. 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


Edition 3.0.2

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


Edition 3.0.2

O-3-12

(This page intentionally left blank)


Edition 3.0.2

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

Yukon

West Minefield East Minefield White Horse

Obstacle Alpha

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


Edition 3.0.2

Reporting Time Action

22 Oct 2003, 10:30 1 CA Brigade creates the contingency plan to set up ObstacleAlpha 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-ITEM-ASSOCIATION-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, MILITARY-OBSTACLE, MINEFIELD, and MINEFIELD-LAND).

O-4-2


Edition 3.0.2

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 /> <NameText>West Minefield</NameText> ... <LengthDimension>300</LengthDimension> <WidthDimension>105</WidthDimension> <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> <CreatorId>18077000000000000001</CreatorId> <UpdateSequenceNo>1</UpdateSequenceNo> <NameText>East Minefield</NameText> ... </MinefieldLand> <Bridge> <OID>OI3</OID> <CreatorId>18077000000000000001</CreatorId> <NameText>White Horse Bridge</NameText> ... </Bridge> <OtherMilitaryObstacle> <OID>OI4</OID> <CreatorId>18077000000000000001</CreatorId> <NameText>Obstacle Alpha</NameText> ... </OtherMilitaryObstacle> <ReportingDataAbsoluteTiming> <OID>RPTD695</OID> <CreatorId>18077000000000000111</CreatorId> ... </ReportingDataAbsoluteTiming> ... </JC3IEDM>

O-4.4.1 The overall structure of an XML document for the above-

mentioned 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


Edition 3.0.2

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> <CreatorId>18077000000000000001</CreatorId> <NameText>West Minefield</NameText> <HostilityStatus> <OID>HS1</OID> <CreatorId>18077000000000000001</CreatorId> <Code>FR</Code> <ReportingDataRef> <OID>RPTD695</OID> </ReportingDataRef> </HostilityStatus> <ObjectItemTypeInObjectItem> <ObjectTypeRef> <OID>OT1</OID> </ObjectTypeRef> <ObjectItemType> <OID>OI1-OT1</OID> <CreatorId>18077000000000000001</CreatorId> <ReportingDataRef> <OID>RPTD001</OID> </ReportingDataRef> </ObjectItemType> </ObjectItemTypeInObjectItem> <Status xsi:type="OtherFacilityStatus"> <OID>FS1</OID> <ReportingData xsi:type="ReportingDataAbsoluteTiming"> <OID>RPTD701</OID> <CreatorId>18077000000000000001</CreatorId> <ReportingDataCategoryCode>REP</ReportingDataCategoryCode> <CredibilityCode>RPTFCT</CredibilityCode> <ReportingDatetime>20031102094900.000</ReportingDatetime> ... </ReportingData> <MinePresenceCode>YES</MinePresenceCode> <OperationalStatusCode>OPR</OperationalStatusCode> <UsageStatusCode>ACTIVE</UsageStatusCode> <CategoryCode>NOS</CategoryCode> </Status> <LengthDimension>300</LengthDimension> <WidthDimension>105</WidthDimension> ... </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


Edition 3.0.2

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> <NameText>West Minefield</NameText> ... <Status xsi:type="OtherFacilityStatus"> <OID>FS1</OID> <CreatorId>18077000000000000001</CreatorId> <ReportingData xsi:type="ReportingDataAbsoluteTiming"> <OID>RPTD701</OID> <CreatorId>18077000000000000001</CreatorId> ... <ReportingOrganisationRef> <OID>OI6</OID> </ReportingOrganisationRef> ... </ReportingData> ... </Status> ... </MinefieldLand> <Unit> <OID>OI6</OID> <CreatorId>18077000000000000001</CreatorId> ... <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


Edition 3.0.2

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 top-level 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 <?xml version="1.0" encoding="UTF-8"?> <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> <Status xsi:type="OtherFacilityStatus"> <OID>FS1</OID> <CreatorId>18077000000000000001</CreatorId> <ReportingData xsi:type="ReportingDataAbsoluteTiming"> ... </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


Edition 3.0.2

O-4-7

arbitrary number of elements that establish a one-to-many relationship. In that way, you can establish new associations with existing objects.


Edition 3.0.2

ANNEX O, APPENDIX 5 MULTILATERAL INTEROPERABILITY PROGRAMME

OPEN SOURCE LICENSE

Copyright © 2009, Multilateral Interoperability Programme (MIP), http://www.mipsite.org 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


Edition 3.0.2

O-5-2



Edition 3.0.2

ANNEX O, APPENDIX 6 XML TERMS AND REFERENCES

O-6.1 XML Terms and Definitions

Term Definition DTD 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.

PIM 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/]

UML 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/]

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

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

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

XML Extensible Markup Language (XML) is a simple, very flexible text format derived from SGML (ISO 8879).

XML Attribute XML attribute types are of three kinds: a string type, a set of tokenized types, and enumerated types.

XML Base 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],

XML Element 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.

XML Namespace See definition above XML Namespace identifier (NID)

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

http://www.omg.org/mda/%5D

http://www.uml.org/%5D

http://www.w3.org/XML/

http://www.iso.ch/cate/d16387.html

http://www.w3.org/TR/xmlbase/%2522%20%255Cl%20%2522dt-must%2522%20%255Co%20%2522Must,%20May,%20etc.

http://www.w3.org/TR/xmlbase/%2522%20%255Cl%20%2522RFC2396

http://www.w3.org/TR/REC-xml/%2522%20%255Cl%20%2522dt-element%2522%20%255Co%20%2522Element

http://www.w3.org/TR/REC-xml/%2522%20%255Cl%20%2522dt-xml-doc%2522%20%255Co%20%2522XML%20Document

http://www.w3.org/TR/REC-xml/%2522%20%255Cl%20%2522dt-valid%2522%20%255Co%20%2522Validity

http://www.w3.org/TR/REC-xml/%2522%20%255Cl%20%2522dt-content%2522%20%255Co%20%2522Content


Edition 3.0.2

XML Namespace name

Identifies the namespace; see above

XML Namespace prefix

See definition above

XML Namespace specific string (NSS)

As required by RFC 1737, there is a single canonical representation of the NSS portion of an URN.

XML Schema 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 XPath is a language for addressing parts of an XML document, designed to be used by both XSLT and XPointer.

XQuery Xquery is a query language, which is designed to be broadly applicable across many types of XML data sources.

XSL XSL is a family of recommendations for defining XML document transformation and presentation. It consists of three parts: XSLT, XPath and XSL-FO.

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

http://RFC.net/rfc1737.html


Edition 3.0.2

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-NDR-1.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

http://www.w3.org

http://www.w3.org/TR/xml-names11

http://www.w3.org/TR/xml11

http://www.w3.org/TR/REC-xml




http://www.oasis-open.org

http://www.unece.org/cefact/ebxml/CCTS_V2-01_Final.pdf

http://docs.oasis-open.org/ubl/cd-UBL-1.0/

http://www.oasis-open.org/committees/download.php/10323/cd-UBL-NDR-1.0Rev1c.pdf

http://www.oasis-open.org/committees/download.php/10323/cd-UBL-NDR-1.0Rev1c.pdf

http://www.iso.org/iso/en/ittf/PubliclyAvailableStandards/c035343_ISO_IEC_11179-1_2004(E).zip


Edition 3.0.2

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


http://www.jtc1sc32.ohttp:/staging.jtc1sc32.org/doc/N1051-1100/32N1079-ISO-IEC11179-3-COR1.pdf




http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=35347&ICS1=35&ICS2=40&ICS3=


http://www.metadata-standards.org





http://www.oasis-open.org


Edition 3.0.2

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/cefact-roups/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

http://www.doncio.navy.mil/StoreFront/Uploads/0128YRM15241.pdf

http://xml.coverpages.org/ATG2-NamingAndDesignRules200501.pdf

http://www.disa.org/cefact-roups/atg/downloads/NamingAndDesignRules_1.1a.pdf

http://www.disa.org/cefact-roups/atg/downloads/NamingAndDesignRules_1.1a.pdf

http://nhqc3s.nato.int/

mailto:[email protected]

http://www.w3.org/TR/ws-arch/


Edition 3.0.2

O-6-6



Edition 3.0.2

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 <?xml version="1.0" encoding="UTF-8"?> <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


Edition 3.0.2

<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> <ReportingData xsi:type="ReportingDataAbsoluteTiming"> <OID>RPT20</OID> <CategoryCode>REP</CategoryCode> <ReportingDatetime>2006-04-25T23:17:55Z</ReportingDatetime> <ReportingOrganisationRef> <OID>ORG2</OID> </ReportingOrganisationRef> </ReportingData> </ObjectItemLocation> </ObjectItemLocationInObjectItem> </ObjectItemLocationInObjectItemList> </ObjectItemRef> </JC3IEDM>

O-7.1.2 The WMAPositionReport XSDs documents shown in Listing 24 and 25 below.

Listing 24: WMAPositionReport.xsd <?xml version="1.0" encoding="UTF-8"?> <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


Edition 3.0.2

Listing 25: WMAPositionReportEntities.xsd <?xml version="1.0" encoding="UTF-8"?> <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> <documentation xml:lang="en">The specific value that represents, for usual operational purposes, the nature of a specific REPORTING-DATA.</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> <documentation xml:lang="en">The specific value that represents, for 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> <documentation xml:lang="en">The specific value that represents, for 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


Edition 3.0.2

</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 REPORTING-DATA.</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


Edition 3.0.2

<sequence> <element name="OID" type="jc3iedm:OIDType"> <annotation> <documentation xml:lang="en">The globally unique object identifier.</documentation> </annotation> </element> <element name="ReferenceCode" type="jc3iedm:VerticalDistanceReferenceCode"> <annotation> <documentation xml:lang="en">The specific value that represents the 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> <attribute name="typeCategoryCode" type="NMTOKEN" fixed="Entity"/> </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> <element name="OID" type="jc3iedm:OIDType"> <annotation> <documentation xml:lang="en">The globally unique object identifier.</documentation> </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


Edition 3.0.2

<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> <documentation xml:lang="en">The specific value that represents the resolution used for the expression of a value of a latitude coordinate.</documentation> </annotation> </element> <element name="LongitudePrecisionCode" type="jc3iedm:AnglePrecisionCode" minOccurs="0"> <annotation> <documentation xml:lang="en">The specific value that represents the 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


Edition 3.0.2

</annotation> <sequence> <element name="OID" type="jc3iedm:OIDType"> <annotation> <documentation xml:lang="en">The globally unique object identifier.</documentation> </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 OBJECT-ITEM 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> <documentation xml:lang="en">The one-dimensional linear distance representing the uncertainty in terms of probable error range for the vertical axis of a specific OBJECT-ITEM-LOCATION.</documentation>

O-7-7


Edition 3.0.2

</annotation> </element> <element name="HorizontalAccuracyDimension" type="jc3iedm:DimensionType12_3" minOccurs="0"> <annotation> <documentation xml:lang="en">The one-dimensional linear distance 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> <documentation xml:lang="en">The specific value that represents the 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> <documentation xml:lang="en">The specific value that represents the 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


Edition 3.0.2

O-7-9

</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-ITEM-LOCATION 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> <documentation xml:lang="en">The specific value that represents the maximum resolution used for the expression of speed.</documentation> </annotation> </element> <element name="MeaningCode" type="jc3iedm:ObjectItemLocationMeaningCode" minOccurs="0"> <annotation> <documentation xml:lang="en">The specific value that represents the meaning of the LOCATION geometry as it pertains to the OBJECT-ITEM.</documentation> </annotation> </element> <choice> <element name="ReportingData" type="jc3iedm:IncSubReportingData"> <annotation> <documentation xml:lang="en">The REPORTING-DATA.</documentation> </annotation> </element> </choice> </sequence> <attribute name="typeCategoryCode" type="NMTOKEN" fixed="Entity"/> </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>