ANNEX O. EXTENSIBLE MARKUP LANGUAGE (XML) REFERENCE SCHEMAS AND IMPLEMENTATION GUIDANCE. Contents

Transcription

1 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 O5. SCHEMA DESIGN CONSIDERATIONS O5.1 RDBMS XSD O5.2 WEB SERVICE/OBJECT-ORIENTED SCHEMA O5.3 COIS USING JC3IEDM AS A FOUNDATION FOR COI BO O6. APPLICATION USE CONSIDERATIONS O7. TOOLS OVERVIEW O8. DELIVERY O9. ONGOING XML COLLABORATION 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 O-1.9. RDBMS ALTERNATE REPRESENTATIONS 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 O-2.4 SUMMARY AND CONCLUSIONS ANNEX O, APPENDIX 3 WS/OO XSD DESIGN DOCUMENT... 1 O-1

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

3 O1. BACKGROUND O1.1 The use of the Extensible Mark-up Language (XML) for information exchange and processing has reached a high degree of technical maturity, as well as acceptance in the commercial world. XML provides a simple yet powerful mark-up syntax that aids in making data more accessible, understandable and reusable. O1.2 Although the XML features mentioned above are quite positive one should never forget that automated, XML-based information exchange and processing requires agreement on the semantics and format of the XML elements and their markup tags, as well as the clear specification of allowed instance XML document structure and content. O1.3 Fortunately, one of the XML technologies, namely the XML Schema Definition (XSD), enables the specification of XML document content and structure. This, coupled with specifications for the semantics of the data, such as the ones provided by information models, offers the possibility of developing very robust XML information exchange implementations. O1.4 This Annex describes the approach taken in the Multilateral Interoperability Programme (MIP) to leverage for the application of XML the results achieved in the area of C2 and incorporated in the Joint Consultation, Command and Control Information Exchange Data Model (JC3IEDM). National and programmatic interest in using XML technology in applications and services has created an opportunity for MIP partners to collaboratively produce and share capability to implement XML-based data exchange solutions. O1.5 The MIP information exchange data model enables command and control system interoperability based on shared information exchange standards and protocols developed through an international process that has built operational and technical consensus. The JC3IEDM and its business rules define the MIP shared vocabulary, grammar and business rules for information exchange and define the required baseline semantics for implementing XML-based data exchange and processing. O1.6 The following sections of this Annex describe how any given version of the MIP IEDM can be transformed to define XML Namespaces, in turn suitable for building reference XSDs that can support XML-based consultation, command and control (C3) information sharing within the MIP community. O1.7 The contents of this Annex reflect a continuing effort centred on the definition of XML use-cases, associated syntactic transformation patterns for XSD design, Namespaces for the proposed XSDs, applications of the extensible Stylesheet Language Transformations (XSLT), and prototype software tools. These components provide a capability for MIP C3 information exchange services based on XML technology and standards. O-3

4 O1.8 Table O-1 describes how XML technologies can be applied to support the MIP Tactical C2IS Interoperability Requirements (MTIR Version 3.0.8). Table O-1. XML Application to MIP Interoperability Requirements MTIR Section Information/Structured Information Information /Unstructured Information Information/ Information Exchange /Automated Exchange without Human Intervention Exchange Mechanism /Information Pull Exchange Mechanism /Information Repository Exchange Mechanism /Information Push Exchange Mechanism /Electronic Messaging Exchange Mechanism /Online Collaboration Information Management /Operational Information Groups Uninterruptible Support to C2/ Moveability of Static Command Posts XML Contribution 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. 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. 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. 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. XML technologies are widely used in on-line repositories providing managed access to multiple national or multinational users at distributed locations. Document XSDs are the modern equivalent of electronic message specifications. XML instance documents enable user and machinereadable messaging. XSDs enable machine validation of message structure and content. Instance XML documents can be converted using XSLT (Extensible Stylesheet Language Transformation) and other technologies into alternative formats. XML-based Real Simple Subscription (RSS) technology provides a common tailored service for automated sender to receiver flow of structured information (without user acknowledgement on the receiving side). See 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. Operational Information Groups (OIGs) are effectively predefined electronic messages. See 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

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

6 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

7 translation approach used when no shared community semantic standards exist 1. 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

8 O3.2.3 To achieve combined and joint integrated capabilities in the networkenabled environment, many functional communities must work together and share information. As within a functional COI, semantic standards provide the critical basis for inter-coi automated machine exchange and processing. Without semantic harmonization in the overlaps, each functional COI communicates with other COIs through lossy and expensive 2 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

9 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 COIs 3. Thus, there are IERs shared by C2 and TST, IERs shared by TST and other functional COIs (e.g., GS), and TSTunique IERs. Figure O-4. Definition of COI Information Exchange Semantics O3.2.5 The MIP IEDM solution anticipates the need for extensions. In fact the history of developing the MIP IEDM has been a requirements driven process of logical generalization and extension. Similarly, functional COI extensions built on the C2 semantic core are practical. The C2 core has already been extended to meet national, multinational and COI requirements 4. 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

10 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 objects 5. 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 messages 6. 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

11 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: O 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 OBJECT-ITEM-LOCATION OBJECT-ITEM-TYPE OBJECT-ITEM-ALIAS LOCATION MATERIEL ORGANISATION POINT LINE SURFACE LINE-POINT UNIT ABSOLUTE-POINT POLYGON-AREA CONTEXT REPORTING-DATA VERTICAL-DISTANCE CONTEXT-ELEMENT REPORTING-DATA-ABSOLUTE-TIMING GEOGRAPHIC-POINT Figure O-6. Blue Force Position JC3IEDM View O-11

12 O 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) O 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 National Non-MIP System JC3IEDM I/F EM XML (RDBMS) EM XSLT Non-MIP DB I/F O Figure O-7. RDBMS Use Case 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

13 f. XML schema definition does not need to be partitioned due to low complexity. O3.4.2 XML Exchange Mechanism (XEM) O 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) EM XML (RDBMS) EM MIP Common Interface (MCI) O Figure O-8. XEM Use Case The characteristics of this use case are: 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) O 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 Non-MIP system JC3IEDM XSLT Web Services (EM) XML (OO) XSLT Figure O-9. Web Services/Object-Oriented Use Case O The characteristics of this use case are: a. XML tag set is derived from the IEDM logical view b. XML documents capture the IEDM in an Object Oriented structure O-13

14 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) O 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 System 1 System 1 Internal Model XSLT XML (OO, RDBMS) COI JC3IEDM XML Business Object Exchange Mechanism XML (OO, RDBMS) XSLT COI System n System n Internal Model O Figure O-10. Business Object Exchange Use Case The characteristics of this use case are: 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 O 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 Exchange Standard/System JC3IEDM I/F EM1 XML (RDBMS, OO) EM1 Transform Technology EM2 Non-MIP Exchange Figure O-11. Tactical Communications Interface Use Case O-14

15 O The characteristics of this use case are: 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 O 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. C2IEDM EM1 XML (RDBMS, OO) EM1 Mediation Service or XSLT EM2 XML (RDBMS, OO) EM2 JC3IEDM O Figure O-12. Mediation Use Case The characteristics of this use case are: 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

16 MEM-like nature of the WS/OO does not preclude the use of the publish/subscribe paradigm. O4.4 Design considerations and the transformation rules for the two MIP Reference XSDs, namely the RDBMS XSD and the WS/OO XSD, are described in the appendices to this Annex. These transformation rules are generic. It is recognized that an optimal XSD design (i.e., transformation choices) can only be realized in the context of a specific use case. However, by choosing a generic approach one minimizes the impact of IEDM changes across versions and facilitates the automation of the XSD generation process. O4.5 The two alternative representations are equivalent in terms of their ability to convey information represented in the MIP IEDM. These XML schemas are both derived under different transformation rules from the same reference entityrelationship model, i.e., the MIP IEDM. General considerations applied in developing these XSDs include: a. Automatically Generated: The XML schemas should be automatically derivable from the MIP Entity-Relationship model to ensure correctness and minimize their production and maintenance cost. b. Syntactic Transformations Only: The procedures for generating the XML schemas should use only syntactic transformations. This enables the specification of transformation patterns that are independent of the semantics in any given version of the MIP IEDM. O4.6 As an overview to the appendices, two instance XML document fragments, compliant with the RDBMS/XEM and WS/OO XML schemas, are shown below: a. In Figure O-13 information regarding West Minefield in an instance XML document, valid with respect to the RDBMS XSD, is distributed across multiple tables. The same information in the WS/OO instance document has been aggregated by inheritance into the MinefieldLand element. b. In Figure O-13 and Figure O-14, the primary and foreign keys (e.g., <OBJ_ITEM_ID>, <MNFLD_LAND_ID> respectively) used for subtyping in the RDBMS/XEM instance document have been replaced by an Object ID (OID) that applies to all nested/aggregated information elements that have been inherited in the WS/OO instance document. To simplify these figures the OID typing construct is not shown, neither is the obligatory <CreatorId> nor the optional <UpdateSequenceNo>, which follow the OID specification. c. In Figure O-14, nested structures create associations between independent elements. O-16

17 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> Primary Key <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> Foreign Key <FAC_ID>223432</FAC_ID> <CAT_CODE>MILOBS</CAT_CODE> <LENGTH_DIM> </LENGTH_DIM> <WIDTH_DIM> </WIDTH_DIM> </FAC> </FAC_TBL> <MIL_OBS_TBL> <MIL_OBS> Foreign Key <MIL_OBS_ID>223432</MIL_OBS_ID> <CAT_CODE>MNFLD</CAT_CODE> </MIL_OBS> </MIL_OBS_TBL> <MNFLD_TBL> <MNFLD> Foreign Key <MNFLD_ID>223432</MNFLD_ID> <CAT_CODE>MNFLND</CAT_CODE> <MINE_SPACING_DIM> </MINE_SPACING_DIM> </MNFLD> </MNFLD_TBL> <MNFLD_LAND_TBL> <MNFLD_LAND> <MNFLD_LAND_ID>223432</MNFLD_LAND_ID> Foreign Key <DEPTH_PLCMNT_CODE>MIXED </DEPTH_PLCMNT_CODE> <FUNC_CODE>NUISNC</FUNC_CODE> <PATTERN_CODE>REGTHK</PATTERN_CODE> <PERSISTENCE_CODE>REMOTE </PERSISTENCE_CODE> <STOPPING_POWER_CODE>MEDIUM </STOPPING_POWER_CODE> </MNFLD_LAND> </MNFLD_LAND_TBL> </JC3IEDM_RDBMS> Object ID <?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</MineSpacingDime nsion> <DepthPlacementCode>MIXED </DepthPlacementCode> <FunctionCode>NUISNC</FunctionCode> <PatternCode>REGTHK</PatternCode> <PersistenceCode>REMOTE</PersistenceCode> <StoppingPowerCode>MEDIUM </StoppingPowerCode> </MinefieldLand> <MilitaryObstacleType> <OID>343545</OID> <DummyIndicatorCode>NO</DummyIndicatorCo de> <NameText>LandMinefield</NameText> <CategoryCode>MINEFD</CategoryCode> </MilitaryObstacleType> </JC3IEDM> Figure O-13. Minefield Establishment Report Distributed (ER) vs Aggregated (WS/OO) Information O-17

18 ER instance document fragment WS/OO instance document fragment Flat Structure <?xml version=»1.0» encoding="utf8"?> <JC3IEDM_RDBMS> <OBJ_ITEM_TBL> Primary Key <OBJ_ITEM> <OBJ_ITEM_ID>223432</OBJ_ITEM_ID> <CAT_CODE>FA</CAT_CODE> <NAME_TXT> West Minefield </NAME_TXT> </OBJ_ITEM> Nested </OBJ_ITEM_TBL> structure <OBJ_ITEM_STAT_TBL> Foreign Key <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> </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> </RPTD_ABS_TIMING_RPTD_ID> <EFFCTV_START_DTTM> </EFFCTV_START_DTTM> </RPTD_ABS_TIMING> </RPTD_ABS_TIMING_TBL> <OBJ_ITEM_TYPE_TBL> <OBJ_ITEM_TYPE> reference <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> Association via key <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> Object ID <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> </ReportingDatetime> <ReportingOrganisationRef> <OID>OI6</OID> </ReportingOrganisationRef> <EntityCategoryCode>OISTAT </EntityCategoryCode> <EffectiveStartDatetime> </EffectiveStartDatetime> </ReportingData> </Status> </ StatusList> </MinefieldLand> <MilitaryObstacleType> <OID>343545</OID> <DummyIndicatorCode>NO</DummyIndicatorCode> <NameText>LandMinefield</NameText> <CategoryCode>MINEFD</CategoryCode> </MilitaryObstacleType> </JC3IEDM> Figure O-14. Minefield Status Report Object IDs Supplant Keys and Associations Made through Nested References Association by O-18

19 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 O 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. O 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 O 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-tomachine interface b. Communication procedures preserve referential integrity: O-19

20 (1) Replication-based methods preserve database keys O5.1.3 Entity-Relationship Use Case: Specific Considerations O The RDBMS XSD is built according to the following set of syntactic transformation rules: a. For every entity specified in the logical MIP IEDM there is a specification in the physical schema that corresponds to the RDBMS table. This specification is the basis for the XML elements as indicated below. b. Figure O-15 shows an example of this correspondence. The entity ACTION in the logical view is represented in the physical view as the table ACT. From this physical schema one can implement the table ACT in a database. Figure O-15. XML Representation of Physical Tables and Columns c. This generic syntactic transformation provides the following rules for the generation of the XML representation: (1) For each physical table there is an XML element. The name of the element is formed by appending to the physical table name the string _TBL, e.g., <ACT_TBL>. O-20

21 (2) For each record in the physical table there is an XML element. The name of the element is identical with the name of the physical table name, e.g., <ACT>. (3) For each column in the physical table there is an XML element. The names of these elements are identical with the physical column names, e.g., <ACT_ID>, <CAT_CODE>. (4) The RDBMS XSD does not use XML tag attributes. The values of the columns in a physical table are represented as content of the corresponding column XML elements. (5) Every instance XML document that conforms to the RDBMS schema has the same root tag. The name of the root tag is chosen to make explicit its type (physical, RDBMS-related, as opposed to WS/OO), and the model whence it is built. O5.2 WEB SERVICE/OBJECT-ORIENTED SCHEMA O5.2.1 Introduction O 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). O 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 O design: The following assumptions underlie the WS/OO XSD schema 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

22 (3) Systems that rely on XSD validation to enforce business rules, (4) Gateways that mediate between MIP and Non-MIPcompliant 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-andanswer exchanges. Referenced information must be accessible but not necessarily embedded in the instance document. The referencing mechanism supports this way of communication by relaxing the referential integrity constraints. (3) WS/OO instance documents when imported into a MIP-compliant RDBMS may require the generation of new RDBMS keys. Moreover, external OIDs must be associated with RDBMS keys and RDBMS keys must be preserved in an Object ID when generating a WS/OO instance document. O 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

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

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

25 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 O 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. O The use of NATO Guidelines for XML Naming and Design (GXND), which are based on the ISO and 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

26 O6.4.3 A functional community that reuses and extends the JC3IEDM semantics would ideally use data modelling tools and then generate a community namespace XSD. The community XSD would ideally include JC3IEDM namespacequalified elements as well as the community-specific qualified element. Current XSD generation tools create a single JC3 community namespace specification. Future versions of the tools may support generating a community-specific namespace (i.e., specified restrictions, extensions and additions) and include the JC3IEDM namespace. O7. TOOLS OVERVIEW O7.1 A number of tools and techniques have been developed and applied to generate the reference materials referred to in this annex. Reference XSDs are generated using open source tools that process equivalent renderings of the MIP IEDM metadata, e.g., MIRD, ERwin XML, XMI. These tools and the XML products that they generate are available at the MIP homepage. The tools are provided under the BSD Open Source License. O7.2 A list of available tools is as follows: a. A Java tool that enables the user to generate the RDBMS and WS/OO XML schemas and the Java classes automatically from the ERwin XML file of the MIP Information Exchange Data Model. b. A SAX-based XML parser for the WS/OO XSD that validates instance XML documents and generates corresponding Java objects. In combination with the model-specific Java classes, the XML parser supports incremental updates. c. Other XML XSD generation tools, that use a developmental UML Platform Independent Model of the JC3IEDM, have been developed but are not currently approved MIP products. O8. DELIVERY The products of the MIP XML WP will be published on the XML page at the MIP member web site. The MIP Data Modelling Working Group (DMWG) and Programme Management Group (PMG) will approve public release of selected products (e.g., XSDs) to the MIP public web page and to other international bodies. MIP intends to make submissions to the NATO XML Registry. Nations may use these products as they deem appropriate in their national efforts. O9. ONGOING XML COLLABORATION O9.1 The XML products described in this Annex present a reference baseline suitable for supporting a broad scope of XML application and service development work. They are being published to the public space to encourage use of the MIP IEDM semantics and to serve as a catalyst for MIP capability development using XML. From this public discourse alternative XSDs, XSLTs, RDBMS support tools, web service components, XML document schemas, demonstration exemplars, etc. will emerge. The XML WP will have its own specific continuing work plan and products to contribute. The MIP XML WP will periodically elect to recommend to O-26

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

28 ANNEX O, APPENDIX 1 ENTITY-RELATIONSHIP XSD DESIGN DOCUMENT O-1.1 INTRODUCTION O The aim of the Multilateral Interoperability Programme (MIP) is to enable interoperability among multinational military commanders. This requires appropriate and adequate information exchange between national C2 systems supporting the multinational operations. To enable the exchange of (structured) datain-context the MIP has defined an information exchange data model (IEDM) and supporting information exchange mechanisms (IEM). These capabilities are well documented, mature, and agreed to by 26 nations and institutions. The Data Exchange Mechanism (DEM) is an RDBMS-based IEM. It enables data base replication through the MIP Communications Interface (MCI). Similarly, the Message Exchange Mechanism (MEM) is an ADatP3 message-based IEM that enables message passing through the MCI. O 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 Six types of XML Use Cases are identified in the Annex main document. Two of these are candidates for an XSD that preserves the natural entityrelationship structure of the underlying data model, specifically: a. XML Exchange Mechanism (exchange among MIP data bases via XML), and b. RDBMS (exchange between a MIP data and a non-mip data base via XML). O-1-1

29 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 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 Once a non-mip system implements the transformation steps needed to send and receive data in conformance with the MIP standards the target non-mip RDBMS is operationally indistinguishable from a MIP database. Therefore, this document concentrates on the XEM Use Case requirements. The XEM Use Case is shown in Figure O-17 and the RDBMS Use Case is shown in Figure O-18. MIP Communication Interface (MCI) EM XML (RDBMS) EM MIP Communication Interface (MCI) Utility: MIP Communications Interface (MCI) using XML MIP Communications Interface with XML PDUs XML tag set aligns with JC3IEDM Physical view XSD captures the RDBMS structure of the JC3IEDM o 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

30 National MIP System National Non-MIP System JC3IEDM I/F EM XML (RDBMS) EM XSLT Non-MIP DB I/F Utility: Move data between MIP DB and Non-MIP DB XML tag set aligns with JC3IEDM Physical view XSD captures the RDBMS structure of the JC3IEDM o 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 Requirements Derived from Sender/Receiver of XML Message O The XEM Use Case presupposes that all communicating systems are MIP-compliant C2ISs. Under that scenario an XML schema is required that allows for a simple mapping to and from the physical schema implemented in the RDBMS resident within the C2ISs. Furthermore, one can assume that referential integrity is ensured by the RDBMS in the MIP-compliant systems, and that, furthermore, it is not necessary to perform a thorough and, potentially, timeconsuming XML validation before incoming data is loaded into the database. O 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

31 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 Requirements Derived from Communication Procedures O In a replication-based scenario, such as the DEM, an initial RDBMS data load must first be established. Information updates are then transmitted. Each update may refer to information transmitted earlier. For example, for an instance of OBJECT-ITEM it is valid to send only a status update provided that the appropriate defining information on that instance has been transmitted before. Thus, replicationbased communication requires a mechanism to refer to previously transmitted data. Ultimately, this means that for information exchanges that include an RDMBS-based system the MIP data model synthetic keys must be preserved. Specifically, data forwarding using XML documents will not work between MIP systems if all the mandatory MIP keys are not exchanged. O 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 Applicable XML Standards O 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 Additionally, there are multiple standards for XML naming and design rules (NDRs). As noted above, since the main goal is to move data among MIP C2ISs the optimal choice is to align the XML tags with the physical table and column names, because that is the way in which most commercial RDBMSs support XMLbased I/O operations. Transformations using XSLT to recast the physical names into logical names, and visa versa, are provided in materials. O-1.4 GENERAL MIP RDBMS XML CONSIDERATIONS O 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

32 a. Flat: Normalised relational databases strive to eliminate any kind of data nesting. The linkage among the data classes is accomplished via foreign keys. Therefore, a flat XML structure for the RDBMS XSD is the optimal match. b. Monolithic: Although NDRs recommend modular XSDs to improve maintenance, design and reuse, the specialised purpose of the RDBMS XSD would warrant having a self-contained specification that handles all possible combinations of tables, rather than specialised combinations, such as those needed for an object oriented kind of message. c. Community of Interest (COI) Driven: The MIP IEDM is systemindependent. It provides a COI (i.e., Command and Control) generic view of information exchange requirements. In the same way, the RDBMS XSD should provide a system-neutral representation suited for exchange. d. Conformant with the Physical Model: The MIP IEDM physical schema is specifically designed for an RDBMS implementation and, therefore, the RDBMS XSD generation and maintenance can be more readily accomplished when basing the specification on the MIP IEDM physical model. e. Normalized: RDBMS-based exchanges are highly normalised as are the source and target databases that are meant to exchange their data via the XEM. f. Storage format independent: Although instance XML documents conformant with the MIP RDBMS XSD are meant to be produced and consumed by MIP C2IS databases they should support any type of storage format. O-1.5 SPECIFIC MIP RDBMS XML CONSIDERATIONS O Introduction O In addition to the general considerations listed in the preceding section, the RDBMS XSD also should be: a. Automatically Generatable: The XML schema should be automatically derivable from the MIP ERA IDEF1X model to ensure correctness and minimize its production and maintenance cost. The simplest approach maps each entity definition onto an XSD complex type where all attributes are preserved and keep their original domains. Such a one-toone mapping ensures easy integration in MIP-compliant RDBMS systems. b. Based on Syntactic Transformations Only: The use of only syntactic transformations enables the specification of transformation patterns that can be applied to any version of the MIP IEDM. In addition, this approach ensures that the RDBMS XSD is not dependent structurally on the semantics of the model. O-1-5

33 O RDBMS XSD Syntactic Transformation Design Patterns O 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 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 Transformation Patterns for Relationships O 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 Non-Identifying One-to-Many A B Foreign Key (FK) from A to B Key of B depends on FK Foreign Key (FK) from C to B B C 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 Physical Tables and Columns O 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

34 Figure O-20. XML Representation of Physical Tables and Columns O 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

35 O-1.6 CHARACTERISTICS OF THE BASELINE RDBMS XML SCHEMA O 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

36 O 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 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 Specification of the Root Tag O 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 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

37 O 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 Specification of XML Elements for Physical Tables O 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 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 Specification of XML Elements for Record Delimiters O 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

38 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 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"> <documentation xml:lang="en">an activity, or the occurrence of an activity, that may utilise resources and may be focused against an objective.</documentation> <all> <element name="act_id" type="jc3iedm:identifiertype20" minoccurs="1" maxoccurs="1"> <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> </element> <element name="cat_code" type="jc3iedm:actioncategorycode" minoccurs="1" maxoccurs="1"> <documentation xml:lang="en">the specific value that represents the class of ACTION. It serves as a discriminator that partitions ACTION into subtypes.</documentation> </element> <element name="name_txt" type="jc3iedm:texttypevar50" minoccurs="0" maxoccurs="1"> O-1-11

39 <documentation xml:lang="en">the character string assigned to represent a specific ACTION.</documentation> </element> <element name="creator_id" type="jc3iedm: IdentifierType20" minoccurs="1" maxoccurs="1"> <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> </element> <element name="update_seqnr" type="jc3iedm:updateseqnrtype15" minoccurs="1" maxoccurs="1"> <documentation xml:lang="en">an absolute sequence number, assigned to represent the validity (in terms of seniority) of a certain data item.</documentation> </element> </all> </complextype> O 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 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"> <documentation xml:lang="en">an absolute sequence number, assigned to represent the validity (in terms of seniority) of a certain data item.</documentation> <restriction base="integer"> <mininclusive value=" " /> <maxinclusive value=" " /> </restriction> </simpletype> O The characteristics of elements that have decimal numeric content are captured in the Simple Types XSD in the following fashion: O-1-12

40 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 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"> <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> <restriction base="decimal"> <totaldigits value="5" /> <fractiondigits value="1" /> <mininclusive value="-273.2" /> <maxinclusive value="9999.9" /> </restriction> </simpletype> O 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 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"> <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> <restriction base="string"> <minlength value="0" /> <maxlength value="2000" /> </restriction> </simpletype> O-1-13

41 O-1.8. RDBMS XSD GENERATION TOOLKIT O 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 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=" " CAT_CODE="ACTTA" NAME="Operation Alpha Point" CREATOR_ID="777474" UPDATE_SEQNR="0" /> </ ACT_TBL> O If the use of XML tag attributes is used in both the WS/OO and the RDBMS documents it could be possible to increase the commonality between the two specifications by adopting an RDBMS representation based on the XML tag and attribute names of the WS/OO schema. Converting from this alternate style to the original format is relatively straightforward and can be accomplished via either XSLTs or programmatically, e.g., Perl scripts. O-1-14

42 ANNEX O, APPENDIX 2 Extensible Markup Language (XML) Reference Implementations RDBMS Use Case O-2.1 STRUCTURE OF THE DOCUMENT O 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 O 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 All the SQL query examples are for MySQL (version ). 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 Description O 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

43 Obstacle Alpha N West Minefield White Horse Bridge East Minefield Yukon River S Figure O-21. Sketch for the Scenario Used to Highlight the Use of OBJECT-ITEM-STATUS O 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. (a) OBJECT-ITEM Table O-2. Data for Example 01 FACILITY West Minefield 1 East Minefield 2 Obstacle Alpha 3 facilitywidthdimension MILITARY- OBSTACLE MILITARY- OBSTACLE MILITARY- OBSTACLE object-item-nametext facilityid facility-categorycode facilityheightdimension facilitylengthdimension White Horse Bridge 4 BRIDGE (b) BRIDGE bridge-id bridge-longest-spanlength-dimension bridge-spancount bridge-usagecode Railway/vehicle O-2-2

44 (d) MINEFIELD minefield -id (c) MILITARY-OBSTACLE military-obstacle-id military-obstacle-category-code 1 MINEFIELD 2 MINEFIELD 3 NOS 1 MINEFIELD-LAND MNFLD-WEST 10 (m) 2 MINEFIELD-LAND MNFLD-EAST 10 (m) (e) MINEFIELD-LAND minefield -land-id 1 Mixed Nuisance Regular minefield, thickened with scattered mines 2 Mixed Nuisance Regular minefield, thickened with scattered mines minefieldcategory-code minefieldidentification-text minefieldminespacingdimension minefielddestructiondatetime minefield-landdepthplacement-code minefield-landfunction-code minefield-landpattern-code minefieldlandpersistenc e-code Remote activated destruction Remote activated destruction Medium Medium (f) OBJECT-ITEM-HOSTILITY-STATUS object-item-id 1[Minefield West] 1 Friend [Minefield East] 1 Friend [Obstacle Alpha] 1 Friend [White Horse Bridge] 1 Friend 700 (g) OBJECT-ITEM-STATUS object-item-id *- index *-category-code minefieldlandstoppingpower-code object-item-hostilitystatus-index object-item-hostilitystatus-code reportingdata-id *-booby-trappresencecode *-emissioncontrolcode reportingdata-id 1[Minefield West] 1 FACILITY-STATUS [Minefield East] 1 FACILITY-STATUS [Obstacle Alpha] 1 FACILITY-STATUS [White Horse Bridge] 1 FACILITY-STATUS [White Horse Bridge] 2 FACILITY-STATUS [Obstacle Alpha] 2 FACILITY-STATUS 705 Note: * = "object-item-status" O-2-3

45 1[Minefield West] 2 [Minefield East] 3 [Obstacle Alpha] 4 [White Horse Bridge] 4 [White Horse Bridge] 3 [Obstacle Alpha] (h) FACILITY-STATUS Not otherwise specified Not otherwise specified Not otherwise specified Not otherwise specified Not otherwise specified Not otherwise specified facilitystatus-id objectitemstatusindex **-categorycode **- demolitionstatus-code **-minepresence -code Yes Operational Activated Yes Operational Activated Yes Not operational Prepared for execution Prepared for execution No Operational Passable Executed No Not operational Destroyed Yes Operational Activated Note: ** = facility-status (i) OBJECT-ITEM-ASSOCIATION **- operationalstatus-code **- operationalstatusqualifiercode **-usagestatus-code ***-subject-object-itemid ***-object-objectitem-id ***- index 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 *-id *** -index Start association Start association Start association Start association Start association Start association 712 Note: *** = object-item-association (k) REPORTING-DATA ***-categorycode ***-subcategorycode ***-subjectobject-item-id ***-objectobject-item-id ***-associationstatus-index ***-statuscategory-code reportingdata-id *-categorycode *-countingindicatorcode *-credibility-code *-reporting-datetime *-timingcategorycode *-reportingorganisationid 700 Reported Reported as a fact [absolute] [1 CA Bde] 701 Reported Reported as a fact [absolute] [1 CA Bde] 702 Reported Reported as a fact [absolute] [1 CA Bde] 703 Planned Reported as a fact Timing not available 704 Reported Reported as a fact Timing not available [1 CA Bde] [1 CA Bde] 705 Reported Reported as a fact [absolute] [1 CA Bde] 711 Planned Reported as a fact Timing not available [1 CA Bde] 712 Reported Reported as a fact [absolute] [1 CA Bde] Note: * = reporting-data O-2-4

46 (l) REPORTING-DATA-ABSOLUTE-TIMING **reporting-data-id **-effective-start-datetime **-effective-end-datetime Note: ** = reporting-data-absolute-timing Note: The data for OBJECT-TYPE, OBJECT-ITEM-TYPE, and ORGANISATION has been omitted. O Serialization Using the RDBMS XML Tag Set O 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 The XML serialization of Example 01 is, therefore, simply the expression of the values shown in Table O-2 above, both explicitly and implied, using the XML tags specified in the RDBMS XSD. The listings below show the XML segments corresponding to the entries in Table O-2, subparts (a) through (l). O-2-5

47 OBJECT-ITEM object-item-id object-item-category-code object-item-name-text FACILITY facility-id (FK) has / is-ascribed-to object-item-category-code facility-category-code facility-primary-construction-material-code facility-base-identification-code-text facility-height-dimension facility-length-dimension facility-width-dimension facility-major-building-type-id (FK) OBJECT-ITEM -HOSTILITY-STAT US object-item-id (FK) object-item-hostility-status-index object-item-hostility-status-code reporting-data-id (FK) has / is-ascribed-to provides-applicable-information-for / is-referenced-to is-the-object-of is-the-subject-of 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-code object-item-association-subcategory-code action-task-id (FK) has / is-ascribed-to 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-code reporting-data-id (FK) P is-classified-as facility-category-code BRIDGE M ILITARY-OBSTACLE bridge-id (FK) military-obstacle-category-code M INEFIELD minefield-id (FK) minefield-category-code bridge-longest-span-length-dimension bridge-span-count bridge-usage-code military-obstacle-id (FK) military-obstacle-category-code minefield-category-code minefield-identification-text minefield-mine-spacing-dimension minefield-destruction-datetime M INEFIELD-LAND ORGANISATION organisation-id (FK) organisation-category-code is-the-reporting-agent-for / is-reported-by REPORTING-DATA reporting-data-id OBJECT-ITEM -STATUS object-item-id (FK) object-item-status-index object-item-status-category-code object-item-status-booby-trap-presence-code object-item-status-emission-control-code reporting-data-id (FK) reporting-data-accuracy-code reporting-data-category-code reporting-data-counting-indicator-code reporting-data-credibility-code reporting-data-reliability-code reporting-data-reporting-datetime reporting-data-source-type-code reporting-data-timing-category-code reporting-data-real-data-exercise-use-only-code reference-id (FK) reporting-data-reporting-organisation-id (FK) object-item-status-category-code provides-applicable-information-for / is-referenced-to provides-applicable-information-for / is-referenced-to provides-applicable-information-for / is-referenced-to FACILIT Y-STATUS facility-status-id (FK) object-item-status-index (FK) OBJECT-ITEM -T YPE OBJECT-T YPE object-item-id (FK) object-type-id (FK) object-item-type-index reporting-data-id (FK) object-type-id object-type-category-code object-type-decoy-indicator-code object-type-name-text facility-status-category-code facility-status-demolition-status-code facility-status-enemy-activity-condition-code facility-status-mine-presence-code facility-status-occupation-program-indicator-code facility-status-operational-status-code facility-status-operational-status-qualifier-code facility-status-reserve-indicator-code facility-status-security-status-code facility-status-usage-status-code P is-used-as-a-classification-for minefield-land-id (FK) minefield-land-depth-placement-code minefield-land-function-code minefield-land-pattern-code minefield-land-persistence-code minefield-land-stopping-power-code reporting-data-timing-category-code REPORTING-DATA-ABSOLUTE-TIM ING reporting-data-absolute-timing-reporting-data-id (FK) reporting-data-absolute-timing-effective-start-datetime reporting-data-absolute-timing-effective-end-datetime Figure O-22. MIP IEDM Data Structures Needed to Specify the Use of OBJECT-ITEM-ASSOCIATION and OBJECT-ITEM-STATUS Listing 1. XML Segment for the OBJECT-ITEM table <OBJ_ITEM_TBL> <OBJ_ITEM> <OBJ_ITEM_ID>1</OBJ_ITEM_ID> <CAT_CODE>FA</CAT_CODE> <NAME_TXT>WEST MINEFIELD</NAME_TXT> </OBJ_ITEM> <OBJ_ITEM> <OBJ_ITEM_ID>2</OBJ_ITEM_ID> O-2-6

48 <CAT_CODE>FA</CAT_CODE> <NAME_TXT>EAST MINEFIELD</NAME_TXT> </OBJ_ITEM> <OBJ_ITEM> <OBJ_ITEM_ID>3</OBJ_ITEM_ID> <CAT_CODE>FA</CAT_CODE> <NAME_TXT>OBSTACLE ALPHA</NAME_TXT> </OBJ_ITEM> <OBJ_ITEM> <OBJ_ITEM_ID>4</OBJ_ITEM_ID> <CAT_CODE>FA</CAT_CODE> <NAME_TXT>WHITE HORSE BRIDGE</NAME_TXT> </OBJ_ITEM> <OBJ_ITEM> <OBJ_ITEM_ID>5</OBJ_ITEM_ID> <CAT_CODE>OR</CAT_CODE> <NAME_TXT>1 CA BDE</NAME_TXT> </OBJ_ITEM> </OBJ_ITEM_TBL> Listing 2. XML Segment for the OBJECT-TYPE table <OBJ_TYPE_TBL> <OBJ_TYPE> <OBJ_TYPE_ID>1</OBJ_TYPE_ID> <CAT_CODE>FA</CAT_CODE> <DUMMY_IND_CODE>NO</DUMMY_IND_CODE> <NAME_TXT>MINE</NAME_TXT> </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> </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> </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> </OBJ_TYPE> </OBJ_TYPE_TBL> O-2-7

49 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> </LENGTH_DIM> <WIDTH_DIM> </WIDTH_DIM> <FAC_MAJOR_BUILDING_TYPE_ID>NULL</FAC_MAJOR_BUILDING_TYPE_ID> </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> </LENGTH_DIM> <WIDTH_DIM>90.000</WIDTH_DIM> <FAC_MAJOR_BUILDING_TYPE_ID>NULL</FAC_MAJOR_BUILDING_TYPE_ID> </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> </LENGTH_DIM> <WIDTH_DIM> </WIDTH_DIM> <FAC_MAJOR_BUILDING_TYPE_ID>NULL</FAC_MAJOR_BUILDING_TYPE_ID> </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> </LENGTH_DIM> <WIDTH_DIM>10.000</WIDTH_DIM> <FAC_MAJOR_BUILDING_TYPE_ID>NULL</FAC_MAJOR_BUILDING_TYPE_ID> </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> </MIL_OBS> <MIL_OBS> <MIL_OBS_ID>2</MIL_OBS_ID> <CAT_CODE>MNFLD</CAT_CODE> O-2-8

50 </MIL_OBS> <MIL_OBS> <MIL_OBS_ID>3</MIL_OBS_ID> <CAT_CODE>NOS</CAT_CODE> </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> </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> </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> </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> </MNFLD_LAND> </MNFLD_LAND_TBL> Listing 7. XML Segment for the BRIDGE table <BRIDGE_TBL> <BRIDGE> <BRIDGE_ID>4</BRIDGE_ID> <LONGEST_SPAN_LENGTH_DIM>40.000</LONGEST_SPAN_LENGTH_DIM> <SPAN_CNT>5</SPAN_CNT> <USAGE_CODE>RLWYVH</USAGE_CODE> O-2-9

51 </BRIDGE> </BRIDGE_TBL> Listing 8. XML Segment for the ORGANISATION table <ORG_TBL> <ORG> <ORG_ID>5</ORG_ID> <CAT_CODE>NOS</CAT_CODE> </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> </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> </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> </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> </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> </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> O-2-10

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

53 <REP_ORG_ID>5</REP_ORG_ID> <ENT_CAT_CODE>OISTAT</ENT_CAT_CODE> </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> </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> </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> </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> </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> </EFFCTV_START_DTTM> <EFFCTV_END_DTTM /> </RPTD_ABS_TIMING> <RPTD_ABS_TIMING> <RPTD_ABS_TIMING_RPTD_ID>702</RPTD_ABS_TIMING_RPTD_ID> <EFFCTV_START_DTTM> </EFFCTV_START_DTTM> <EFFCTV_END_DTTM /> </RPTD_ABS_TIMING> <RPTD_ABS_TIMING> <RPTD_ABS_TIMING_RPTD_ID>705</RPTD_ABS_TIMING_RPTD_ID> <EFFCTV_START_DTTM> </EFFCTV_START_DTTM> <EFFCTV_END_DTTM /> </RPTD_ABS_TIMING> O-2-12

54 <RPTD_ABS_TIMING> <RPTD_ABS_TIMING_RPTD_ID>712</RPTD_ABS_TIMING_RPTD_ID> <EFFCTV_START_DTTM> </EFFCTV_START_DTTM> <EFFCTV_END_DTTM /> </RPTD_ABS_TIMING> </RPTD_ABS_TIMING_TBL> Listing 11. XML Segment for the OBJECT-ITEM-TYPE table <OBJ_ITEM_TYPE_TBL> <OBJ_ITEM_TYPE> <OBJ_ITEM_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> </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> </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> </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> </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> </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> O-2-13

55 </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> </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> </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> </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> </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> </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> </OBJ_ITEM_HSTLY_STAT> <OBJ_ITEM_HSTLY_STAT> O-2-14

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

57 <ENEMY_ACTV_COND_CODE /> <MINE_PRSNC_CODE>YES</MINE_PRSNC_CODE> <OCPTN_PROG_IND_CODE /> <OPERAT_STAT_CODE>OPR</OPERAT_STAT_CODE> <OPERAT_STAT_QUAL_CODE /> <RESERVE_IND_CODE /> <SECURITY_STAT_CODE /> <USAGE_STAT_CODE>ACTIVE</USAGE_STAT_CODE> </FAC_STAT> <FAC_STAT> <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 /> </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 /> </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 /> </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

58 <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> </FAC_STAT> </FAC_STAT_TBL> Listing 15. XML Segment for the OBJECT-ITEM-ASSOCIATION table <OBJ_ITEM_ASSOC_TBL> <OBJ_ITEM_ASSOC> <SUBJ_OBJ_ITEM_ID>1</SUBJ_OBJ_ITEM_ID> <OBJ_OBJ_ITEM_ID>3</OBJ_OBJ_ITEM_ID> <OBJ_ITEM_ASSOC_IX>1</OBJ_ITEM_ASSOC_IX> <CAT_CODE>ISPART</CAT_CODE> <SUBCAT_CODE /> <ACT_TASK_ID>NULL</ACT_TASK_ID> </OBJ_ITEM_ASSOC> <OBJ_ITEM_ASSOC> <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> </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> </OBJ_ITEM_ASSOC> </OBJ_ITEM_ASSOC_TBL> O Data Presentation for the End User O 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 Example 02. ACTION-TEMPORAL-ASSOCIATION O Description O This example shows how the JC3IEDM handles Temporal Relationships among instances of ACTION. O-2-17

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

60 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 9 (move stores) 10 (lay minefield) 11 (mark minefield) 11 (mark minefield) 7 (create minefield) 9 (move stores) 10 (lay minefield) 7 (create minefield) action-temporalassociationsubject-action-id action-temporalassociationobject-action-id action-temporalassociationindex action-temporalassociation-categorycode action-temporalassociationreference-duration 1 Starts after start of [60 minutes] 1 Starts after start of [60 minutes] 1 Starts after start of [180 minutes] 1 Ends after end of [0 minutes] O Serialization Using the RDBMS XML Tag Set O As discussed in the RDBMS XSD Design Annex, the RDBMS XSD has a structure that exactly parallels all the tables and attributes in the MIP IEDM. Figure O-24 shows the data structures needed to capture the information provided in this example (taken from the JC3IEDM). ACTION action-id action-category-code action-name-text is-the-subject-of is-the-object-of ACTION-TEMPORAL-ASSOCIATION action-temporal-association-subject-action-id (FK) action-temporal-association-object-action-id (FK) action-temporal-association-index action-temporal-association-category-code action-temporal-association-reference-duration Figure O-24. MIP IEDM Data Structures Needed to Specify Temporal Associations Among Instances of ACTION. O 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> </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

61 </ACT> <ACT> <ACT_ID>9</ACT_ID> <CAT_CODE>ACTTA</CAT_CODE> <NAME_TXT>MOVE STORES</NAME_TXT> <CREATOR_ID>122</CREATOR_ID> </ACT> <ACT> <ACT_ID>10</ACT_ID> <CAT_CODE>ACTTA</CAT_CODE> <NAME_TXT>LAY MINEFIELD</NAME_TXT> <CREATOR_ID>122</CREATOR_ID> </ACT> <ACT> <ACT_ID>11</ACT_ID> <CAT_CODE>ACTTA</CAT_CODE> <NAME_TXT>MARK MINEFIELD</NAME_TXT> <CREATOR_ID>122</CREATOR_ID> </ACT> </ACT_TBL> O 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> </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> </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> </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

62 </ACT_TMPRL_ASSOC> </ACT_TMPRL_ASSOC_TBL> O-2.3 Data Presentation for the End User O 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 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 [min] 10-lay minefield starts after start of 9-move stores [min] 11-mark minefield ends after end of 7-create minefield [min] 11-mark minefield starts after start of 10-lay minefield [min] O-2.4 Summary and Conclusions The XML instance documents discussed in this Appendix exemplify the use of the RDBMS XSD specification. They highlight (a) the direct correspondence between the data contained in the tables of a MIP IEDM-conformant database and its XML serialization, and (b) the fact that any such instance XML document can be validated using the RDBMS XSD. O-2-21

63 O-3.1 Introduction ANNEX O, APPENDIX 3 WS/OO XSD DESIGN DOCUMENT O Based on the requirements listed in the previous section, we have developed a reference MIP WS/OO XSD. Structures in instance XML documents conforming to the WS/OO XSD closely match the typical OO concepts, e.g., inheritance and navigability. In particular, the representation of relationships and associations via nesting greatly simplifies the adoption of the MIP IEDM in objectoriented applications. To describe (potentially cyclic) graph structures in the tree-like XML notation, a simple mechanism for referencing objects is provided. Instance XML documents exchanged in accordance with the WS/OO XSD do not prescribe any specific storage format, i.e., the WS/OO XML schema abstracts from the underlying persistence mechanism. This matches with the notion of defining an XML exchange format. Developers are able to choose any persistence framework, API, or tool, which simplifies integration. The WS/OO XSD provides an object oriented payload pattern that is especially convenient for web services, but, does not require a web services implementation, i.e., can be used with other information exchange mechanisms. O 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 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 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

64 the tool set are available at the MIP web site and considered a normative part of the reference MIP WS/OO XSD specification. O 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 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 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

65 O-3.4. Entities and Attributes Figure O-25. Entities and Attributes O 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 Optionality of attributes in the MIP IEDM is maintained by means of the XML Schema minoccurs attribute. O 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 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 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

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

67 WS/OO XSD that includes the identity constraints enforces a corresponding entity definition for every reference. These entities must be defined by a child element of the root element. The identity constraints are specified in a way that ensures type-safe referential integrity of instance XML documents (ID/IDREF would not provide typesafety). The constraints are defined as part of the XML root element definition (see Section O-3.6). O-3.5. Transformation Rules for Relationships O Identifying and Non-Identifying Relationships O 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 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 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

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

69 O Subtype Relationships Figure O-28. Subtype Relationships O 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 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 For the incomplete subtyping concept of IDEF1X, there is no direct counter-part in the OO world. In the case of incomplete subtyping, the discriminator in the super type may have a code that does not correspond to any of the existing subentities (this holds for codes like NOS Not Otherwise Specified). Keeping the discriminator code in the super type would severely limit the use of the WS/OO XSD for other COIs, because they were not able to add new subtypes to the existing schema (the set of discriminator codes in the super type is fixed and there is no way to extend it without redefining the super entity). Therefore, each incomplete subtype O-3-7

70 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 Many-to-Many Relationships Associative Entities O In relational models, a many-to-many relationship between two entities A and B is expressed by an associative entity A-B-ASSOC that is the child of both A and B via identifying relationships. In the MIP IEDM, all many-to-manyrelationships are binary. Nevertheless, we can distinguish three cases: Associative entities with only primary key attributes Associative entities with non-primary key attributes Double-associative entities Figure O-29. Associative Entities with PK Attributes Only O 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

71 Figure O-30. Associative Entities with Non-PK Attributes O 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 The ability to describe associations by nesting rather than by a toplevel element avoids information scattering throughout XML documents and enhances readability. Moreover, the WS/OO XSD supports object-to-association reasoning rather than association-to-object reasoning. This is considered as an important prerequisite for the compact definition of community-specific message formats that are derived from the generic XSD by tailoring. O 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

72 Figure O-31. Double-Associative Entities O There are also associations in which both relationships come from the same entity type. The generic syntactic transformations for such associations are similar to the transformations for associative entities with non-pk attributes given above. The only difference is that the element names include generic role names for the associated entities (see Figure O-31). Subject and Object are used as (modelindependent) role names. The suffixes are necessary, because in an XML document the object may be embedded in the subject and vice versa. O-3.6 XML Root Element O 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