1. Dr. Glenda Hayes MITRE/DII-COE SHADE
XML Mgmt Update
Dr. Glenda Hayes
MITRE/DII-COE SHADE

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

3. Data Management Challenges
Expect Heterogeneity!
No Single Standard can be imposed!
Various DoD communities will adopt multiple “standards:”
Government (message, database, symbology), Commercial, International, de facto/legacy etc.

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

5. Management Options Contrasting Styles
What will work for Defense?
TIGHT
Top-down, “Command”
versus
Market
SPECTRUM OF CONTROL
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.
Recommended Approach:
Market with Some Controls
LOOSE

6. Principles from President Bush
Citizen-centered
Results-oriented
Market-based
Mar-15-01

7. Key Management Mechanism
Developers and Warriors
Asking for Help!!
What data is available?
Which data is better?
Who has it?
How do I get it?
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 Visibility

8. Market Players Developers Community Data Managers
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.)
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.

9. Must engage “hands on” Developers who build important Data Resources!
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”
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.
Must engage “hands on” Developers
who build important Data Resources!

10. 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
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.
Purpose: visibility and re-use, not standardization through mandate!

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

12. Configuration Control
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
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.”

13. 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
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
Purpose is management visibility and re-use, not standardization through mandate!

14. 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
Well over a year ago, the flag-level officers governing the DII-COE approved guidance for XML in the COE.

15. Namespaces/Managers 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
Other Proposed
Logistics
MASINT
NBC
Transport
Training
Trade/Export
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.

16. DII-COE XML Registry Update
Features
Structure/Schematic
Submission Process
Submission Assistance
3 case studies
Namespace Population Status

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

18. DII-COE XML Registry Resources and Relationships…
Information Resources and Relationships
XML schema
ATO confirmation
XML_Element
helicopter_type_and_model
contains
latitude
XML schema
Maintenance Schedule
contains
DescribedBy
Amplifying Doc
IDEF1x model
XML Stylesheet
ATO as Gantt Chart
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.
Domain Document
helicopter_type_and_model domain
IsConstrainedByDomain

19. DII-COE XML Registry Information Resource Types
Manifest
an XML document IAW
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
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
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.

20. DII-COE XML Registry XML Component Submission Process
1) User submits package (wo/write cap)
2) Verifier s to DISA
3) DISA screens for embarrassing material
4) DISA submits package (w/write cap)
DII-COE XML Registry 1
BookshopSubmission.zip
Registry
Submission
Package
Verifier
Registry DB 4 3
Submission
Script 2

21. DII-COE XML Registry Submission Package Example
Package Contains
1 manifest (XML)
0+ docs
0+ domain docs (XML)
0+ schemas
Submission.zip
Manifest.xml
bookshop.gif
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.
con_genre.xml
con_yesno.xml
Bookshop.xml
BookshopStyled.xml
Bookshop.dtd
Bookshop.xsl

22. DII-COE XML Registry Leveraging Existing Metadata Assets
Exports from Modeling Tools + MITRE Prototype Submission Assistance Tool
xml
Domain
Values
Submission
Manifest
Erwin
Domain-Child
Info
Winzip
SAT1*
Rational
Domain
Values
Child
Info
Domain
Values
Domain
Values
Domain
Values
SAT2*
Parent
Info
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.
Registry Verifier
Parent-Child
Assoc
XML Schema
(DTD, Schema)
COE
XML
Registry
Registry
Ingestor
SAT = Submission Assistance Tool

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

24. USMTF & xml-mtf USMTF xml-mtf MSGID/TACREP/CTF 124//
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//
Data Dict
<XSL>
<?xml version="1.0" encoding="UTF-8"?>
<TACTICAL_REPORT>
<MESSAGE_IDENTIFICATION>
<MESSAGE_IDENTIFIER>TACREP</MESSAGE_IDENTIFIER>
<ORIGINATOR>CTF 124 </ORIGINATOR>
</MESSAGE_IDENTIFICATION>
...
</TACTICAL_REPORT>
xml-mtf
USMTF = United States Message Transmission Format MIL-STD 6040

25. xml-mtf Elements Registered

26. 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
in GMI Namespace:
2000 XML Elements
228 Domain Docs
1 XML doc mapping short names to long names

27. MIDB Elements Registered

28. MIDB Domain Values Registered

29. 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
<minInclusive value = "1"/>
<maxInclusive value = "5"/>
<maxLength value = "5"/>
<pattern value = "[a-h|j-n|p-z|A-H|J-N|P-Z]{1,3}"/>

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

31. XML Coordination and Guidance

32. XML Management “at-a-glance”
DISA Engineering
Staff
Namespace
Managers’ Forum
Supports
Operates,
Maintains
Participate in
Governs
Namespace Managers & WGs
Namespace Managers & WGs
Namespace Managers & WGs
XML
Registry
Hosts
Consults & Submits
to/Downloads from XML Registry
Participates in
DATATWG XML
SUB PANEL
DOD Developer
Participates in

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

34. DII-COE XML Guidance XML Data Compliance
Integration and Runtime Specification
DII-COE Compliance Level for XML 8
Reconciled Differences with Standards 7
Used “Production” Components from COI
Submitted Mapping of Logical Model to Physical Schema 6
DII COE
I&RTS 5
Submitted XML Components to Registry

35. 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
The SSD-MD is the XML forum for the DII-COE.

36. XML Coordination DII-COE XML Forum (cont’d)
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
Next Meeting: 27 April

37. 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.        
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).
Next Meeting: 10 May

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

39. Contact Information
Mr. Pete Pasek -
Mr. Jim Pipher -
Mr. Stan Davis -
Ms. Toni Weir -
Ms. Alesia Jones-Harewood –
Ms. Ellen Minderman (FGM) -
Dr. Glenda Hayes (MITRE) -
Mr. Chuck Heazel (MITRE) -
SHADE Data Emporium

40. Backup

41. DII-COE Guidance CIO EB CIO EB – DoD CIO Executive Board
Top Level Oversight
CIO EB – DoD CIO Executive Board
AOG – Architectural Oversight Group
CRCB – Configuration Review Control Board
TWG – Technical Working Group
Establishes/Advises on
DOD Policy
CRCB
Flag Level
Mgt Directions
Selects or Mods Tech & Mgt Options
AOG
Specific
Tech & Mgt Options
Establishes TWG Priorities
DATATWG
Solicits Inputs from
Services/ Agencies
Namespace
Mgrs Forum
SSD-MD (XML)
Subpanel

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

43. Viewing the Intermediate Results Enumerated Domain

44. MIDB Baseline Submission Package

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

46. Exploit Observed Commonality!
Analyzing the Market
Registry support for Market Analysis:
ID of duplicate terms
XML Component “page” visits, downloads and subscriptions
ID of users
COE Compliance
Lat
Long
XML Registry
ENT ?
Lat
Long
Lat
Long
Lat
Long
Lat
Long
Lat
Long
AOP
GOP
TAR
GEO
GMI
MET
PER
FIN
Exploit Observed Commonality!