# Presentation: 937539

## Market-DrivenXML Data Strategy

- Dr. Glenda Hayes
- The MITRE Corporation

## Contrasting Management Styles

**Top-down, ****“Command”**** approach**
***versus***
**Market Driven**** approach**

**LOOSE**

**TIGHT**

**SPECTRUM OF CONTROL**

## DoD’s Business Environment

_**NOT**_** a single Enterprise  *****but . . .***
**Conglomerate of Many Diverse Businesses**
**Various business connections**
**Close support with frequent transactions**
**Remote, infrequent “trading”**
**Adversarial behavior (competition)**
**Relationship with IT suppliers**
**Vendors/developers *****want *****fragmentation**
**Each “stovepipe” is a market**
**Government-Industry teams compete for Market Share**

***Hostile to Interoperability ***_***Requirements***_*** ***

## Which Management Approach?

- Market *with* some Controls appropriate for DoD:
-    - Complex, “many-to-many” problem
-    - Deals with competition
-    - Constrained to lightweight admin overhead -
-    - Modest visibility & enforcement tools
-    - Capitalize on existing acquisition oversight

**LOOSE**

**TIGHT**

## Market Characteristics

**DoD**
**Enterprise**

**Intel**

**C2**

**Log**

**Etc.**

**Pers**

**Fin**

**DoD Conglomerate**

**Spiral Development Process**

**Operators**
**(Users)**

**PMs**

**RQMTS**
**IMPL’N**

**Acquisition**
**Reviewers**

**RQMTS**

**$**

**$**

**CINC-to-Shooter**
**Customers**

**Communities of Interest (COIs)**

## COE Data Management Strategy

**COE Data Management Strategy**

**XML: ****Part of **_**larger**_** Market Driven Data Strategy**
**PMs as change agents**
**COIs (Namespaces) as arena for change**
**Components as unit of exchange (commodity) **
**Electronic Marketplace as change mechanism**

## Common Modular Architecture 
Common Representation
Common Data Exchange Language*
Common Metadata Mgmt Facilities
Common Data Access Services 

***Common***** Modular Architecture **
***Common***** Representation**
_***Common***__** Data Exchange Language**_*****
***Common***** Metadata Mgmt Facilities**
***Common *****Data Access Services **

**Market used to govern ****Data Components:**

***XML**

## Common Data Exchange LanguageeXtensible Markup Language (XML)

- <TacticalReport>
- <MessageIdentification>
- <MessageIdentifier>TACREP</MessageIdentifier>
- <Originator>CTF 124</Originator>
- :
- </TacticalReport>

- Tactical Report encoded in XML

***Common***** Data Exchange Language****e****X****tensible ****M****arkup ****L****anguage**** ****(XML)**

**Data packaged with interpretation rules**
**tailored tags and document structure**
**community of interest (namespace) agreement on tags & structure**
**ASCII text ******** machine & man readable**
**DBMS not required to examine schema or retrieve data**
**users can leverage search engines to locate appropriate data sources**
**Emerging industry data/metadata interchange standard**
**Microsoft Office 2000, Oracle 8*****i***
**Messages (USMTF & EC/EDI)**

- Begin Tag

- End Tag

- Value

## COE 4.x Data Sharing Techniques

**GSORTS**

**JTAV**

**Data Sources**

**C Interface**

**JDBC**

**ODBC**

**Java Classes**

**API Layer**

**App**

**COP**

**App**

**GCSS**

**Browser**

**COE**
**Applications**

**Data Source **
**Connectivity**

**Base-level Objects**

**Integrated Data Object Model (UML)**

**Data**
**Access**
**Mechanism**

*Medium*

*Tightest*

*Loose *

**HTTP**

**XML**

***Mediation***

***Shared ***
***Data Server***

***XML- Web***

**Common Representation**

*******(JCC)**

*******Portal**
**     ****(JCC)**

**TDBM**

**GF**

**XML**

**Notes:**
Here’s the way we doing Data Access in COE v4.x.    The COE provides components to build what we’re now calling  “portols”  which can connect the warrior with structured and semi-structured data derived from both COE and non-COE sources. These portals are comprised of platform independent, self-describing XML, various mediators, and “Libranians,” all integrated in a Common Server Architecture to form data service federations with varying degrees of “tightness.”  (I.e., read-write, read only but integrated, browse the web etc.).  
I don’t have to tell you data professionals that the major stumbling block in doing all this is the problem of Semantic Hetereogeneity. Well . . within the COE, we’re trying to take on the semantics issue though our usual components-based approach coupled with what we call the “common representation of battlefield data.” 

Cache requires to be refreshed within browsers to ensure accurate uptodate data has been accessed.

## XML is GREAT, BUT . . . 

**XML Tower of**** ****Babel**

**XML is *****GREAT*****, **_**BUT**_** . . . **

**Management**** **_***Required***_** for Interoperability**** **
**Conflicting ****XML **_**must**_** be avoided!**
**Tags with overlapping definitions will make horizontal integration *****difficult or impossible***
**Each tag *****must***** be unique within its namespace**
***Without***** aggressive management ...**

**COE Developers**
**Asking for Help!!**

**Notes:**
XML offers tremendous opportunities for data interoperability, but there are significant challenges for harnessing the full potential.   
We must avoid a potential proliferation of tags being developed, that we characterize as an XML Tower of Babel.  COE Developers have already recognized this and are already asking for guidance, both for a tag source and for tag naming conventions.  The SHADE response is 3 fold:  
First, provide a common representation of battlefield objects in XML, as well as more traditional data formats.  I’ll elaborate more on this point in the next slide.
Second, provide a forum for surfacing and discussing XML issues.
Third, provide a Registry so that developers can reuse existing tags, because the appropriate reuse of a tag provides data interoperability.

## Principles which shapeMarket-Driven Data Strategy

**Focus on Common *****implementable***** Components **
**Seek commonality mainly within Communities of Interest (COIs)**
**Develop common representations for 20% of data to satisfy 80% requirements**
**Create market environment to exploit survival of “fit” data representations in various domains**
**PMs and their engineering staffs are primary marketplace players**
**Provide visibility for existing implementations thru Data Component registry with low barriers to entry**

## Data Component Market

**Data Component Market**

**Program **
**Data Engineers**

**PMs**

**Acquisition**
**Review Processes**

**Electronic**
**Mktplace**

**Info Systems Programs**

**Common Infrastructure**
**Program**

**Chief**
**Engr**

**Data**
**Engrs**

**Simple, **
**non-bureaucratic**
**organization**

## XML Governance . . .COE Approach

- Sticks:
- Distribute accountability
- Set reasonable interoperability technical goals
- Measure progress version-to-version
- Carrots:
- Reduce developers’ cost, schedule, risk
-  (give ‘em components that are tested and _free_)
- Enablers:
- Common Representation
- XML Registry (market visibility service)
- Namespace (communities of interest) concept

## Market for XML Tags

**Developers *****KNOW***** they need matching tags**
**Must be easy to locate and down-load**
**Developers come from multiple communities with different but overlapping semantic legacies**
**C2, Intell**
**Combat Support Logistics**
**Personnel/Medical**
**Finance**
**XML tied into other data engineering initiatives**
**Re-use previous investments in Battle space data definition**
**Need XML Tags and Valid Values  **_**ASAP**_

## COE XML Management Structure

**Visibility Service:**
** ****XML Registry within COE Data Emporium**
**Coordination:**
**XML Sub-panel to COE Data TWG (SSD-MD)**
**Individual Community CM venues**
**Must deal with other DoD, Allied, and Commercial XML activities**
**XML CM Responsibility:**
**distributed across COE Engineering Staff and Namespace Managers **

## What is a Namespace?

**A set of names that are managed by Agencies/activities/system builders/PEOPLE who:**
**Share a relatively discrete Subject Area**
**common world view**
**common abstractions, common data representations, and common metadata.  **
**“****Publish” existence of Namespace AND available XML documents so that outsiders may:**
** ****discover XML tags**
** ****assess whether or not they want to use them**
** ****download XML for re-use**

## XML Namespaces

_**Definition**_**: a collection of names, identified by a URI reference**
**namespace prefix (COE) serves as a proxy for a URI reference (COE_Enterprise)**
**Example: ****xmlns:COE=‘http://diides.ncr.disa.mil/xmlreg/COE’**
_**Purpose**_**: to distinguish homonyms**
**“****tank” as large vessel for storing fuel**
**“****tank” as armored vehicle**
_**Status**_**: W3C Recommendation (14-January-1999)**
_**Example of Qualified Tag**_**: ****<COE:CTRY_NM>**
_**Example XML Fragment**_**:**** **
**<COE:CTRY_NM> ****AFGHANISTAN**** </COE:CTRY_NM>**

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

- Namespace Prefix

- Separator

- Tag

## Guiding Principles for COE XML Registry

**Technical requirement**
**Ensure uniqueness of tags and schemas in use (e.g., port assignment on network)**
**Management Objectives**
**Provide opportunity to identify synonyms across namespaces**
**Arrange process to converge identified synonyms within a CM process using a cost-benefit, prioritization basis**

***Purpose is uniqueness via visibility,***
***not standardization through coercion!***

## Market Visibility Service:COE Data Emporium 

***Key to Consistent Interpretation of XML Data***

**XML guidance for developers**
- Registry of tags, data structures, and DTDs

***Market Visibility Service:*****COE Data Emporium **

- Reference Data Sets
**FIPS & ISO Country Codes**
**Ship Control Number**
- Database Segments
**Organization**
**Facilities**
**Plans**
- Integration Views
**GCSS UML Model**
**FIPS to ISO country cross-reference**
- XML Registry

**COE Data Components**

**Notes:**
With the benefits that XML can bring, there are also significant
challenges that COE must anticipate.  There are Extremely low entry
barriers for using XML.  The tags and XML documents can be created
with mere editors.  The result is likely proliferation of
non-interoperable tags.  Desired, recommended tags need to be
collected, validated and visible for developers to reuse.  

What is needed is a simple, flexible, affordable, domain-focused
approach for tag and DTD management.  The COE Answer: a Design MOF -
COE XML Registry, which will be available, on the Web next month.  The
initial tags that populate the registry will come from the JCDB
collaboration, to ensure interoperability between the relational
database format and the XML format.

The XML Registry will provide tag guidance for COE developers in a
web-enabled manner.

## COE XML Registrycontains many types of relationships

- XML_Element
- helicopter_type_and_model

- Domain
- helicopter_type_and_model domain

- XML schema
- ATO confirmation

- XML schema
- Maintenance Schedule

- XML Stylesheet
- ATO as Gantt Chart

*contains*

*contains*

*Is styled by*
*styles*

*Is constrained by*

- XML_Element
- latitude

## Leveraging a 30-year investment in semantics

**Leveraging a 30-year investment in semantics**

- 3141 in generalized domain for aircraft!
- 648 in specialized domain for helicopter!!

## Lessons We Share

**Leveraging current investment - USMTF and XML conceptually the same, yet...**
**Punctuation**
**Spaces, Commas, Quotes, Apostrophes, Leading digit, Parens, Slashes, Hyphens**
**Duplicates**
**Composite (aggregations or complex) tags**
**Must be named uniquely**
**Deconflicted with atomic tags**
**Security Concerns**
**Release-ability (FUD vs Group vs Set vs Segment vs Msg)**
**Registration process provides additional quality control **
**USMTF head start over industry: **
**Configuration Mgmt process in place**
**Large constituency**
**Represents an extensive set of common concepts, complete with valid values**
**Not just a specification, but also an implementation**

**Notes:**
USMTF similar to XML, but there are differences that require resolution.

We want the highest level of visibility for atomic tags (FUDs) so they will have maximum potential reuse.

Xmlmtf Registration process improved USMTF standard and improved Registry
Identified virtual duplicates
Batch loading for existing semantics

Instant dictionary of terms (with constituency) to draw from!  No parallel for industry.  Discourages non-productive development of synonyms.  

## Notional use case for Registry

- In Registry:
-   Information Resource
-     Namespace: MSG
-     Name: HELICOPTER_TYPE_AND_MODEL
-     Version: 1.0.0
-     Description: A non-negative, decimal amount used in transactions.
-     Data Type: STRING(6)
-     Domain: 2000_513_2_helicopter_type_and_model.xml
- In DTD:
- <!ELEMENT HELICOPTER_TYPE_AND_MODEL (#PCDATA)>
- <!ATTLIST HELICOPTER_TYPE_AND_MODEL
-    xmlns:nsname CDATA #FIXED 'http://diides.ncr.disa.mil/xmlreg/MSG'
-    xmlns:version CDATA  #FIXED '1.0.0'>
- In XML document:
- <!DOCTYPE ATO SYSTEM “ato.dtd">
- <HELICOPTER_TYPE_AND_MODEL>AB206A</HELICOPTER_TYPE_AND_MODEL>
- <HELICOPTER_TYPE_AND_MODEL>AH1G</HELICOPTER_TYPE_AND_MODEL>

- AB-206A JETRANGER

- AH-1G HUEY COBRA

## Recommendation #1(XML Tag Registration Requirement)

**Recommendation #1*****(XML Tag Registration Requirement)***

**Configuration Review Control Board (CRCB) direct (via I&RTS 4.0) COE Developers using XML for public interfaces to:**
**Consult XML Registry before creating new Tags and reuse existing XML where practical**
**Indicate planned use of Registered Tags by formally subscribing to them**
**Submit (where required) **
**additional XML tags (and amplifying information) or**
**recommended modifications to existing tags**

## Recommendation #2 (Management of Namespaces)

- Namespace Managers Roles and Responsibilities
- Candidate Namespaces

- Approved

*With* CRCB concurrence, DII COE Chief Engineer will:
- Charter selected agents to manage XML Namespaces
- Example: USMTF Program AO to manage XML-MTF tags
- Manage COE Enterprise Namespace

**Recommendation #2***** ******(Management of Namespaces)***

## Namespace Management Tasks 

**Namespace Management Tasks **

**Coordinate Stakeholders**
**Establish and Run Coordination Venue(s) **
**Resolve Issues within Namespace**
**Coordination across Namespaces **
**Oversee Development of XML Documents, DTDs, XSL style sheets **
**Submit Information Resource Packages to XML Registry**
**Approve Tags and Publish Status**
**Perform Versioning**

## Namespace Selection Criteria“K.I.S.S.”

**START SMALL!!  Don’t want lots of Namespaces**
**Don’t want to create NEW organizations**
***Look for***** existing Data groups (stay at PM level)**
**Capitalize on investment in Data Stores/ Messages**
***Look for***** existing Data Resources (which can be efficiently converted to Tag Starter sets)**
***Look for***** Key Data Resources on which mainline C2I/CS systems depend to form **“XML Starter Sets”
**Management load distribution**
***Look for***** a few complementary Namespaces which cover C2I/CS requirements**

## Namespaces and Designated Managers

**Namespaces and Designated Managers**

**COE Enterprise/DISA **
**COE Chief Engineer**
**Ground Operations/Army**
**PM for JCDB**
**General Military Intelligence/DoDIIS **
**PM for MIDB**
**Aerospace Operations/USAF**
**AF Common Data Environment staff**
**Messages/DISA**
**Chair USMTF Configuration Control Board**
**Tracks and Reports/Navy**
**Common Track Data Store Engineer**
**Geospatial and Imagery/NIMA**
**NIMA Engineer**
**METOC/Navy**
**Principal on developer of meteorological and oceanographic models**
**Combat Support/DISA**
**GCSS Engineer**

## XML Convergence Process

**AOG and CRCB designate namespaces & managers **
**Overlap among Namespaces is inevitable **
**Namespaces as “Buckets” for in-use XML**
**Entry points for XM L Registry submissions **
**Status mechanism (developmental, candidate & approved) provides ability to express preference**
**COE Enterprise Namespace holds “preferred” XML**
**Identified and approved by Chief Engineer**
**SSD-MD Subpanel as Namespace Managers’ Forum**
**Each Namespace has collaborative venue**
**Registry provides XML “Market” visibility**
**Includes system *****and***** developer usage information**

## Proposed Additional Namespaces

**Personnel/DIMHRS (Bob Buckley)**
**Defense Integrated Military Human Resources System**
**Finance/DFAS (Wayne Bodle)**
**Defense Finance and Accounting System**

## The Race for “XML Mgmt Guidance”

**COE Configuration Review Control Board**
**NATO**
**Data Systems Interoperability Panel (DP), Military Communications Electronics Board**
**Joint Battle Center**
**Office of Secretary of Defense**
**DoN XML Implementation Guidelines**
**Intel Community**
**AF XML Policy**
**OSD Acquisition and Technology**

## DII COE XML Registry

**IOC 17 May 1999**
**Public Access**
**Password protected **
**Secret coming soon**
**CRCB Approved**
**XML Registration**
**Namespace Creation**
**Namespace Status**
**9 Approved, 2 more Proposed**
**Registration Status**
**~ 7K elements**
**NATO request for software**

- http://diides.ncr.disa.mil/shade

## For more information contact

- COE Chief Engineer: Mr. Kenneth Wheeler - wheele1k@ncr.disa.mil
- Mr. Pete Pasek - pasekp@ncr.disa.mil
- Mr. Jim Pipher - pipherj@ncr.disa.mil
- Ms. Toni Weir - weirt@ncr.disa.mil
- Mr. Stan Davis - davis2s@ncr.disa.mil
- Ms. Ellen Minderman (FGM) - minderma@fgm.com
- Dr. Glenda Hayes (MITRE) - ghayes@mitre.org

**SHADE Data Emporium**
**http://diides.ncr.disa.mil/shade**

## BACK-UP

## XML Registry Payoff

**XML Registry Payoff**

**Enables developers to easily share data definitions and valid values**
**Obviates need to “reinvent” data structures already available**
**Applications can be developed faster-cheaper because data definitions and data values are reused**
**Appropriate metadata can be found easily because tags have amplifying information**
**Metadata stored in COE-compliant DBMS provides for easy access, analysis, and manipulation**
- Bottom Line:** **
_*Interoperability*_* *- System A’s XML *matches* System B’s XML

## Federated Communities of Interest

**COI**

**COI**

**COI**

**COI**

**COI**

*Need some horizontal & some vertical*

- More standardized
- within COIs (tightly
- coupled)

- Less standardized
- between COIs
- (loosely coupled)

## Principles (cont’d)

**Manage DoD Data Component registry via enterprise level engineering organization**
**Re-use existing implementable data components vice inventing new representations**
**Grade Data Components using interoperability **_**investment**_** and **_**usage**_** Metrics **
**Apply interoperability metrics, usage metrics and incentives to evolve commonality among representations over time **
**Evaluate components in registry using systems’ builders and warrior-customer reps**

## Principles (cont’d)

**Identify key existing data resources and engage their management in distributed CM processes**