Washington, DC June 19, 2002 Briefing to XML Working Group Business Case for the XML.gov Registry This document is confidential and is intended solely for the use and information of the client to whom it is addressed.
An XML registry should support human to registry interactions as well as system to registry interactions. Thus, a subjective human element exists in which a person must first establish and refine understanding of what definitions exist in the registry and how they can be used, before they are incorporated into an XML technology solution for system to system use.
Registries describing and pointing to business services (i.e., web services) offer higher value than registries that provide only XML definitions and classifications (i.e., XML schemas)
The notion of having a single, federal XML registry is not clear in the mind of the respondents, but sounds desirable given the substantial benefits of being able to collect and centralize descriptions and elements on a holistic level.
Interoperability between XML registries run by different agencies is imperative.
Certain levels of interoperability between organizations are difficult to attain even when a common element definition exists
Moving forward one registry does not necessarily seam feasible as opposed to multiple, distributed registries interoperating
The governance and operational model for the registry and its contents has not yet been addressed.
The strengths and limitations of using ebXML in an XML registry appear well known, while the strengths and limitations of using emerging specifications such as UDDI and WSDL appear very unclear.
Given so many systems already exist, newly agreed upon XML definitions that would exist in the XML registry may not be able to be efficiently imposed on other agencies. The question arises as to whether imposing standard element descriptions on different agencies is either possible or desirable.
ebXML possesses positive and negative aspects
Interoperability functionality in ebXML is still in its infancy, not extremely flexible, and lacks substantial industry product support
ebXML’s assumed security model incorporating digital signatures may be too strong for widespread deployment and usage
ebXML provides strong relationships between documents (associations of objects and packages of objects); more granular data elements require more robust relationships and associations as prescribed by ebXML
exXML provides strong capabilities in document lifecycle management and classification schemes that evolving specifications do not
Provide a mechanism to define classification schemes
Administrative capability where a registry “owner” or a “sub-classification owner” would add new categories and classification hierarchy to the registry
Provide a mechanism for navigating/searching a classification scheme
How schemas are organized in a registry for use by humans or systems
Provide a mechanism for adding items to a classification scheme as well as managing newly added items
Uploading XML schemas to the registry/repository for centralized distribution and consumption
Store metadata about data definitions such as XML schemas, DTDs, etc.
Store metadata about web services (i.e., references, address, descriptions)
Store actual XML data definitions (e.g., XML schemas, DTDs, etc.)
Store and describe actual data/reports described in XML (e.g., agencies could publish quarterly reports in XML and centrally distribute those reports as XML files on the registry)
Snapshot purpose of an XML registry/repository (cont…)
Support real-time XML validation of XML content against XML data definitions
For example, states would be have computer software automatically validate state water quality XML files against a centrally stored EPA water quality XML schema stored in the federal XML registry/repository
Support interoperability between different XML registries
The federal XML registry should be able to negotiate and exchange information with agency specific registries
The federal XML registry should be able to cross-search other registry indexes for relevant information
Software and application developers/integrators in federal agencies are the primary users
Snapshot value proposition of an XML registry/repository
Multiple agencies using common XML definitions and objects creates synergy
Increased awareness of what XML objects are available allows people to refine current implementations and apply higher-traction, more widely used XML definitions to future initiatives
Stronger descriptions and classifications of functional lines and definitions in the federal government improve overall government efficiency
Organizations can recognize more value from the registry if the XML registry provides business process classification schemes and the ability to navigate business domains based on required content
Functional overlaps can be identified in the federal government for improved efficiencies
Creation of policies and procedures allowing registries to interoperate enable distributed, collaborative registries that support agencies working together with more agility and flexibility rather than reinventing the wheel each time data is exchanged
Need to represent agile information and interoperability spanning non-traditional organization boundaries
Downstream usage of an XML schema or XML business service may not be known until it becomes available in a registry and promoted to many organizations
A registry allows the federal government to synthesize and consolidate government-wide XML initiatives:
Govt can also identify preexisting standards from industry consortia efforts, authorize, and recommend these as federally supported definitions