# Presentation: 109804

## XML Mgmt Update

- Dr. Glenda Hayes
- MITRE/DII-COE SHADE

## Agenda

- Market-Driven Data Strategy
- Electronic Marketplace For XML
- DII-COE XML Registry
- XML Coordination & Guidance

## Data Management Challenges

- No Single Standard *can* be imposed!
- Various DoD communities _will_ adopt multiple “standards:”
- Government (message, database, symbology), Commercial, International, de facto/legacy etc.

_**Expect**_** Heterogeneity!**

## XML Management Challenges One Language, Many Vocabularies

- <lat_deg>30N</lat_deg>

- <latitude units=“degrees” hemisphere=“north”>30</latitude>

- <latitude>
-   <hemisphere>N</hemisphere>
-   <degrees>30</degrees>
- </latitude>

**These 3 XML fragments are:**
**Equally valid ways to express the same data in XML**
**Well-formed per W3C Specification**
**Different terms **_**and**_** XML structures****  **

_**NOT INTEROPERABLE!    **_

**Notes:**
XML schemas and XML documents can be developed with a text editor, although there are free or cheaply-available tools to assist in their production.  This creates a situation where the bar is so low that it becomes trivial to develop a vocabulary – one that is well-formed and valid and non-interoperable with others.

## Management OptionsContrasting Styles

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

**LOOSE**

**TIGHT**

**SPECTRUM OF CONTROL**

***What will work for Defense?***

**Recommended Approach:**
_**Market**_** with *****Some***** Controls**

**Notes:**
This is the key question that XML forced us to grapple with.  Exactly what kind of management are we talking about?   XML is typical of new information technologies.  Powerful, easy to implement, highly volatile, even chaotic, and rapidly expanding into a wide variety of domains with very little in the way of autocratic guidance.  
What do you get when you try and drive a complex adaptive system such as a national economy with a Top Down, Command approach??  Among other things, you get a GREAT BIG BUREAUCRACY. Lots of policy-makers, middle managers, and low level checkers. And most often it’s rigid, unresponsive, slow to adapt . . . in a word: INEFFECTIVE.  
Well, today’s information systems environment is VERY big, diverse and complex, with many many players, government and commercial, and many-to-many relationships, and it’s certainly NOT under anyone’s control.  What we have is BOTH an increasing demand for and an evolving supply of information products or services surging around in one of the hottest markets ever known!  In situations like this, you not only CAN use market forces to do some managing. You’ve GOT to!
And of course we all learned in History 101 that there ARE significant hazards with TOTAL unconstrained “laissez-faire” capitalism, SO our Publish&Subscribe marketplace needs some rules, some controls, a staff of referees, maybe a light weight board of governors here and there.

## Principles from President Bush

- Citizen-centered
- Results-oriented
**Market-based**

*Mar-15-01*

## Key Management Mechanism 

**Key Management Mechanism **

**Market Visibility**

**Developers **_**and**_** Warriors**
**Asking for Help!!**

_**What**_** data is available?**

_**Who**_** has it?**

_**How**_** do I get it?**

_**Which**_** data is better?**

**Notes:**
Now we can’t harness market forces without implementing some key mechanisms.   The kinds of questions we’re getting from a new generation of Developers and Warrior-customers are giving us some BIG clues about what is required. 
Today’s developers and warriors recognize that there is a tremendous volume and variety of data resources being hooked up to our networks, and they are asking for guidance.  Asking for someone and/or something to answer these kinds of questions for them.  What information resources are on a given network? What specific data can they provide?   Which ones are authoritative?  What is the technical nature of these resources?  How can I connect to them?  How can they be hooked together to fuse data?
To answer those questions, the first thing we need to do for BOTH developers and warriors is make easily visible and accessible a selection of important metadata.  Not just once, but on an ongoing basis.  Everything from URLs to general product or service descriptions to specific APIs and other “in-use” vocabularies have to be dynamically exposed in some consistent manner in some consistent, probably “virtual” place. 
Here, I want you to take away one of our most basic principles. Any market-driven management approach has a fundamental prerequisite:  Visibility!  You can’t manage what you can’t see.  You can’t use something if you don’t know it exists. To the extent that this metadata service actually HELPS developers and warriors by answering their data exchange requirements, by reducing risk, cost and schedule, they’ll buy into using it. 

## Market Players

**Developers**
- Re-use available data components and/or Register new ones they have created
**Community Data Managers**
- Use Market visibility services for configuration control (e.g., current version distro, version change notification etc.)
**Defense Acquisition Policy Makers**
- Use Market metrics for acquisition oversight (e.g., reflecting Program participation, specific data component re-use etc.)

**Notes:**
First the Build-Time.  Who specifically are the Market Players, the “customers” who are using this market service? 
This Marketplace is the way we are trying to take care of our information system builders and maintainers, to provide sharable data components under a configuration control process that’s broader than just one system.   And to supply our systems acquisition oversight at various levels with some “hard facts” about who’s doing what with the various sponsors’ monies.  
From a system builders point of view, the incentives for being in this market are (1) reductions in risk, cost and schedule with respect to fielding interoperable capabilities, and (2) the possibility of having some of his data components gain market share and become key infrastructure that sponsors are willing to sustain.  We’ve seen COTS vendors respond to these pressures . . .  where Oracle, SyBase and Microsoft have all segmented products to become viable in the COE infrastructure market.

## Market Features

- _Low barriers_ to entering the process
- _Electronic Marketplace_ as ***Visibility*** mechanism
- _Components_ as unit of exchange (commodities)
- _Communities_ of Interest (COIs) as arenas for trade
- _Program_ Engineers as primary “traders”

***Must***** engage “hands on” Developers**
**who **_**build**_** important Data Resources!**

**Notes:**
Now, we’ve learned from experience that the Built-Time market has to explicitly recognize and implement these important features. And some of these are counter to the old way of doing Data Administration.
First – we don’t want it to be exclusionary.  We WANT players to enter the game.  Anyone who doesn’t enter is invisible and can’t be managed by the market.  So entering  the marketplace has to be EASY.  
Second – we need to have a real, physical, electronic marketplace, something like the stock market has, where ANY player can see details on what’s available and to publish info about what she or he has to offer.
Third – we need real, physical commodities for our market.  In this case the commodities are data components of various kinds (XML elements, various kinds of schema, valid values, translation and transformation software etc.)
Fourth – As I’ve intimated, Defense is far too BIG and complex to be called a single Enterprise.  Defense includes virtually the full range of business activities, some very close to commercial counterparts; some fairly specific to warfighting.  So we need to explicitly define Communities of Interest, groups of frequent trading partners if you will, that conduct business in substantially different (although overlapping) domains. In doing this, we don’t want to swim against the tide. We want to endorse communities and authorities that are “naturally occurring.”
Fifth – the key players in our market are the guys with the gold.  If you don’t DIRECTLY control important development resources, you can’t be an effective player, and IF the people who DO control development resources aren’t in our market, well . . . the market will fail.  The truth is that the players with the money are the people we want to trade in the marketplace.  We need the market forces to work where program management staffs oversee development teams and tell them directly what to build and how.

## Electronic Market DISA’s Data Emporium 

**“****One Stop” Publish & Subscribe for Defense Metadata**** **
**Data Component Registration**
**COI Creation & Management**
**New Version Jan 01**
**Public Access via WWW **_***plus***_
**Password protected and classified instances**

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

***Purpose: visibility and re-use, not standardization through mandate!***

**Notes:**
Now here’s our baseline electronic marketplace – “one-stop shopping” for all your Build-Time metadata needs. Our XML Registry is one part, one “gallery” of this Data Emporium. Other parts of the Data Emporium are:
Reference data sets (the data structure for frequently used indexes and codes like country code packaged WITH valid values)
Data base segments (Pre-packaged for easy installation relational database schema also with valid values where available)
Again, the purpose of the Emporium is mainly to register “in use” data in various forms, SQL, UML, XML, and to provide an easy way for developers to download data components for re-use.  We accept that there are inconsistencies and overlaps.  The important thing is to get these “commodities” into a market and see who’s “buying” what.  
Parenthetically, we’re still working on the market’s ability to track activity with respect to certain data commodities, BUT I can tell you that right now, the Emporium is drawing about 100 hits per day.  Not bad for a geeky little site.

## Marketplace Rules

**Marketplace Rules**

- Data Component Registration
- Consult Emporium before creating new components and reuse existing data where practical
- Indicate planned use of components by formally subscribing to them
- Register additional components or recommended mods
- Communities of Interest (COIs) Formation
- Created “as required” *when* someone will agree to manage
- Requirements for new COIs staffed with:
- Existing COI Managers
- Senior Service/Agency engineers
- Flag Level Review Board

**Notes:**
Next, like any marketplace, there’ve gotta be some rules.   These are the first rules we got “blessed” (over a year ago) as DII-COE approved guidance for XML.  Right now, these rules are being extended to cover all DoD.   No surprise . . . these rules are aimed at promoting data market visibility and re-use.   If you’re building a data service, the rules say . . . Before you burn resources and create something from scratch, take a look in the Emporium and see if what you need is already there!   Common sense.  If you find stuff you like, download it - copy and paste – into your  program and,  oh-by-the-way, fill out a little form so the market knows you’re using it, and can keep you up on any changes, can allow you , in essence, to have a say in its configuration management.   Common sense.   And where you DO need to create something new, well . . . Register it so others can see it IF their system needs to talk with your system or so they can apply it to create  other interoperable capabilities. 
And then at the management level, do you find existing Communities of Interest that “fit” your stuff or does there need to be another COI added.  If so, is there someone who feels strongly enuff to actually sponsor a Community, provide a couple of admin staff-years to run a coordination venue etc.  If so, there’s a process to vet a new COI and get it added to the marketplace.

## Market Organization

**Market Organization**

- Configuration Control features:
- Distributed across DISA Engineering Staff *and* “Hands On” Managers from multiple COIs
- Capitalizes on existing configuration control bodies
- COI “Managers” govern data in multiple _physical_ forms
- Coordination Venues:
- Individual COI “boards”
- COI Managers’ Forum
- Data Technical Working Group  (_Any_ voice heard)* *
*Ad hoc* contacts with other Government, Allied, and Commercial activities

- }

**Configuration Control **
**Organizations**

**Notes:**
Like any market, in addition to customers, there have to be some managers.  Our position is that no single organization can manage Defense data, and it’s not just the administrative load . . . It’s also the requirement for lots of different domain expertise.  Build-Time Data Management MUST be distributed across our common infrastructure staff here at DISA and a bunch of other players in various sectors of the defense establishment.  Who are these managers?   Well, the important thing is that they NOT be high level.  Who we need handling these data “commodities” are TECHNICAL experts. We’re dealing in engineering artifacts, real implementable components, NOT high level, abstract concepts.  We’re managing the configuration of data components that are, in fact,  scripts, or XML documents, or at the most granular levels, metadata tags.   So a big part of market management requires engaging the hands-on  “owners” of real data resources, capitalizing on CM processes that in many cases they have already been instituted.  We need to co-opt existing and newly formed CM boards that control data components, and then we need to have a higher level board of these configuration managers who can be governors of the marketplace.  We also need an open technical venue that allows developers, policy makers or anyone else to be heard and to learn about what’s going on in the defense data arena, to surface technical or procedural issues and so forth.  And then there are a range of ad hoc coordination activities that the market “community” should foster, individually and collectively.
That takes care of the development community.  Now what about the warrior and other end-users?  This stuff is not pie-in-the-sky;  it’s real and we’re working toward these objectives. SO on the way from Build-Time to Run-Time,  I want to show you a kind of “half-way house.”

## Electronic Market Place XML Registry 

**IOC May 99**
**Public Access via WWW**
**(FOUO) Password protected**
**Improved Version Jan 01**
**10K elements and schema**
**SIPRNET version early CY01 **
**Handles**
**XML Registration**
**Namespace Creation & Mgt**
**CIO EB Expanding Scope**
** ****XML Registration Policy and Plan**

**http://diides.ncr.disa.mil/xmlreg**

***Purpose is management visibility and re-use, ***_***not***_*** standardization through mandate!***

**Notes:**
The XML Registry is only one part of the DII-COE Data Emporium – one-stop shopping for all your data needs.  Other parts of the Data Emporium are:
Reference data sets
Data base segments

## XML Market Place Rules

- XML Registration Requirement
- Developers using XML for public interfaces should:
- Consult XML Registry before creating new XML components and reuse existing XML where practical
- Indicate planned use of Registered XML by formally subscribing to it
- Submit (where required)
- additional XML components (with amplifying information) or
- recommended modifications to existing components
- Creation of XML Namespaces
- Formed “as required” *when* someone will agree to manage
- Requirements for new Namespaces staffed with:
- Existing Namespace Managers
- Senior Service/Agency engineers
- Flag Level Review Board
- CIO EB kept apprised

**Notes:**
Well over a year ago, the flag-level officers governing the DII-COE approved guidance for XML in the COE.

## COE/DISA 
Ground Operations/Army
General Military Intelligence/DIA
Aerospace Operations/USAF
Messages/DISA
Tracks & Reports/Navy
Combat Support/DISA
Geospatial & Imagery/NIMA
METOC/Navy
Personnel/DIMHRS
Finance and Accounting/DFAS
TBD/DISA
Enterprise/DISA

- Ground Operations/Army
- General Military Intelligence/DIA
- Aerospace Operations/USAF
- Messages/DISA
- Tracks & Reports/Navy
- Combat Support/DISA
- Geospatial & Imagery/NIMA
- METOC/Navy
- Personnel/DIMHRS
- Finance and Accounting/DFAS
- TBD/DISA
- Enterprise/DISA

- Namespaces/Managers

_**Other Proposed**_
- Logistics
- MASINT
- NBC
- Transport
- Training
- Trade/Export

**Notes:**
NBC = nuclear, biological, chemical
MASINT = measurement and signatures (intel – thermal, magnetic, acoustic)

There has been a conscious effort to identify and leverage existing programmatic sources to manage namespaces.  There has also been a conscious effort to spread the responsibility as evenly as possible.

## DII-COE XML Registry Update

- Features
- Structure/Schematic
- Submission Process
- Submission Assistance
- 3 case studies
- Namespace Population Status

## DII-COE XML Registry Features

- Search/Browse Filters
- Across or within namespaces
- By Information Resource Type
- By Substring in Name, Definition, Comment
- By Submitter
- By Status
- By Version
- Subscription
- On-Line Submission Pkg Verification & Submission
- On-Line Registry Administrative Features

**Notes:**
The prime directive is to make it as easy as possible for the developer to discover and retrieve reusable components if they are available and to facilitate the registration of new components.  

## DII-COE XML Registry Resources and Relationships...

_**XML schema**_
- ATO confirmation

- Information Resources and Relationships

**Notes:**
The Registry stores nodes and arcs, permitting the user to navigate among the information resources (the nodes) using the relationships (the arcs) that link the information resources.  Here is a high-level view of the Registry’s contents.

## DII-COE XML Registry Information Resource Types

**Manifest **
- an XML document IAW http://diides.ncr.disa.mil/xmlreg/DTD/registry.dtd
**Schema **
- e.g., Bookshop.dtd
**XML Element** (atomic and container)
- Atomic: Title
- Container: Book
**XML Attribute**
- e.g., Genre, in_stock
**Domain Document**
- an XML document IAW http://diides.ncr.disa.mil/xmlreg/DTD/registry_domain_values.dtd
- e.g., con_genre.xml, con_yesno.xml
**Stylesheet**
- e.g., Bookshop.xsl
**XML Example**
- e.g., Bookshop.xml, BookshopStyled.xml
**Amplifying Document**
- e.g., bookshop.gif

**Notes:**
Definition: An Information Resource (IR) is a component or product of an information system that can be defined, scoped, and managed for reuse.  
Technical Explanation: The IR can be either physical (e.g., file, database column, database record, query) or conceptual (e.g., entity, attribute, content model).  An IR may be atomic (e.g., .gif, .ppt, .doc), that is not practically divisible, or complex (e.g., zip, schema, collection), that is constructed from components that are themselves managed.  An IR may be electronically accessible (e.g., on-line material) or not (e.g., book, periodical).  A catalog can store the description of and relationships among information resources to provide the visibility required for discovery and widespread reuse. 

Although the COE XML Registry is currently scoped to include the types of information resources identified above, SHADE is not limiting an "information resource" to these, which brings our notion of information resource close to the Section 3502(6) of Title 44, United States Code.  The code defines Information Resources as "information and related resources, such as personnel, equipment, funds, and information technology.”  SHADE looked to the DDDS for a term that encompasses all the types of "information things" that need to be managed via a catalog (not just the COE XML Registry) to provide the visibility required for discovery and widespread reuse.  The DDDS records the term "information-asset" as an approved prime word, but the definition provided for information-asset is: An information resource.  Consequently, we chose to go with the term "information resource," based on our anecdotal evidence of the acceptance and use of the term within the computing industry compared to "information asset.“
We’ll scroll down on this page to find the instructions for how to submit XML Components to the Registry.

## DII-COE XML Registry XML Component Submission Process

- DII-COE XML Registry* **XML Component Submission Process*

- 1) User submits package (wo/write cap)
- 2) Verifier emails to DISA
- 3) DISA screens for embarrassing material
- 4) DISA submits package (w/write cap)

**Registry**
**DB**

**Submission**
**Script**

**DII-COE XML Registry**

**Registry**
**Submission**
**Package**
**Verifier**

**BookshopSubmission.zip**

***email***

**4**

**1**

**2**

*http://diides.ncr.disa.mil/xmlreg/XMLUserSubmitForm.cfm*

**3**

## DII-COE XML Registry Submission Package Example

- Package Contains
- 1 manifest (XML)
- 0+ docs
- 0+ domain docs (XML)
- 0+ schemas

**Manifest.xml**

*Submission.zip*

**con_genre.xml**

**bookshop.gif**

**Bookshop.dtd**

**con_yesno.xml**

**Bookshop.xml**

**Bookshop.xsl**

**BookshopStyled.xml**

**Notes:**
The Submission Package is a zip file containing 1 manifest (an XML file that conforms to registry.dtd), zero or more documents, zero or more domain docs (XML files that conform to registry_domain_values.dtd), and zero or more schemas (e.g., DTD, DCD, RDF, XDR).  

The diagram in the lower left provides a visual for the package and its contents.  In that example, the package contains a manifest, one generic document (the .pdf file), 3 domain documents (corresponding to the 3 other .xml files) and a single schema (.dtd).  

The screen capture on the right is a sample of the submission package from the work that SHADE is doing with the GMI Namespace Mgr.  Sometimes the package can get quite large.  Since DIA is doing the initial build of GMI by reusing the semantics from MIDB, the manifest is over 2M in size.  It does, however, zip down to a much smaller size, just over 200K.  

The manifest describes what is being registered.  Think of it as a packing list or a structured readme for the zip package.  The remainder of this briefing focuses on the content and structure of the manifest.

## DII-COE XML Registry Leveraging Existing Metadata Assets

- Domain
- Values

- Domain-Child
- Info

- Child
- Info

- Parent
- Info

- Parent-Child
- Assoc

- SAT1*

- Submission
- Manifest

- Domain
- Values

- Registry Verifier

- COE
- XML
- Registry

- Registry
- Ingestor

- Winzip

- xml

- Domain
- Values

- Domain
- Values

- Domain
- Values

- Erwin

- Rational

- SAT = Submission Assistance Tool

- Exports from Modeling Tools  +  MITRE Prototype Submission Assistance Tool

- XML Schema
- (DTD, Schema)

- SAT2*

**Notes:**
MITRE has recognized the need to leverage the investment made in developing the existing metadata resources and has been working with partners (such as DIA, DISA, DFAS) to incorporate the semantics into the XML Registry to form namespace (COI) vocabularies.

## Leveraging Existing Metadata Assets Case 1 - USMTF

- USMTF CCB
- Maintains Data Dictionary in relational database
- Algorithm to transform USMTF-to-xml-mtf
- Stylesheet to transform xml-mtf-to-USMTF
- Challenges
- Mismatch in Data Types with DII-COE Registry
- Lack of Name for Groups, Segments
- SHADE Strategy
- Enter FUDs (atomic elements)
- Enter Domains, link to FUDs, store xml files of domains
- Enter groups, sets, segments, messages
- Registration Status
- Messages Namespace
- 6165 XML Elements Registered (2/28/2000)

## USMTF & xml-mtf

- MAROP/011800Z/1/US/SUB/CL:WASHINGTON/NAME:SEAROVER
- /LM:4040N01100E//
- OPSUP/ACTTYP:ASW//
- AIROP/020200Z/6/US/FTR/F15/TN:401/LM:4130N01000E/CRS:180/SPD:600KPH
- /ALT:12000FT//
- OPSUP/ACTTYP:DCA//

*USMTF  = United States Message Transmission Format MIL-STD 6040*

- USMTF

## xml-mtf Elements Registered

## Leveraging Existing Metadata Assets Case 2 – Data Models

- MIDB
- Erwin Physical Model
- 7 add’l domain documents
- DIA-supplied Long Names
- Challenges
- Relational v. Hierarchical Models
- Erx errors
- Multiple techniques for storing domains
- SHADE Strategy
- Harvest metadata from erx
- Register Columns & Attributes as “atomic” XML Elements
- Register Tables & Entities as “container” XML Elements
- Register Enumerated Domains as Domain Documents
- Develop Viewer
- Register Better Definitions for Domain Documents
- Register Logical-to-Physical Mappings
- Register Parent-Child Relationships as “contain” relationships
- Register algorithmic constraints using XML Schema Definition

- Registration Status
- GMI Namespace
- 2000 XML Elements
- 228 Domain Docs
- 1 XML Mapping Doc

**Notes:**
in GMI Namespace:
2000 XML Elements 
228 Domain Docs
1 XML doc mapping short names to long names

## MIDB Elements Registered

## MIDB Domain Values Registered

## Leveraging Existing Metadata Assets Case 3 – XML Schema Definition

- Convert DTDs to XML Schema Definition
- Tool support is available
- Augment elements/attributes with
- Annotation
- Data Type
- Constraints
- Patterns
- Enumerated Values
- SHADE Strategy: Construct Submission Manifest Shell from .xsd
- No progress to report at this time

- <pattern value = "[a-h|j-n|p-z|A-H|J-N|P-Z]{1,3}"/>

- <maxLength value = "5"/>

- <minInclusive value = "1"/>
- <maxInclusive value = "5"/>

## DII-COE XML Registry Namespace Population Progress

- Messages
- 6165 XML elements
- Domain docs
- Container (complex) elements
- Aerospace Operations
- 1 DTD, 8 XML elements
- Ground Operations
- Technical coordination required
- Tracks and Reports
- 452 XML elements
- 1 schema
- 8 domain docs

- Intelligence
- 2000 XML elements
- 228 domain docs
- 1 mapping doc
- MDITDS request
- Geospatial & Imagery
- Baseline GML and IML
- Finance & Accounting
- Leveraging existing metadata
- METOC
- Leveraging existing metadata

## XML Coordination and Guidance

## XML Management “at-a-glance”

- Participates in

- Participates in

- Consults & Submits
-  to/Downloads from XML Registry

- Supports

- Governs

- Operates,
- Maintains

- Participate in

- Hosts

## XML Convergence Process

- Namespaces & managers chartered “as required”
- Overlap among Namespaces is inevitable
- Namespaces act as “Buckets” for in-use XML
- Managers run Working Groups (collaborative venues)
- Entry points for XML Registry submissions & Developer requirements
- Status mechanism (developmental, operational, deprecated) provides ability to express COI preference
- Enterprise Namespace holds DoD “common” XML
- Identifies and Registers “Common” XML from COI Namespaces
- Governed  by Namespace Managers’ Forum
- Registry provides XML “Market” visibility
- Includes system and developer usage information

## DII-COE XML Guidance XML Data Compliance

**  ****Integration and Runtime Specification**
**DII-COE Compliance Level for XML**

- 7

- 8

- 6

- 5

**Reconciled Differences with Standards**

**Used “Production” Components from COI**

**Submitted Mapping of Logical Model to Physical Schema**

**Submitted XML Components to Registry**** **

## XML CoordinationDII-COE XML Forum

- Sponsor (DII-COE DATATWG)
- Defense Information Infrastructure (DII)
- Common Operating Environment (COE),
- Data Access Services Technical Working Group (DATATWG),
- Semi-Structured Data and Metadata Subpanel (SSD-MD)
- Objectives
- Develop specifications and/or DTDs
- Select metadata standards and tools
- Create DTD repository / distribution mechanism / versioning management
- Provide guidance for tag terminology
- Develop “enhanced” XML editors for coded XML docs
- Develop application interpreters for XML
- Reference implementations

**Notes:**
The SSD-MD is the XML forum for the DII-COE.

## Meetings
Chartered by DII-COE Architectural Oversight Group (AOG): Nov 1998
Distribution List = 400 Names, Attendance = 70+
Bi-monthly meetings, 11 meetings since Jan 1999
Topics
XML Activities Survey
XML Vendor Briefings and Demos 
DII-COE XML Requirements
DII-COE XML Registry Debut
XML Technical Discussions
XML Policy Coordination
SOAP
XML Schema

- Chartered by DII-COE Architectural Oversight Group (AOG): Nov 1998
- Distribution List = 400 Names, Attendance = 70+
- Bi-monthly meetings, 11 meetings since Jan 1999
- Topics
- XML Activities Survey
- XML Vendor Briefings and Demos
- DII-COE XML Requirements
- DII-COE XML Registry Debut
- XML Technical Discussions
- XML Policy Coordination
- SOAP
- XML Schema

- XML Coordination*DII-COE XML Forum (cont’d)*

**Next Meeting: 27 April**

## XML Coordination XML Namespace Managers Forum

***Draft Forum Objectives:***
- Propose, review, and implement DoD XML policy.
- Develop and promote best practices in XML.
- Seek opportunities for convergence.
- Oversee the operation of the Registry.
- Determine what metrics to use, analyze and make recommendations as inputs to DoD and other policies (I&RTS, JTA)
- Define, review, update the procedures for the Namespace Mgrs Forum.
- Review proposals for additional namespaces to make recommendation to DII-COE AOG.
- Participate, Respect, and influence international and coalitions metadata standards.

**Next Meeting: 10 May**

**Notes:**
The popularity of the SSD-MD has required that the namespace mgrs have a separate forum for discussing Registry and Policy issues – especially as the DoD CIO Executive Board deliberates the XML Registration Implementation Policy (to be discussed soon).

## DoD XML Registration Policy Draft Implementation Plan Coordination

- CRCB directs Chief Engineer to propose DII-COE XML process for DoD
- Chief Engineer briefs DoD CIO EB **29 Aug**
- CIO EB asks for
- Draft registration Policy memo
- Draft implementation plan
- Resource assessment
- Staff through ASD C3I, USD AT&L, etc.
- Info Brief to CIO EB for status **May**

## Contact Information

- Mr. Pete Pasek - pasekp@ncr.disa.mil
- Mr. Jim Pipher - pipherj@ncr.disa.mil
- Mr. Stan Davis - davis2s@ncr.disa.mil
- Ms. Toni Weir - weirt@ncr.disa.mil
- Ms. Alesia Jones-Harewood – harewooa@ncr.disa.mil
- Ms. Ellen Minderman (FGM) - minderma@fgm.com
- Dr. Glenda Hayes (MITRE) - ghayes@mitre.org
- Mr. Chuck Heazel (MITRE) - cmheazel@mitre.org

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

## Backup

## DII-COE Guidance 

- Establishes TWG  Priorities

- Selects or Mods Tech & Mgt Options

- CIO EB – DoD CIO Executive Board
- AOG – Architectural Oversight Group
- CRCB – Configuration Review Control Board
- TWG – Technical Working Group

- Establishes/Advises on
- DOD Policy

**Namespace **
**Mgrs Forum**

**SSD-MD (XML)**
**Subpanel**

## Registration is Easy!

- Developer identifies or creates XML not currently registered.
- Developer creates Registry package for new XML and proposed mods.
- Developer submits Registry package via on-line capability, specifying an existing namespace.
- http://diides.ncr.disa.mil/xmlreg/XMLUserSubmitForm.cfm
- Registry Ops reviews submittal for propriety and registers package as “Developmental.”
- Receiving Namespace Mgr reviews submittal and accepts or rejects as properly belonging to another namespace.
- If rejected, Namespace Mgrs Forum determines whether another namespace will accept it.
- Upon developers' request, entries rejected by all namespaces are retained in TBD namespace.
- Namespace Mgrs may review accepted XML to change status from “Developmental” to “Operational.”

## Viewing the Intermediate ResultsEnumerated Domain

## MIDB BaselineSubmission Package

## Registered XML Status

- Developmental =  “Registered”
- Operational = Employed by Community
- Deprecated = Legacy Operational version (still “in use”)
- Retired = No longer in use

## Analyzing the Market

**Registry support for Market Analysis:**
**ID of duplicate terms**
**XML Component “page” visits, downloads and subscriptions**
**ID of users**
**COE Compliance**

**AOP**

**GOP**

**TAR**

**GEO**

**ENT**

**XML Registry**

**GMI**

**MET**

**PER**

**FIN**

**Lat **
**Long**

**Lat **
**Long**

**Lat **
**Long**

**Lat **
**Long**

**Lat **
**Long**

**Lat **
**Long**

**?**

**Exploit **_**Observed**_** Commonality!**