# Presentation: 752257

## DoD XML RegistryStatus

**Dr. Glenda Hayes, MITRE**
- Presentation to Federal CIO XML WG
- 20 Mar 2002

## Agenda

- Current Status
- DoD XML Registry
- COE XML Guidance Proposed for DoD Adoption
- Next Steps
- Convergence Task Force
- Create Reusable Domain Schemas
- Participate in NIST Registry Proof of Concept

## DoD XML Registryhttp://diides.ncr.disa.mil/xmlreg 

- “One Stop” Publish & Subscribe for Defense Metadata
- IOC May 99
- COI Creation & Management
- Public Access via WWW plus
- Password protected instance
- SIPRNET instance shortly

*Market-driven Approach to XML Mgmt*

## DoD XML Registry Features

- Search/Browse Filters
- Across or within namespaces
- By Substring in Name, Definition, Comment
- On Information Resource Type, Submitter, Status, Version, Domain Value, Date Range
- Navigate relationships among resources
- New Information Resource Type: Schema Data Type
- On-Line Submission Pkg Verification & Submission
- Manifest Schema uses W3C XML Schema Recommendation
- Password Protected Areas
- On-Line Registry Administrative Features
- Status changes (finer granularity)
- Status reports for Namespace Mgrs
- General/Overall Services
- Server-side certificate (DoD generated)

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

## DoD XML RegistryCommunities of Interest

_**Other Proposed**_
*NBC*
*Architecture*
- E-Business
- MASINT
- Document
- Training

## DoD XML Registry Current Inventory

- Documents - 631
- Domain Value - 774
- Submission Packages - 49
- XML Attribute - 981
- XML Element - 14700
- XML Sample - 21
- Schema - 89
- Schema Data Type - 16
- Stylesheets - 4

**Current As of 15 Mar**

*Includes Password-protected portions*

**Notes:**
These numbers include FOUO
“Old Numbers:
Documents – 589
Domain Value Sets – 608
Submission Pkg – 27
XML Attribute – 173
XML Element – 7391 + 6165 (FOUO)
XML Sample – 9
Schema – 46
Stylesheet – 2

+ 6165 (FOUO) from MSG

IR_TYPE_TX CountOfIR_TYPE_TX
InformationResourceSchemaDataType 21
InformationResourceTypeDocument 572
InformationResourceTypeDomainDocument 704
InformationResourceTypeXMLAttribute 701
InformationResourceTypeXMLElement 8019
InformationResourceTypeXMLSample 17 
InformationResourceTypeXMLschema 79
InformationResourceTypeXSLStylesheet 4
Package 40

## DoD Data EmporiumCustomer Service Transactions

- ’01 Emporium “hits” = approx 24K (100/day)
- XML Registry = 50-plus/day
- Other Emporium pages = approx 50/day
- Re-use of XML
- Army Intelligence Data Integration
- GCCS-I3 XML Target Folders
- Time Critical Targeting to use Wx and GMI XML
- Database Segment Re-use
- GMIDB for I3 data replication
- Clearinghouse Function
- 25 - 30 Q&A transactions/mo
- Initial Convergence Task Force
- Logistics/DFAS lead: Alcon to agree on “Postal Address”
- Proposed Conventions and Normative Schemas

**Notes:**
XML in ASAS, ASPO's TES, INSCOM's OSALAT, CI/HUMINT
AFTADS, FBCB2, AMDWS, GCCS- A, ASAS, IMETS, CSSCS, ISYSCON, DTSS, MCS, TAIS

## XML Registration Rules

**XML Component Registration**
- Consult Registry before creating new components and reuse existing XML where practical
- Indicate planned use of XML components by formally subscribing to them
- Register additional XML or recommend modifications
**Community of Interest Namespace Formation**
- 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

***COE Process proposed for DoD Adoption***

**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 looked at by ASD C3I as one way to govern data for 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.

## DoD XML Registration Policy Coordination 

**DoD CIO EB Actions**
- CRCB directs Chief Engineer to propose COE XML process for DoD
- Chief Engineer briefs DoD CIO Executive Board (EB) **29 Aug 2000**
- CIO EB asks for
- Draft registration Policy memo
- Draft implementation plan
- Resource assessment
- Staff through ASD C3I, USD AT&L, etc.
- Implementation Plan
- Version 6f Comments Received and Reviewed
- Version 7 to ASD/C3I **16 Jul 2001**
- Version 8 of Implementation Plan, Version 3 of Policy being drafted by ASD-C3I; Name Change Request: DOD XML Registry
- Brief to CIO EB for decision (To Be Determined)
**Federal CIO Actions**
- Coordination with Federal CIO
- Request to re-brief xml.gov
- Participate in NIST Registry Proof of Concept

## Analyzing the Build-Time Market

**Emporium support for Market Analysis:**
**ID of duplicate or overlapping terms, concepts etc.**
**Metadata Component “page” visits, downloads and subscriptions**
**ID and mission of users**
**Compliance levels**

**AOP**

**GOP**

**TAR**

**GEO**

**ENT**

**Data Emporium***

**GMI**

**MET**

**PER**

**FIN**

**Lat **
**Long**

**Lat **
**Long**

**Lat **
**Long**

**Lat **
**Long**

**Lat **
**Long**

**Lat **
**Long**

**?**

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

**********provides technical bases for ***_***both***_*** “to be” ***_***and***_*** transformations to handle legacy***

## Convergence Task ForceDelivery Address

## Common Domains

- High probability that developers (or SMEs) will...
- Re-invent the domain
- Re-invent the XML representation for the domain
- Need to use the same domain for multiple roles
- Not know the original source for the domain
- Thereby introduce deviations, increasing synchronization cost over time
- Re-invent transformations between “standards” for the domain
- Balk at some prescribed element names
- Reference Sets Experience – Developers will reuse if...
- Easy to find
- Easy to use
- Not overly constraining

## Reusable Data Components Reference Sets

**CREATE TABLE COUNTRY**
**  ****(CTRY_CD****	****  CHAR(2) NOT NULL,**
**  ****CTRY_NM****	****  VARCHAR(50) NOT NULL**
**  ****PRIMARY KEY (CY_CD));**
**CREATE UNIQUE INDEX XPKCOUNTRY**
**   ****ON COUNTRY**
**(  CTRY_CD****	****  ASC);**
**  **

**Ref Data Sets by Functional Area**

- Reusable Data Components *Reference Sets*

## Adoption of Common Data Types

- Data types are domains for data validation
- Range limits
- Enumeration
- Patterns
- Elements provide role/context for a data type
- Elements are reusable, Data types are reusable
- Common data types constrain variability, with less impact on programs than common element names
- Explicit Data types are represented in XML schemas as simpleType or complexType
- DOD XML Registry for Transform Specifications
- Function/Rule-based (e.g., English-to-Metric)
- Association/Cross Reference (e.g., FIPS-to-ISO)

- <xsd:element name=“Allegiance" type=“FIPS10-4CountryCodeType">

## Composable Interfaces

- COE:ExerciseCountryCodeType

- COE:COPCountryCodeType

- COE:Target

- Target.xml

- COE:FIPS10-4CountryCodeType

- GMI:MIDBAddlAllegianceCodeType

- GEO:GeospatialLocationType

- COE:UnitOfMeasureCodeType

- GMI:DatumType

- Legend
- 	Normative Schema
-  	Notional Schema
- 	Notional Instance

- Union of Domains

## Normative schemas for Some Common Data Types

- simpleType
- Unit of Measure
- Country Code
- FIPS 10-4 (2-character)
- ISO 3166 (2-character, 3-character, & 3-number)
- complexType
- Geospatial Location (Latitude, Longitude, Datum)

*Candidates for the Enterprise COI*

**Notes:**
Question of bundling?

## FIPS10-4CountryCodeType Domain Source: DOD Data Emporium RefSet

- FIPS10-4CountryCodeType *Domain Source: DOD Data Emporium RefSet*

- “lang” tag

- enumeration “meaning”

- documentation

- XML Elements: UpperCamelCase
- XML Attributes: lowerCamelCase
- Types: UpperCamelCase + Type

- Tie-back version to XML Registry

- Data Type, Data Size

**Notes:**
Use annotation/documentation for elements, attributes, types to provide documentation
Use annotation/appinfo <Meaning> to provide meaning for enumeration values
Use UpperCamelCase for elements, lowerCamelCase for attributes
Use UpperCamelCase for types and append “Type” to differentiate types from elements
To create tag for aggregations, append “List” to contained element name
Include xml:lang tag within schema and xml instance where needed.

## Registering Common XML Domains FIPS and ISO Country Codes

- Registering Common XML Domains *FIPS and ISO Country Codes*

- Both standards exist, neither can be ignored
- Challenge for interoperability
- Transforms needed

**IQ**

**IZ**

**US**

**US**

**GZ**

**FX**

**TP**

**UM**

**WE**

**Qty w/Same code**
**93**

**Qty w/Different code**
**143**

**Qty not in ISO**
**26**

**Qty not in FIPS**
**3**

**FIPS Qty: 262**

**ISO Qty: 239**

**Notes:**
GZ = Gaza Strip
WE = West Bank
IZ, IQ = IRAQ
FX = Metropolitan France, European part of FRANCE (FR); excluding GF, GP, MQ, NC, PF, PM, RE, TF, WF, YT
UM = UNITED STATES MINOR OUTLYING ISLANDS, Includes i.a. Baker Island, Howland Island, Jarvis Island, Johnston Atoll, Kingman Reef, Midway Islands, Palmyra Islands, and Wake Island
TP = East Timor, Includes the enclave of Oa-Cussi

## DISA Participation in NIST Registry Proof of Concept

- DISA Participation in NIST *Registry Proof of Concept*

- DISA Role
- Advertise and link to DoD XML Registry
- Assess ebXML Registry Services
- Develop interoperability modalities among registries

**DoD XML Registry**

**ebXML Wrapper**

**ebXML-compliant**
**Registry**

**ebXML-compliant**
**Registry**

## SHADE Next Steps

- SIPRNET copy of Registry
- Visibility for classified environment
- Registration Assistance
- Harvest Metadata from Operational Sources
- Convergence
- Identify Preferred Components
- Transform Components
- e.g., FIPS-to-ISO, Metric-to-English
- Registry API
- For Application-level Access to Metadata

## Emporium Development Planadds progressively more metadata* “galleries” from various resources

**Emporium v0**
**(Federated Metadata Stores)**

**Emporium v1**
**(Common Metadata Store)**

**Emporium vX**

**Emporium Baseline**
**(Ref Sets v1)**

**XML Reg**
**v1**

**Transformations**

**Ref Tabs**
**(Ref Sets v2) **

**Standard Data**
**(DDDS)**

**DB Segs v0**

**Messages**

**XML Reg**
**v2**

**DB Segs v1**

**XML Reg**
**v3**

**ISO 11179 **

**DDA (Models)**

**Symbology**

**Other**

**EDI (X-12)**

**EBXML**

**Ontologies**

- Emporium Development Planadds progressively more metadata* “galleries” from various resources

## Slide 22

## Phase 3 Requirements

- Generate schema from registered components
- Impact analysis for status change
- De-register mechanism
- Measure use/re-use
- Add user-defined types for registration
- Registry API
- Subscription
- Info Desk with FAQ capability
- Compare/contrast assistance for Convergence
- Registry Replication
- Registry Submission Assistance
- Indent Namespaces within COIs
- Constrain Search (exact vs substring)
- Convert reference sets to domain value documents

## DOD XML RegistryNext Steps

- DOD

****

## Convergence Task ForceRegistered “address” components

## Proposed COE Conventions

- Preference for W3C XML Schema Recommendation
- Use annotation/documentation for elements, attributes, types to provide documentation
- Use UpperCamelCase for elements, lowerCamelCase for attributes
- Use annotation/appinfo <Meaning> to provide meaning for enumeration values
- Use explicit Data Types rather than inline constraints
- Use UpperCamelCase for types and append “Type” to differentiate types from elements
- For aggregation tags, append “List” to element name
- Include xml:lang tag within schema and xml instance where needed.
- Limit the use of “generic” tags (e.g., no “item” tag)
- Express tie-back to XML Registry