Information about the XML Registry
For COE Developers
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.
For Other DOD Namespaces
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.
What is XML?
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
Registry Submission ProcessThe process for submitting XML Components and Information Resources to the XML Registry follows:
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 ConventionsFollow these conventions for establishing new information resources for the Registry:
You are visitor number 179 to this page.