Dr. Glenda Hayes MITRE/DII-COE SHADE 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 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.

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!

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

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

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

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.

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!

Electronic Market DISA’s Data Emporium http://diides.ncr.disa.mil/shade “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!

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.

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

Electronic Market Place XML Registry http://diides.ncr.disa.mil/xmlreg 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!

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.

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.

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

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 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 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) DII-COE XML Registry 1 BookshopSubmission.zip Registry Submission Package Verifier Registry DB 4 3 Submission Script 2 email http://diides.ncr.disa.mil/xmlreg/XMLUserSubmitForm.cfm

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

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

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

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 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 <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}"/>

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

XML Coordination and Guidance

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

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

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.

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

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

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

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

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!