COE Data Engineering makes reusable common data components and related specifications available to you using XML, a universal data interchange format. The Registry constitutes guidance in the generation and use of XML within the COE v4.x data environment and is the authoritative source for registered XML data and metadata components.

To improve data interoperability, we strongly encourage all DOD communities to browse and use these XML data components, which are known to satisfy DOD system or database requirements.

eXtensible Markup Language is the new data interchange format approved by the World Wide Web Consortium (W3C). The W3C (http://www.w3.org/) is an independent organization that develops protocols for interoperability on the web. Platform and vendor independent, XML provides lightweight, flexible, self-describing text in the form of tags that may be used in concert with JAVA in any system, document, or database. XML format can handle data, data structures, and the description of data (metadata). The following is an example of the XML syntax:

   <Book Genre="Fiction" In_Stock="Yes">
      <Title>The Round Door</Title>
      <Author>Tom Evans</Author>
      <Year_Published>1996</Year_Published>
      <ISBN>0-9546-0274-3</ISBN>
      <Price>$23.00</Price>
      <Review>An Intriguing Tale Of A Round Door In A Wall</Review>
   </Book>

An XML tag can be described as any object and is easily created by anyone using a text editor. Although XML is a relatively new technology, many developers are already using XML in operational COE systems and have already created tags and specifications, many of which may be inconsistent with tags used in other systems. So far, the burgeoning sets of XML tags have created redundancy and irrelevancy, and they lack validity.

COE XML Registry

To ensure interoperability, this registry provides a baseline set of XML components developed through coordination and approval among the COE community. The Registry allows you to browse, search, and retrieve data that satisfy your requirements. The Registry has a substring search capability so that the user may easily find information resources that meet the criteria. The user may specify whether to search for the term within the name of the information resource, the definition, or both.

COE Developer's Role

You are urged to review the baseline components, adopt them where possible, and subscribe to future notifications about the components. If, after reviewing the tags in the Registry, you cannot reuse an existing specification (a.k.a. Document Type Definition [DTD]) or existing tags, you can submit your proposed tag to a Namespace manager and provide amplifying information for all to understand the semantics for its proper use.

COE Chief Engineer's Role

The COE Chief Engineer will approve a single Point of Contact (POC) for a Namespace to manage the XML components within that Namespace. The COE Chief Engineer will have the ultimate authority to mediate any unresolved disputes within all Namespaces.

The COE Data Engineering Team's Role

Tags and semantics will be analyzed to identify opportunities to consolidate tags towards a single or a minimal number of representations. A "market forces" model can also guide COE Data Engineering in identifying the weak candidates from the strong.

COE XML Venue

The Semi-Structured Data and Metadata (SSD-MD) sub-panel of the Data Access Technical Working Group addresses XML issues in bi-monthly meetings.

The Namespace Manager's Role

The Namespace Manager's responsibilities will include the transitioning of information resources from one status to another. Table 1 lists the valid types of information resources. The status levels are developmental, candidate, registered, rejected, deprecated, and retired.

Table 1 - Information Resource Types

1. Register yourself as a user of the XML Registry. Click here to go to the user registration screen.
2. Determine which Namespace your tags belong in. If you have questions, you should contact the Namespace Administrator for further guidance. Additional guidance can be found by contacting the COE Enterprise Namespace Manager.
3. Review the tags already in the XML Registry and determine if any of the existing tags meet your requirements.
4. Build a submission package. See "How to Create a Submission Package" for more information. The example submission package is an excellent starting point for creation of your package. Click here to download the example submission package.
5. Once your package is ready for submission, you should verify that your package is properly formatted and contains no errors. Use the online package verifier which will display any errors found. Your package will process correctly if no errors are reported. Click here to jump to the package verifier.
6. You should receive e-mail verification within 3 working days once your package has been processed correctly.

How to Create a Submission Package

In order to register your tags into the XML Registry you will need to create a submission package containing the documents, tags, schema, etc you want to register. The submission package is a ZIP file that must contain a file called Manifest.xml. Manifest.xml is an XML document conforming to the registry.dtd schema. Within the Manifest.xml file you define all the tags you want to register and the associations between those tags and existing tags within the XML Registry. Documents you want to register should also be placed in the ZIP file and references within Manifest.xml must be defined. An example submission package is available here.

A submission package validation capability is available to verify that the structure of your submission package is correct. This capability is available here and is also used to submit validated packages to the XML Registry for further processing. Additional information on the layout and content of the Manifest.xml file is provided below.

Rules and Conventions

1. Include descriptive definitions AND synonyms for the Information Resource Definition

   Initially, the Registry will not have keyword, thesaurus, or ontology support but it will have a substring search for a number of fields, including definition. Therefore, we urge submitters to include enough expressive terms so that COE developers can easily find the term they might consider "natural" in the definition, and find the desirable tag for expressing that concept. Example: If the registered tag is ORG_ID, the description that includes references to "military unit," "organization," and "UIC" would be appropriately returned from most search efforts.



2. Uppercase XML elements and attributes

   With Oracle 8i support for XML as an output form, we anticipate that table and column names will be used as tags for the XML output.