ACORD Naming and Design Rules (NDR)

An ACORD proposed Joint Architecture 'Naming and Design Rules' Working Group "has been initiated from the need of developing new ACORD XML components around a single XML architecture that would encompass all ACORD domains. The group will develop a set of XML architecture principles, which will be in line with approaches taken within the wider XML user community. Examples of issues to be addressed are XML naming conventions, standardized data types, code list representation, message assembly principles, use of XML schema features, use of namespaces, and XML extension method. Applicable Steering Committees inclide Life, Property & Casualty/Surety, and Reinsurance.

According to the Working Group proposal, the objective is to complete standardized XML Naming and Design Rules for future ACORD Standards:

This working group has been initiated from the need of the Joint Technical - ACORD Web Services Profile WG to define XML components that would be reused throughout ACORD's XML standards to support functionality in the messaging infrastructure domain. These crossdomain components initially covered areas like Attachment and document handling and Error reporting, but this requirement will grow over time. Added to this, ACORD's standards strategy envisions the creation of a single XML standard which each of the ACORD domains could adopt at some point in the future.

To support these requirements, there is a need to develop a set of XML architecture principles upon which new XML designs can be based, which will be in line with approaches being taken within the wider XML user community, and will remain stable for several years. Examples of issues to be addressed are XML naming conventions, standardized data types, code list representation, use of XML schema features, and use of namespaces.

From November 2006 there was a need to continue the working group to address:

• Generation of XML from 'Core Components'. UBL and UN/CEFACT have made significant progress in working together to come up with a single NDR approach that sets rules for generation of XML formats directly from 'Core Components', and it was felt this area needed to be considered by the group.
• Some issues within the original scope were not able to finally agreed by the November 2006 target

The target for April 2007 was to ensure all NDR components required to support the design of PCS v2 (AML) and AWSP v1 were defined, and then published by June 2007...

The Joint XML Naming and Design Rules specification will be required for XML constructs derived from the Standards Framework and for any new cross-domain ACORD XML components. It is also ACORD's goal that it be used as the target architecture when our current domain standards undergo major redesign...

For relevant parts of the specification, the group will review whether they can reuse rules created by UBL and CEFACT for generation of XML constructs from 'Core Components'. They will try to align the documentation structure to cross-industry NDR's for easing comparison and enhancing tool support of ACORD NDR...

An ACORD Messaging Library Working Group was formed "to manage the transformation of ACORD's domain specific XML standards content into a new combined standard (AML), incorporating ACORD's vision of a single business messaging standard. AML is to define business XML messages that support business functions relevant to all lines of business, varied geographies, B2B, B2C, and internal systems. Additionally, the message inventory will be developed on a common set of design rules... This direction will have an iterative approach that will allow each ACORD domain to transition its messaging content based on the domain specific plans. The unified business messaging direction will adhere to the target architecture currently being developed by the Naming and Design Rules (NDR) Working Group..."

ACORD XML: " ACORD (Association for Cooperative Operations Research and Development) "is a global, nonprofit insurance association whose mission is to facilitate the development and use of standards for the insurance, reinsurance and related financial services industries... ACORD XML (Extensible Markup Language) is the electronic language of the insurance Internet, facilitating real-time, cross-platform, peer-to-peer communication. ACORD XML for Life, Annuity & Health is based on the ACORD Life Data Model and provides a robust, industry-tested XML vocabulary... The ACORD XML for P&C/Surety standard addresses the industry's real-time requirements. It defines P&C/Surety transactions that include both request and response messages for Accounting, Claims, Personal Lines, Commercial Lines, Specialty Lines and Surety transactions. The strength of Extensible Markup Language (XML) is that it provides a generic way to process data on the Internet and an efficient way to transfer structured data between applications. In the Property & Casualty business, ACORD XML provides a foundation for real-time exchange of data between producers, insurers, rating bureaus, service providers and more..."

References:

• ACORD home page
• ACORD Standards Working Group Proposal. By Phil Brown and Serge Cayron (ACORD). [cache]
• Contact: Lloyd Chumbley (Assistant Vice President, ACORD Standards). Also jtndr@teams.acord.org, Serge Cayron [WWW], Phil Brown (Standards Project Manager and Technical Architect, WWW)
• See also: Data Dictionary for Global Insurance Industry. "This resource is the public release of a harmonized data dictionary for the insurance industry by ACORD, eEG7 and CSIO. This marks the completion of efforts by this international coalition of standards bodies to harmonize their existing data dictionaries as part of a United Nations initiative. This new data dictionary provides the technology neutral, reusable building blocks that serve as the basis for the development of messages for all lines of insurance business. The common data elements and their definitions have been identified and harmonized to one element name and definition for each concept such as 'coverage', 'risk object' or 'claim'. The associations submitted this harmonized data dictionary to UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business), providing them with already agreed upon international insurance industry data elements and definitions. UN/CEFACT is creating a methodology for achieving interoperable standards within and across business sectors including among others insurance, finance, transport, and healthcare... The data dictionary provides a high level, syntax neutral foundation on which standards organizations can build and map specific messages and XML schemas to meet their own unique market and geographic requirements while remaining compliant with the now agreed upon definitions."

Danish XML Project: OIOXML Naming and Design Rules

OIO: Danish "Offentlig Information Online" == Open Public Information Online.

The [OIOXML] Infostructurebase is a collaboration tool for the information society. The Infostructurebase is a part of the Danish e-Government Project and a strategic element in the architecture for e-Government. The main purpose and value is to support exchange and reuse of data related to public and private service delivery, including cooperation, business reengineering and alignment of related services... The ISB contains four main tools: infosite, forum, repository and UDDI. The Danish Ministry of Science, Technology and Innovation has established the Danish Infostructurebase...

The Danish XML project: Denmark has adopted XML as a key to the information architecture in support of E-Government. The philosophy of the Danish E-Government strategy is based on government wide co-operation and reuse — and support also cooperation with both the private sector and with a wider international community. The Danish XML project focuses on coordination and supports the development and standardization of XML interfaces and vocabularies. A national XML Committee is responsible for ensuring coherence and momentum in the standardization of XML-based interfaces and vocabularies. Together these element make up the socalled OIOXML paradigm. The Danish XML Committee foresees the development of XML standards in the Danish public sector..."

"The OIOXML NDR publication defines the latest OIOXML Naming and Design Rules (NDR 3.0) for creating OIOXML-compliant XML Schema files. The set of rules laid down by the OIOXML NDR 3.0 provides the foundation for the approval process for OIOXML schemas used in public government data provider solutions. The OIOXML NDR only allows one to use a subset of the XML Schema specification and also endorses certain schema patterns to avoid ambiguities and to maximize interoperability..."

Apart from an update of the rules in NDR 2.0, the current version has been enriched with a large number of examples in XML and XML Schema explaining the use of the rules, as well as a quick reference sheet and an index. Each rule has also been assigned a unique number for easier reference..."

OIOXML schema: "The designation OIOXML schema counts for the XML schemas, which has been approved by the Danish XML Committee (or a valid representative, e.g., a Domain Committee) and adheres to the relevant OIOXML NDR in force at the time of approval or if they have been adopted as international contributions. This means that an OIOXML schema does not need to observe the OIOXML NDR rules, if the schema is part of an international contribution. This is designated an adopted schema. In this way OIOXML serves as an umbrella for all schemas relevant to the Danish XML project, whether they are national or international..."

References:

• OIOXML Naming and Design Rules (OIOXML NDR). Notice posted 2005-04-13.
• OIOXML NDR Navngivnings- og Design Regler [OIOXML Naming and Design Rules]. Version 3.0. Date: 2004-12-15. Publikation: OIO 6 [3:2004]. 66 pages. [cache]
• See: "Naming and Design Rules for E-Government — The Danish Approach."
• "What is OIOXML?"
• Danish e-Government Project: Infostructurebase

EPA Exchange Network XML Design Rules and Conventions

The [EPA] Exchange Network is "a partnership between state environmental departments and the U.S. Environmental Protection Agency. The Exchange Network is a secure Internet- and standards-based approach for exchanging environmental data and improving environmental decisions. The U.S. Environmental Protection Agency, State environmental departments, and U.S. tribes and territories are partnering to build the Exchange Network to increase access to environmental data and make the exchange of data more efficient."

In December 2004, the EPA Schema Review Work Group under the Technical Resource Group (TRG) prepared a documentation package designed to help Partners initiate their "schema development effort based on the Exensible Markup Language (XML) Design Rules and Conventions (DRC), existing schema, documented elements from the Environmental Data Registry (EDR), Environmental Data Standards Council (EDSC) data standards, and modularity defined by the Core Reference Model (CRM). These are critical for schema designed to flow data within the EN, including facility to state, state to state, state to Environmental Protection Agency (EPA), and all combinations in between... The Exchange Network (EN) is a major EPA/State initiative to promote data exchange and information sharing across various environmental programs and among EN Partners (Partners). A major tool of the EN is the XML language and the development of XML schema to be used to exchange environmental data among Partners. A number of efforts are underway to ensure the success of the EN, including the Environmental Data Standards Development, the CRM [Core Reference Model], XML DRC [Design Rules and Conventions], this Schema Review Process, and the TRG Approval Process. These efforts are envisioned to aid schema developers by reducing redundancy and encouraging harmonization among schema..."

According to the EPA Exchange Network's Instructions for XML Schema development: Partners should develop XML schema in accordance with the following guidance documents to ensure interoperability and reuse among schema components: (1) XML Design Rules and Conventions: This document was developed by the Technical Resource Group (TRG) and provides the guidance for drafting XML Schema for the Exchange Network. Please download all three .pdf files: [a] XML Design Rules and Conventions for the Environmental Information Exchange Network: Prologue; [b] XML Design Rules and Conventions for the Environmental Information Exchange Network: Section 1. XML Design Rules; [c] XML Design Rules and Conventions for the Environmental Information Exchange Network: Section 2. Schema Design Rules... U.S. EPA offers an automated tool for testing XML schema compliance with the Exchange Network's Design Rules and Conventions..."

From the XML Design Rules and Conventions for the Environmental Information Exchange Network Prologue

The XML Design Rules and Conventions (DRCs) provides rules and guidelines for the creation and use of XML schema and schema components for use in the Exchange Network. Schema design has important implications for the reusability of schema and schema components in data exchanges. It provides an opportunity to promote the Exchange Network's goals of improved data quality and efficient data exchanges. In developing the DRCs, the Technical Resource Group strived to ensure the rules would promote the development of reusable, interoperable Network schema that would build efficiencies for Network schema developers and data managers exchanging data.

The design rules govern the use of features and options available through the World Wide Web (W3C) Schema Technical Specification. For example, the W3C Specification allows the use of both global and local data element declarations, while the DRCs restricts a Network data exchange schema to global data elements declared in the Network namespace. Unlike local elements, global data elements are interchangeable and reusable in other Network Schema and carry with them unique data definitions when reused. In contrast, locally declared elements lose their uniqueness and may lose their meaning when used elsewhere.

This is one prominent example of a design rule used to promote interoperability. Other rules govern the use of attributes, namespaces, versioning and the many other schema design features that affect their reusability in the Exchange Network. Over time, adherence to the DRCs and other Exchange Network guidelines will create a robust repository of reusable schema built on data standards that developers can reuse to build Network schemas for new data flows and data managers can use to exchange data across that Network..."

References:

• National Environmental Information Exchange Network website
• Exchange Network XML Schema Development. Includes description of the XML Design Rules and Conventions.
• XML Design Rules and Conventions:

  • XML Design Rules and Conventions for the Environmental Information Exchange Network: Prologue. Steve Vineski (EPA Co-Chair, Technical Resources Group). Version 1.0. September 23, 2003. 2 pages. See the extract. [source PDF]

  • XML Design Rules and Conventions for the Environmental Information Exchange Network: Section 1. XML Design Rules. Version 1.0. September 23, 2003. 26 pages. Chapter 1: XML Design Rules Introduction; Chapter 2: XML Schema File Naming Conventions; Chapter 3: XML Tag Naming Conventions. Comments on this guide should be sent to Steve Vineski (EPA Office of Information Collection). [source PDF]

  • XML Design Rules and Conventions for the Environmental Information Exchange Network: Section 2. Schema Design Rules. Version 1.0. September 23, 2003. 120 pages. Chapter 1: Schema Introduction; Chapter 2: Datatypes; Chapter 3: Elements and Attributes; Chapter 4: Namespaces; Chapter 5: Schema Configuration and Documentation; Chapter 6: Information Association and Uniqueness; Chapter 7: Advanced W3C Schema Concepts [ID/IDREF; KEY/KEYREF; XLink/XPointer]; Appendix A: Summary of XML Rules; Appendix B: Glossary. "This guide separates the application of XML into two types: data centric and document centric. Data-centric XML is used in data exchange environments; document-centric XML is used in a content management environment. Datacentric XML is geared toward machine processing; document-centric XML is geared toward formatting and human consumption. An example of data-centric XML is information passed between an order management system and an inventory management system. An example of document-centric XML is information formatted for inclusion in a book, brochure, or website..."[source PDF]

• Schema Review Process for Schema Developers. December 23, 2004. 11 pages. By: Tom Aten (WI), Brand Neimann (US EPA), Bruce Bargmeyer (US EPA), Dennis Burling (NE), Jeff Kohn (US EPA), Larry Fitzwater (US EPA), Louis Sweeney (Ross & Assoc), Mike Beaulac (MI), Molly O'Neill (ECOS/NSB), Sarah Calvillo (Ross & Assoc), Steve Vineski (US EPA), Terry Forest (US EPA), Tim Crawford (US EPA). References the XML Schema Architecture Report. "This document describes the package of materials, the resources available, and the steps a schema reviewer needs to take to review a schema prior to submitting it to the Technical Resource Group (TRG) for recommended use by Exchange Network participants. The document proposes that each Network schema be evaluated for compliance with the XML Design Rules and Conventions, with the modularity aspects of the Core Reference Model, and with the data element standards established for Network use." [source PDF]

• Exchange Network Shared Schema Components: Technical Reference. Developed by the EPA Phase II Core Reference Model (CRM) Workgroup; this Workgroup is comprised of participants from EPA and States, along with contractor support. Last Call Working Draft. Revision Date: September 29, 2004. 101 pages. Members: Tom Aten (Wisconsin DNR), Michael Beaulac (Project Manager, Michigan DEQ), Mary Blakeslee (Environmental Council of States - ECOS), Dennis Burling (Nebraska DEQ), Tim Crawford (US EPA - DSB), Gail Jackson (Pennsylvania DEP), Tom Lamberson (Nebraska DEQ), Dennis Murphy (Delaware DNR), ), Sandy Smith (Missouri DNR), Linda Spencer (US EPA - DSB). [The document] "provides a technical representation of the Shared Schema Components (SSC). For each SSC, the elements that are referenced and their details (namespace, type, attributes, facet restrictions, and annotations) are provided." [cache]

• Exchange Network Shared Schema Components: Usage Guide. Developed by the EPA Phase II Core Reference Model (CRM) Workgroup; this Workgroup is comprised of participants from EPA and States, along with contractor support. Last Call Working Draft. Revision Date: September 29, 2004. 54 pages. [The document] "illustrates the benefits of using sharable schema components based on approved EDSC data standards as an alternative to XML schema developed without such standards... provides detailed guidance to XML schema developers on how to incorporate the SSC into data flow XML schema. A companion document to this Usage Guide is the Exchange Network Shared Schema Components: Technical Reference, which provides detailed information for each of the Shared Schema Components." [cache]

• Core Reference Model for Environmental Information Exchange Network. Revision Date: March 31, 2003. Draft Version 1.0. 256 pages. Prepared for the EPA Technical Resource Group (TRG). Contract Number: NE-TRG-01. The Core Reference Model (CRM) Workgroup is comprised of participants from four States, ECOS, the US EPA, and independent contractors. Sates, ECOS, US EPA Members: Michael Beaulac (Project Leader, Michigan DIT), Mary Blakeslee (ECOS), Dennis Burling (Nebraska DEQ), Tim Crawford (US EPA / DSB), Pat Garvey (US EPA / OIC), Sarah Hisel-McCoy (US EPA / OEI), David Kempson (Arizona DEQ), Tom Lamberson (Nebraska DEQ), Dennis Murphy (Delaware DNR). "The EPA Core Reference Model (CRM) is an inventory to organize and identify commonalities in the data States and EPA currently and anticipate exchanging. The Exchange Network's intent to use shared XML schema fostered the CRM development effort that provides Network Partners some new tools to improve exchangeable information by harmonizing its common components... The draft CRM described in this document was created to provide the Environmental Data Standards Council (EDSC), Technical Resources Group (TRG), and Exchange Network Partners (Partners) with guidelines for consistently building and sharing data on the Exchange Network. The CRM is a high-level depiction of major groupings of environmental data and their relationships. The CRM provides the EDSC opportunities to identify new data standards or to revise existing data standards. The CRM also provides guidance for the development of consistent and reusable Data Exchange Templates (DET) for sharing data on the Exchange Network. In addition, the CRM provides basic building blocks for those designing, revising, or expanding environmental information exchanges."

• XML Schema Architecture Report. Prepared for Environmental Council of States (ECOS/NSB) by Service Applications International Corporation (SAIC). July 08, 2004. 29 pages. Service Agreement: NE-TRG-02. This paper documents architectures for several XML schema designs and may be helpful guidance for schema developers. Discusses Russian Doll, Salami Slice, Venetian Blind, and Garden of Eden. Compare Roger Costello, Global versus Local. [cache]

• RCRAInfo Data Exchange XML Schemas. Example (Resource Conservation and Recovery Act Info) XML schemas, "developed to support exchanging hazardous waste between trading partners. The XML schemas are structured in a Modular format consistent with groupings of data found in EPA's RCRA Info System." See the file listing for the ZIP distribution, with Schema to RCRA Data Exchange Template, RCRA to Schema Data Exchange Template, and Model Trading Partner Agreement. [cache]

• Environmental Data Standards Council (EDSC)
• XML File Naming Conventions for the Environmental Information Exchange Network. LMI Report EP211L4. Christopher T. Kupczyk and Jessica L. Glace. June 2003. Provides "a detailed discussion and rationale in developing EPA's file naming conventions."
• XML Schema Namespace and Versioning Strategy for the Environmental Information Exchange Network. Mark Crawford and Jessica Glace (Logistics Management Institute). LMI Report EP211L1. December 2002.
• XML Enumeration and Code Lists for the Environmental Information Exchange Network. Mark Crawford, Jessica Glace, and Alison Kittle (Logistics Management Institute). LMI Report EP211L2. December 2002.

Federal XML Naming and Design Rules Project

Warning: As of December 2005, it appears that all the links (below) to https://fed-xml-ndr.core.gov/ have been broken by the authority of the owners of Core.gov. If notification is sent to the editor indicating a policy change at Core.gov, I will attempt to restore some or all of the broken links below; otherwise, this note may stand as witness to a weak commitment to data integrity and longevity, on which, see: (1) "we found we had to move the files..." is "one of the lamest excuses" (according to Tim Berners-Lee), (2) behavior as evidence of clumsy management or inadequate commitment to information persistence..."

XML Schema Interoperability: Web site description 2007-09: "This is the XML Schema Interoperability community, previously called 'Federal XML Naming and Design Rules and Guidelines'. In contrast to the approach that ended in early March 2006, our current focus is to create an environment and repository for the authoring, sharing, and testing of XML Schema rules for optional use by any agency or COI. Read about the NIST Quality of Design (QOD) tool for validating schemas against rules which is the basis for our continuing work. Note that the Federal CIO Council Data Architecture Subcommittee has its own CORE.gov community for the XML Schema Interoperability Working Group approved by the DAS in July 2006.

CORE.GOV (Component Organization and Registration Environment) is FEA's Center for Components — a government source for business process and technical components. One of the projects hosted at CORE.GOV is the Federal XML Naming and Design Rules Project, directed by Mark Crawford and Tim Mathews.

According to the August 17, 2005 presentation by Mark Crawford to the XML.gov XML Community of Practice, the draft Federal XML Naming and Design Rules and Guidelines [perhaps to be titled: Federal XML Naming and Design Rules and Guidance] is designed to "provide a set of rules and guidelines that will enable development of: (1) a flexible federal modularity model that defines the structure for creating interoperable schema and schema modules; (2) a clearly defined namespace scheme that ensures consistency across Agencies; (3) a versioning scheme that will support consistency in versioning of government schema; (4) a Federal canonical schema for base Data Types; (5) specific NDR's by government agencies or communities of practice that build on this document; (6) a reference to use for a mapping of different agency NDR's to each other; (7) consistent, reusable XML components that may be made available for reuse such as: Schema; Schema Modules such as reusable code lists and identifier lists; Simple and Complex Types; Elements; Attributes; (8) a set of tools to facilitate ease of development, validation, and interoperability."

The June 2005 draft document assigns rules into the following categories: Attribute Declaration; Attribute Naming; Code List; ComplexType Definition; Data Element Dictionary Entry Names and Definitions; Documentation; Element Declaration; Element Naming; General Naming; General Type Definition; General XML Schema; Instance Document; Modeling Constraints; Naming Constraints; Namespace; Root Element Declaration; Schema Structure Modularity; SimpleType Definition; Standards Requirements; Versioning.

The document scope: "This Federal XML Naming and Design Rules and Guidelines document is intended for use by all Executive Branch Departments and Agencies (hereinafter referred to as Agency) that employ XML, including all commercial and government off-the-shelf XML related product implementations. It should be used by all contractors and vendors doing XML development work on behalf of Departments and Agencies. Agencies developing specific XML Naming and Design Rules and Guidelines should use this document as the baseline for those efforts."

The proposed audience [not vetted as of 2005-08-17] includes: "Developers of Federal Enterprise Schema; Government organizations looking for guidance; Agency level developers interested in fostering interoperability; Private sector organizations who wish to track government efforts."

The technology builds upon work from voluntary consensus standards bodies (OASIS Universal Business Language Technical Committee; UN/CEFACT) and other government NDRs (e.g., Department of the Navy, Environmental Protection Agency, Global Justice). "Modularity is the key to reuse: the modularity model must be: Structured, Flexible, and Consistent."

Note from Owen Ambur of August 12, 2005: "I myself have begun to use the acronym NDRG to denote the fact the draft will contain both rules and guidelines. Also, based upon progress at yesterday's meeting, I am hoping to be able to deliver a consensus draft to the AIC Governance Subcommittee on October 20 [2005]..." (responding to Ken Sall: "[there] was a productive NDR+G meeting yesterday at Interior... For those not on the line yesterday, the new name of the document is expected to be 'Federal XML Naming and Design Rules and Guidance', which is why I used the NDR+G acronym..."

References:

• Federal XML Naming and Design Rules. Draft Version 2. June 09, 2005. 105 pages. From the Federal XML Naming and Design Rules Project. Major Document Sections: Introduction, Information Analysis, General XML Constructs, Naming XML Constructs, Declarations and Definitions, Extending and Restricting Types, Code Lists and Identifier Lists, Using Schematron, Miscellaneous XSD Rules, XML Instances. With appendices: Appendix A: Federal XML Naming and Design Rules Checklist; Appendix B: Approved Acronyms and Abbreviations; Appendix C: Metadata Components; Appendix D: Approved Representation Terms; Appendix E: Technical Terminology. "The document is primarily intended for developers already familiar with XML. This document focuses on XML Schemas as a tool for interoperability. We encourage developers to try the techniques recommended here and provide feedback via the Federal CIO Council XML Working Group listserver."
• NDR Draft with line numbers, source .DOC
• FED-XML-NDR Project home page Broken! Try: https://collab.core.gov/CommunityBrowser.aspx?id=2234.
• Project documents
• Federal XML NDR Brief; see the biblio ref.
• fed-xml-ndr Project mailing lists
• Archives for the general-purpose mailing list of FED-XML-NDR. Post to listserv@fed-xml-ndr.core.gov.
• FED-XML-NDR Project document list
• Contacts: Mark Crawford, Tim Mathews (project owners - initially)

Global Justice XML Data Model (GJXDM) Naming and Design Rules

The Global XML Structure Task Force (GXSTF) [also XSTF] was formed under The Global Justice Information Sharing Initiative to "identify data requirements, explore XML concepts, and apply XML best practices to the design and implement of the Global Justice XML Data Model (Global JXDM). It is composed of government, academic, and industry domain experts (law enforcement, courts, probation & parole, and corrections), technical managers, and engineers." The Global XML Structure Task Force (GXSTF) works closely with researchers at the Georgia Tech Research Institute (GTRI).

XSTF is developing a Global Justice XML Data Model Naming and Design Rules document which specifies the data model, XML artifacts, and XML data for use with the Global Justice XML Data Model. In its early draft form, the NDR document "specifies an information sharing framework based on the Global Justice XML Data Model (GJXDM) and World Wide Web Consortium (W3C) Extensible Markup Language (XML) Schema. Sponsored by the Office of Justice Programs (OJP), U.S. Department of Justice (DoJ), the GJXDM is the result of a combined government and industry effort under the Global Information Sharing Initiative (Global). The mission of Global is to improve the administration of justice and protect the nation's public by promoting practices and technologies for the secure sharing of justice information..."

The XSTF's NDR is a work in progress which is still being vetted by Global XSTF, and has not yet undergone the debate process. Two internal draft for XSTF review and comment have been produced, generating some 170 comments. According to the tentative development schedule, a draft for external review will be completed by August 23, 2005, and a target GJXDM NDR release v3.1 is projected for October 31, 2005. The development team anticipates NDR rule modifications/refinements, as well as new rules, in response to changes to the GJXDM. Work remaining includes [2005-08] new content (definitions and rules), explanations, examples, revision of relationships, and additional conformance profiles. An outstanding topic is how to use (non-conforming) external schemas.

Draft Version 0.4 of the "Global Justice XML Data Model Naming and Design Rules was released 23-August-2005, and "specifies the data model, XML artifacts, and XML data for use with the Global Justice XML Data Model. The document is an early draft of a specification for GJXDM-conformant XML components. This document is incomplete, and will undergo considerable revision before being approved for use. This document will be updated by GTRI in concert with the Global XML Structure Task Force (XSTF)." Particularly,

[it] "specifies an information sharing framework based on the Global Justice XML Data Model (GJXDM) and World Wide Web Consortium (W3C) eXtensible Markup Language (XML) Schema. Sponsored by the Office of Justice Programs (OJP), U.S. Department of Justice (DoJ), the GJXDM is the result of a combined government and industry effort under the Global Information Sharing Initiative (Global). The mission of Global is to improve the administration of justice and protect the nation's public by promoting practices and technologies for the secure sharing of justice information.

In 2002, Global commissioned the Global XML Structure Task Force (GXSTF) to collect justice and public safety information requirements from various state and local government sources. Over 16,000 data requirements were identified and analyzed. These were reduced to approximately 2,200 unique data properties that were incorporated into about 500 data objects. These reusable GJXDM data components are then rendered in W3C XML Schema. The schemas are available to justice practitioners and developers on the OJP Information Technology Website.

W3C XML Schema was designed to enable information interoperability and sharing by providing a common language for describing data precisely. As its name implies, W3C XML Schema was also designed to be extensible. The constructs it defines are basic building blocks — baseline data types and structural components. Users apply these building blocks to describe more complex data types and structures — in effect, a new application with a domain-oriented syntax and vocabulary. This is what the GJXDM renders in XML Schema for the justice community. A reasonable set of rules and constraints on the employment of the building blocks and the GJXDM domain components will enhance information sharing by facilitating better interoperability. Therefore, this document specifies enforceable constraints for GJXDM schemas. It is a product of the GXSTF, the steering committee that continues to guide, manage, and approve changes to the GJXDM..."

Summary (adaptation) from an August 17, 2005 public presentation and an earlier draft version of the specification:

Key inputs to the GJXDM NDR have come from the GJXDM, the OASIS LegalXML IJ TC GJXDM draft MNDR, the Federal XML NDR Working Group draft [NDRG], and the OASIS UBL NDR specification. Its design has been incluenced by the NIEM Steering Committee, the Federal Enterprise Architecture, the IJIS Institute, the OASIS LegalXML Integrated Justice TC, the National Center for State Courts, and the Federal XML NDR Working Group.

In terms of Scope, the GJXDM NDR constitute a specification for GJXDM Version 3.1. It is focused on providing: (1) a definition of GJXDM-conformant schemas; (1) a definition of GJXDM-conformant reference schemas, on which schemas that are simply conformant are based; (3) a definition of subsetting methodology, through which conformant schemas are built from conformant reference schemas; (4) naming of content to ensure understandability and reuse; (5) documentation of content to ensure comprehension; definition of GJXDM-conformant instances, which contain additional validation requirements, such as types associated with references and relationships.

The GJXDM NDR is a technical specification for GJXDM 3.1, specifying how GJXDM is actually defined. In format, it's as close as possible to theUBL NDR document, where appropriate, and it uses (copies) appropriate wording from other NDR documents. On the other hand, the GJXDM NDR is not a projection of UBL on GJXDM, nor a a comparison of UBL and GJXDM, nor yet a methodology for building Information Exchange Package Documentation (IEPDs). It is not an MNDR (Methodology, Naming, and Design Rules) document.

The draft NDR articulates both principles and rules, along with normative definitions or terms. Some twenty-two (22) principles guide creation of rules. The principles represent the requirements, concepts, and goals that have helped shape the GJXDM. Principles (e.g., design criteria) are informative, but act as the basis on which the rules are defined. Principles thus provide a foundation, as "all rules spring from the principles." Only the rules are binding (enforceable), and they state how they bind the users. Most rules apply to conformant schemas, while others apply to instances or reference schemas.

The draft document organizes rules under 'Rule Categories' similar to those used by the UBL NDR and related NDRs. These include: Attribute Definition Rules; Attribute Naming Rules; Constraint Schema Rules; Complex Type Definition Rules; Documentation Rules; General Naming Rules: Broadly-applicable rules for naming entities; General XML Schema Rules; Instance Document Rules; Subset Schema Rules; Standards: The GJXDM's relation to standards, standards compliance, and interpretation of standards; Simple Type Definition Rules; Structures: The GJXDM's use of specific structural conventions to represent non-hierarchical data and object order. A 'VER' (Versioning) rule category is still in discussion within XSTF.

Slide #15 of Paul Embley's August 17, 2005 public presentation documents a Survey of NDRs in terms of principles, rules, and definitions. The GJXDM draft NDR to date provides 22 Principles, 110 Rules, and 5 Definitions. The OASIS IJTC GJXDM draft MNDR has 100 Rules and 37 Definitions; the Federal XML draft NDRG to date has 10 Principles and 159 Rules. [See also the Federal NDR Comparison document.]

References:

• "Global Justice XML Data Model Naming and Design Rules." Draft Version 0.4. 23-August-2005. Edited by Webb Roberts (Georgia Institute of Technology). This document specifies the data model, XML artifacts, and XML data for use with the Global Justice XML Data Model. [source PDF]
• "Global Justice XML Data Model Naming and Design Rules." By Paul Embley (Global XML Structure Task Force). Presented an update on the Global Justice XML Data Model (GJXDM) Naming and Design Rules at the August 17, 2005 meeting of the XML Community of Practice (xmlCoP). 16 slides. Also in PDF format. Covers the current status of the GJXDM NDR, its inputs and influences, what the specification is and is not, projected development schedule, document overview, summary of principles, summary of rules, and comparison to other NDRs. See the excerpted text above. Source from XML.gov: HTML, .PPT.
• Global Justice XML Data Model (Global JXDM)
• GJXDM XML Structure Task Force
• Georgia Tech Research Institute (GTRI)
• Global Justice XML Data Model: Reference Architecture. By Dr. Mark Kindl (Georgia Tech Research Institute). May 2004.
• GJXDM Information Exchange Package Documentation Guidelines. March 2, 2005. Version 1.1. Principal author: Mike Hulme (Architecture Director, Justice and Public Safety, Unisys Corporation Member, XML Structure Task Force - XSTF). Published by the GJXDM XML Structure Task Force. 8 pages. This document, published by the GJXDM XML Structure Task Force, presents guidelines for the content of Information Exchange Package Documentation. It will be referenced in the upcoming OASIS MNDR Deliverable. [source .DOC]
• GJXDM Technical Specification: Naming and Design Rules (NDR). From the GTRI Team [Georgia Tech Research Institute (GTRI)]. June 2005. Posted by Paul Embley June 28, 2005 to the OASIS Exchange Document Methodology, Naming, and Design Rules (MNDR) Subcommittee mailing list; see followup by Scott Came. "NDR to be published with [GJXDM] Release 3.1. Vetting by XSTF, IJIS, NIEM SC, OASIS, fed-xml-ndr Working Group. Inputs: OASIS LegalXML IJ TC; OASIS UBL NDR; UN/CEFACT CCTS NDR; fed-xml-ndr workgroup draft NDR; others as necessary. What Spec Will Do or Be: [1] A product of the Global XSTF; [2] Technical specification; [3] Specify how GJXDM is actually defined; [4] Format as close as possible to UBL NDR document, where appropriate; [5] Use/copy/borrow appropriate wording from UBL NDR document, or from other inputs; [6] Specify rules and rationale for rules. What Spec Will NOT Do or Be: [1] not a projection of UBL/CCTS on GJXDM; [2] not a comparison of UBL and GJXDM; [3] not a methodology for building IEPDs, i.e., NOT an 'MNDR'. (Projected) Schedule: 15-July-2005 Draft 1 XSTF review/comment; 31-July-Draft 2 XSTF review/comment, corresponds to 3.1alpha1; 15-August-2005 Draft 1 for external review — IJIS, NIEM SC, OASIS, Fed XML NDR WG, etc.; 31-August-2005 GJXDM NDR v1.0. [source .PPT, cache]
• Contacts:
  • Paul Embley (XSTF Chair)
  • Christopher Traver (Department of Justice, Bureau of Justice Assistance).
  • Webb Roberts (GTRI)

Hong Kong OGCIO Interoperability Framework for E-Government

The Office of the Government Chief Information Officer (Government of the Hong Kong Special Administrative Region) has published an XML Schema Design and Management Guide through the Interoperability Framework (IF). This IF, "including the technical specifications, is managed by the Interoperability Framework Co-ordination Group (IFCG). An XML Co-ordination Group (XMLCG) has also been formed to develop strategies to facilitate more effective adoption of XML. In addition, specialist groups in some government Bureaux and Departments [B/Ds] are taking the lead in specifying interoperability standards for their respective business areas. The IFCG liaises closely with these specialist groups..."

To facilitate the implementation of joined-up E-government services, OGCIO has promulgated interoperability standards, including international standards, as well as Chinese language interface standards formulated by the Government. IF is one of the [IT Infrastructure and Standards, Infrastructure for E-government] e-government initiatives designed to provide client-centric joined-up government services to the public [and] to provide one-stop comprehensive services by enabling the seamless flow of information, within legal bounds, across individual B/Ds as necessary. The Hong Kong Interoperability Framework is producing a collection of technical and data specifications that help B/Ds define the interface between interacting applications. Extensible Markup Language (XML) is a key component of the Interoperability Framework. Data specifications for interface between systems are defined in XML..."

The XML Schema Design and Management Guide "aims to facilitate the process of designing and defining quality, consistent and reusable XML Schema Definitions (XSDs) in a systematic manner. Capturing international best practices and standards available, the Guide serves as an instruction manual for business analysts and developers to participate in the schema design process. It is intended for Bureaux and Departments (B/Ds) and their contractors to design XML Schema that defines the interface for data exchange between two or more B/Ds or between B/Ds and businesses in joined-up services..."

Part II of the Guide "XML Schema Design Guide" includes a Section 5 on "XML Schema Definition Development." Section 5 provides the mechanism that programmers should follow to convert information models, which are prepared by business analysts, into XSDs. XML naming rules are also discussed. In addition, this section provides guidelines on namespace assignment, versioning, and meta-data documentation of schema documents." Excerpts:

Name an Element: The name of the xs:element that represents the aggregation of a BBIE or ASBIE in an ABIE shall be translated from the Property Term of the BBIE/ASBIE by applying the upper camel case convention. For example, the xs:element name for the 'Delivery Date' Property Term is DeliveryDate.

Name an Attribute: The name of the xs:attribute that represents a Supplementary Component shall be translated from the Supplementary Component name by applying the lower camel case convention: all words shall be concatenated with the first letter in every word in upper case, except the first word, and the other letters in lower case. For example, the xs:attribute name for the 'Currency Code' Supplementary Component is currencyCode.

Name a Complex Type: Ignoring the impact caused by different versions of a BIE, the name of the xs:complexType that represents a BBIE or ABIE shall be translated from the Dictionary Entry Name following this procedure: (1) Remove all dot and space characters from the Dictionary Entry Name; (2) Apply the upper camel case convention: all words shall be concatenated with the first letter in every word in upper case and the other letters in lower case; (3) Append .CT at the end to indicate it is an xs:complexType. For example, the xs:complexType name for the Dictionary Entry Name 'Postal Address. Street. Text' is PostalAddressStreetText.CT...

References:

• E-Government Interoperability Framework
• Office of the Government Chief Information Officer (OGCIO)
• XML Schema Design and Management Guide:
  • Part I: Overview [cache]
  • Part II: XML Schema Design Guide. Reference: G55-2. Version 1.2. November 2004. 73 pages. [cache]
  • Part III: XML Schema Management Guide [cache]
  • Part IV: Appendices [cache]
• Contact: IFCG Standing Office

IRS XML Naming and Design Rules

The US Department of the Treasury, Internal Revenue Service has a long history of SGML/XML adoption, now prominently featured in the IRS.gov web site.

"As of January 2003, the IRS has already adopted XML as a de facto, recommended syntax specification in more than twenty different applications. Although each application had its own XML standards, there was also regular, informal coordination among IRS XML stakeholders and with the tax industry. On January 22, 2003, the IRS Enterprise Data Management Organization (EDMO) was assigned the role of serving as the single IRS enterprise XML Point of Contact (POC). It is the on-going policy of EDMO to work collaboratively on the establishment of policy and standards with those organizations and projects experienced in or affected by the proposed work. The IRS XML Community of Practice (xmlCoP) was established to facilitate communication and collaboration on XML policy, standards and practices within the IRS...

IRS XML Naming and Design Rules (NDR) Development Process: The IRS XML xmlCoP convened a working a group to define Naming and Design Rules for the use of XML in the IRS. These rules were based on the International standard, Universal Business Language (UBL), as supported by the Federal CIO's Council and International technical committees (OASIS, OECD, and ISO). The NDR will be periodically reviewed and updated, if necessary, in order to keep current with UBL updates and any other relevant industry standards.

IRS XML Naming and Design Rules (NDR) Purpose: The EDMO is responsible for the IRS XML naming and design rules as well as for the standardized XML components and products resulting from their use... Effective XML management requires a balance between diversity and conformity recognizing that diversity can impose increased transformation costs and performance penalties. The principal objective of all the XML naming and design rules is to facilitate consistency and interoperability across the IRS and with its data exchange partners...

Rules in the IRS NDR have a Rule Prefix Token corresponding to the rule category: ATD: Attribute Declaration; CDL: Code List; COM: ComplexType; CVR: Component Versioning; DOC: Artifact Documentation; ELD: Element Declaration; FRM: Forms; GNR: General Naming; GXS: General Construct; IMP: Schema Import; IND: Instance Document; NMP: Namespace Prefix; NMS: Namespace; SCF: Schema File; SCH: Schema Organization; SIM: SimpleType; SSM: Schema Modularity; STA: Standards Adherence; VER: Schema Versioning.

A table in 'Appendix A' of the draft IRS NDR contains a mapping of the IRS XML NDR rules to the UBL XML NDR rules; it can be used as a reference for determining the origination of an IRS XML NDR rule.

Industry XML Standards: The IRS XML Naming and Design Rules (NDR) will remain closely tied to the following industry standards: (1) The World Wide Web Consortium (W3C) family of XML standards; (2) ebXML (Electronic Business using eXtensible Markup Language); (3) UBL (Universal Business Language). UBL is an implementation of ebXML. ebXML, originally an Oasis standard, is now an ISO standard (ISO15000-5) and focuses on the design of reuseable components..."

Comments on the IRS NDR are welcome and can be sent to Sol Safran or John Triplett.

References:

• "IRS XML Standards and Guidelines." Edited by Sol Safran (IRS, Enterprise Data Management). Draft document. From Volume 4, IRS Enterprise Data Standards and Guidelines (Special Tools and Techniques). Posted June 27, 2005 to the CORE.gov web site. 33 pages. "This document is a major revision to the IRS XML Standards and Guidelines found in Volume 4 of the EDSG, distributed for review. It will be incorporated within the official copy of the EDSG once approved. The cover page, and page headers and footers are solely for presentation purposes."
• XMLNDR DRAFT Federal XML DG Comments/Changes and Template Posting from Sol Safran, Mon, 27 Jun 2005: "Attached is draft XML NDR being circulated within the IRS. Our timeframe to formally complete these is early August. You may post them to our working group listserv. This set of NDR is another step in an ongoing process for maturing the IRS XML standards..."
• Draft IRS NDR from Core.gov web site
• Contact: Sol Safran or John Triplett (IRS XML Lead).
• IRS and SGML/XML:
  • IRS: About XML or SGML Formatted Files
  • IRS (US Internal Revenue Service) and SGML
  • US Internal Revenue Service and SGML/XML for Tax Filing

OAGIS Naming and Design Rules (NDR)

"The Open Applications Group, Inc. (OAGi) is a not-for-profit open standards group building process-based XML standards for both B2B and A2A integration. OAGi was formed in late 1994 as the first post-EDI organization focusing on improving the state of application integration...

OAGIS XML is a royalty-free XML business language broad enough and rich enough to create a Canonical Model for application integration for organizations. This Canonical Model provides the common business language that organizations can use to solve the 'N Squared' integration problem...

OAGIS 9.0 is a major release that includes full support for the UN/CEFACT/ISO Core Components Technical Specification, CCTS 2.01, harmonized Core Components from UN/CEFACT TBG17, a great deal of new content, and technical improvements to better support Web Services and to make OAGIS easier to use. OAGIS 9.0 provides 434 Business Object Documents and 77 Nouns (including 15 new Nouns); new BODs support Customer Relationship Management, Logistics, and Sarbanes-Oxley, among others. It includes the approved harmonized Core Components [CCTS 2.01] from UN/CEFACT TBG 17, with enhancements to provide better Web Services support."

'Naming Updates in OAGIS 9.0': "OAGIS 9 incorporates today's best practices for XML and continues to take full advantage of XML Schema. It uses primarily global elements, incorporating UN/CEFACT ATG 2 Naming and Design Rules (ISO 11179; long tag names; use of UpperCamelCase for Elements and Types; use of lowerCamelCase for attributes; makes use of XML Schemas Typing to define types for everything to inherit common pieces of the component and Noun definitions, minimizing the number of definitions and the amount of code needed to process the standard; all Types end with the word 'Type'. [from the August 2005 Introduction, Slide #19]

While the OAGIS 9.0 NDR document is not finalized, some of its design may be observed in the naming of components in the OAGIS 9.0 distribution. See for example (directories for /BODS/ and /Nouns/ ) XML schemas in filenames like "ProcessEngineeringChangeOrder.xsd" and "ProcessEngineeringWorkDocument.xsd" which are based upon the corresponding types "ProcessEngineeringChangeOrderType" and "ProcessEngineeringWorkDocumentType" with XML elements "ProcessEngineeringChangeOrder" and "ProcessEngineeringWorkDocument."

According to a 2005-01 memo from Garret Minakawa, OAGi is now a full voting member of ATG2 and is also an Editor of the ATG2 NDR. [The editors have] provided many comments into the Draft 1.0 NDR and worked with ATG2 to better align Draft 1.1 NDR with OAGIS 9.0; the soon to be released OAGIS 9.0 NDR will reference the ATG2 NDR extensively and every effort has been made to adopt ATG2 rules..." The OAGIS 9 Naming and Design Rules draft was reviewed by the OAGi Architecture Team at the OAGi Summer 2005 Technical Meeting, August 9-10, 2005.

References:

• The Open Applications Group web site
• "OAGIS 9.0 Introduction." Presented by Michael Rowell (Chief Architect, Open Applications Group, Inc.. August 9, 2005. See the meeting agenda. [cache]
• OAGi Development Methodology Review
• "OAGIS 9.0: Where do we go from here?" By Michael Rowell. March 03, 2005. Presentation context: see the meeting agenda. Slide #27 on OAGIS Components and BODs. OAGIS Core Components build upon the UN/CEFACT CCTS and the OAGIS NDR (OAGIS 9.0), which makes extensions to the UN/CEFACT ATG2 NDR.
• OAGi Core Components Work Group
• [UBL and] Open Applications Group Core Components Work Group
• Introduction to the Open Applications Group (OAGi)
• Download OAGIS v .90
• Contact: Michael Rowell (OAGi)

OASIS LegalXML Exchange Document Methodology, Naming, and Design Rules (MNDR) Subcommittee

The Exchange Document Methodology, Naming, and Design Rules (MNDR) Subcommittee is a workgroup of the OASIS LegalXML Integrated Justice Technical Committee. The MNDR Subcommittee was chartered in January 2005 to "develop and document (1) A methodology for the construction of GJXDM-conformant exchange documents; (2) Naming and design rules for the artifacts called for by the methodology; (3) Guidelines for the customization of GJXDM schema structures; (4) Context drivers for integrated justice... In chartering this subcommittee, the Integrated Justice Technical Committee explicitly recognizes that this work is patterned after the successful development of similar methodology, naming, and design rules in the OASIS UBL Technical Committee."

In April 2006, members of the OASIS SC published Integrated Justice Exchange Document Methodology, Naming, and Design Rules (MNDR). An earlier draft (Working Draft .08, 13-May-2005) was made available for GJXDM Information Exchange Package Methodology, Naming and Design Rules (MNDR). Section VI — Schema Set Naming and Design Rules. Section VII — Instance Naming and Design Rules.

Summary from GJXDM User Conference, Atlanta, Georgia, June, 2005: "The Organization for the Advancement of Structured Information Standards (OASIS) LegalXML Integrated Justice Technical Committee has been working to document a methodology for the creation of Global JXDM-conformant information exchange package documents (IEPD), Naming and Design Rules (NDR) as required by that methodology, and guidance for the customization of Global JXDM schema structures for integrated justice. The OASIS LegalXML Integrated Justice Technical Committee is developing a Methodology NDR document for defining interoperable standards for developing Global Information Exchange Packages (GIEP). This presentation was geared towards implementers and provided an overview of the draft Methodology NDR, proposed standards for development artifacts, extension schema documentation, and schema naming rules." See the bibliographic reference.

[May 16, 2005] The purpose of the MNDR deliverable is: (1) to "improve interoperability by promoting consistent use of GJXDM in constructing schemas; (2) to lower risk and improve efficiency of projects to establish exchanges between justice partners, by disseminating best practices; (3) to reduce the effort involved in identifying exchange document development best practices, by consolidating them in, or at least referencing them from, one single place; (4) where possible, to provide a formal, normative standard that exchange partners can use to establish criteria for quality assurance — for example, in contracts with system integration vendors... In addition, the MNDR recognizes that Information Exchange Package (IEP) development projects will often seek to reuse IEPs developed in other contexts. For instance, Reference IEPs may serve as the basis for the development of IEPs in particular jurisdictions. Consequently, the MNDR deliverable seeks to improve the reuse potential of all IEP design artifacts (e.g., visual models, mapping artifacts) by proposing a standard IEP development methodology, with standardized artifacts, and by suggesting the use of only non-proprietary, open-standard, vendor-independent tools and artifacts in IEPs...

"The TC is aware of other successful Naming and Design Rules (NDR) development efforts. The UBL and Department of Navy NDRs are two examples. The MNDR deliverable under development differs from the UBL and Navy NDRs as follows: (1) This TC's MNDR effort takes as a given the existence of GJXDM, and does not contain any rules applicable to the GJXDM vocabulary itself. Rather, it contains only rules for conformant schemas built with the GJXDM vocabulary. (2) This TC's MNDR effort goes further than the UBL and Navy NDRs in defining a standardized IEP development process with standardized artifacts, including domain models and explicit mapping of domain model entities to GJXDM structures. At the same time, the TC has consciously incorporated UBL and Navy NDRs into the TC's MNDR deliverable where applicable, and has remained consistent with the other NDRs whenever possible..." [May 16, 2005 from SC Chair Scott Came]

References:

• Integrated Justice Exchange Document Methodology, Naming, and Design Rules (MNDR). Working Draft. April 20, 2006. Produced by members of the OASIS LegalXML Integrated Justice Exchange Document Methodology, Naming, and Design Rules Subcommittee. Document identifier: 'wd-ijtc-MNDR-1.0.0.doc'. Technical Committee: OASIS LegalXML Integrated Justice TC. Chairs: Ellen Perry (MTG Management Consultants) and John Ruegg (LA County Information Systems Advisory Body - ISAB) Editors: John Ruegg (LA County Information Systems Advisory Body (ISAB), Marcus Leon (LA County Information Systems Advisory Body (ISAB), and Marguerite Soto (LA County Internal Services Department). Contributors: Scott Came (Justice Integration Solutions, Inc), Tom Carlson (National Center for State Courts), Ellen Perry (MTG Management Consultants, L.L.C.), John Ruegg (LA County Information Systems Advisory Body - ISAB), and Nancy Rutter (Maricopa County, Arizona). [source .doc, cache]

  Document Abstract: The purpose of this document is to establish guidance on how to develop GJXDM Information Exchange Package Documentation. Schema language provides many redundant features that allow a developer to represent a logical data model many different ways. Heterogeneous data models can become an interoperability problem in the absence of a comprehensive set of naming, definition, and declaration design rules. This [document] establishes rules for XML schema elements, attributes, and type creation. Because the W3C XML specifications are flexible, comprehensive rules are needed to achieve a balance between establishing uniform schema design while still providing developers flexibility across the Justice and Public Safety domain. Adherence to these rules will ensure that semantics are unambiguous, enabling the practitioner teams to conduct straightforward comparisons and make recommendations with respect to enterprise reusability across their respective organizations. GJXDM information exchange schema(s) and XML Instances rules are modeled after the same naming and design conventions used to develop the Global Justice XML Data Model (GJXDM)..."

• [OASIS LegalXML Integrated Justice] Exchange Document Methodology, Naming, and Design Rules Subcommittee
• MNDR SC Charter [source .DOC]
• MNDR SC List archives
• "GJXDM MNDR Purpose". Draft descriptopn of the purpose of the GJXDM Exchange Document Methodology, Naming and Design Rules (MNDR) deliverable in progress on the OASIS Integrated Justice Technical Committee. By Scott Came (Justice Integrated Solutions, Inc). May 16, 2005.
• GJXDM Information Exchange Package Methodology, Naming and Design Rules (MNDR). Section VI — Schema Set Naming and Design Rules. Section VII — Instance Naming and Design Rules. Version 10 snapshot of MNDR Section 6 and 7. Posted by Ellen Perry. Date Submitted: Tuesday, 28-June-2005. Status: "This document contains all subcommittee and TC revisions made through 6/28/2005." [source .DOC]
• "GJXDM Information Exchange Package Methodology Naming & Design Rules (MNDR)." Presented by John Ruegg (County of Los Angeles, Information Systems Advisory Body). GJXDM User Conference, Atlanta, Georgia, June, 2005. See the summary. [source .PPT; cache]
• "Leveraging UBL for Developing Justice XML (GJXDM) Reference Documents." By John Ruegg (County of Los Angeles, Information Systems Advisory Body). Copy of presentation submitted for April 2005 OASIS Symposium. April 04, 2005. 29 slides. "OASIS Integrated Justice is evaluating UBL NDR as a model for developing a GJXDM Information Exchange Package NDR Additionally, the GJXDM NDR will specify standards for Domain Model artifacts and Detail Domain Modeling mapping artifacts to make these artifacts interoperable." [source .PPT]April Symposium 2005 UBL & GJXDM NDR Name* April Symposium 2005 UBL & GJXDM NDR (539K) Description. Copy of presentation submitted for April 2005 Oasis Symposium on "Leveraging UBL for developing Justice XML (GJXDM) Reference Documents Group, LegalXML Integrated Justice Exchange Document Methodology, Naming, and Design Rules SC FolderMNDR Section Documents Submitter. Mr. John Ruegg Date Submitted Monday, 04 April 2005 02:22pm Document StateDraft (A preliminary unapproved sketch, outline, or version.) AccessThis document is visible to the members of LegalXML Integrated Justice Exchange Document Methodology, Naming, and Design Rules SC only-->
• "Implementation of Global Justice XML Data Model 3.0.2 through the Use of Universal Business Language Methodology and Core Component Constructs." OASIS LegalXML Integrated Justice Technical Committee. Proposed White Paper. January 24, 2005. [source .DOC]
• OASIS LegalXML Integrated Justice Technical Committee. Parent TC for the MNDR SC, chartered to facilitate the exchange of data among justice system branches and agencies for criminal and civil cases.
• Contact: (1) Scott Came (SC Chair; Justice Integrated Solutions, Inc); (2) John Ruegg (LA County Information Systems Advisory Body - ISAB) and Ellen Perry (Manager, MTG Management Consultants, L.L.C.), Integrated Justice TC Chairs.

Universal Business Language (UBL) Naming and Design Rules

The Universal Business Language (UBL) specification is being developed through an international effort to define a royalty-free library of standard electronic XML business documents such as purchase orders and invoices.

The UBL Library has been designed "as an implementation of ebXML Core Components Technical Specification 2.01, based on a conceptual model of information components known as Business Information Entities (BIEs). These core components are assembled into specific document models such as Order and Invoice. These document assembly models are then transformed in accordance with UBL Naming and Design Rules into W3C XSD schema syntax. This approach facilitates the creation of UBL-based document types beyond those specified in this 1.0 release. UBL schemas thus are modular, reusable, and extensible in XML-aware ways." OASIS announced the approval of the Universal Business Language (UBL) Version 1.0 as an OASIS Standard in November 2004; the specification is available online.

In December 2004 the OASIS membership also voted to approve the Universal Business Language (UBL) Naming and Design Rules specification as an OASIS Standard. This specification "conveys a normative set of XML schema design rules and naming conventions for the creation of business based XML schema for business documents being exchanged between two parties using XML constructs defined in accordance with the ebXML Core Components Technical Specification." It is one of three closely aligned specifications governing XML naming and design rules, along with (1) the UN/CEFACT XML Naming and Design Rules, produced by the Working Group 2 of the UN/CEFACT Applied Technology Group (ATG) and (2) the U.S. Department of the Navy XML Naming and Design Rules Final Version 2.0, published by the Office of the DON Chief Information Officer as part of the DoD Net-Centric Data Strategy.

Universal Business Language v2.0. OASIS Standard. 12-December-2006. Contains: Appendix F. UBL 2.0 Naming and Design Rules (Informative). "The UBL 2.0 release package contains UBL Naming and Design Rules specifying the generation of UBL schemas from the UBL data models. NDRs are given in the checklist at doc/ndr/NDR-checklist.pdf [source]. The entire NDR document (including explanatory prose) will be released following publication of UBL 2.0... See UBL NDR 2.0 Checklist. Edited by Michael Grimley and Mavis Cournane. "The following checklist contains all UBL XML naming and design rules as defined in UBL Naming and Design Rules Version 2.0, 30-August-2006. The checklist is in alphabetical sequence as follows: Attribute Declaration Rules (ATD); Code List Rules (CDL); ComplexType Definition Rules (CTD); ComplexType Naming Rules (CTN); Documentation Rules (DOC); Element Declaration Rules (ELD); Element Naming Rules (ELN); General Naming Rules (GNR); General Type Definition Rules (GTD); General XML Schema Rules (GXS); Modeling Constraints Rules (MDC); Naming Constraints Rules (NMC); Namespace Rules (NMS); Root Element Declaration Rules (RED); Schema Structure Modularity Rules (SSM); Versioning Rules (VER). Other NDR "2.0" formats: PDF version of DocBook NDR draft (uploaded to Kavi 15-March-2007); see also the posting of 11-April-2007 for UBL-NDR-Docbook-2007-04-11.zip.

Universal Business Language (UBL) Naming and Design Rules 2.0. Public Review Draft, 8-September-2006. Edited by Mavis Cournane (Cognitran Limited) and Mike Grimley (US Navy). Available in Word .doc format, PDF format, and HTML format.

As of 2005-08, work continued within the OASIS Universal Business Language (UBL) Technical Committee to produce an updated NDR for UBL Version 2.0. The specification is being further aligned with the UN/CEFACT NDR, for example. Finalization of the naming and design rules for UBL 2.0 is [2005-08] gaining momentum with the appointment of Michael Grimley of the US Department of the Navy to the UBL NDR editorial team. Grimley has played a pivotal role in the development of both UBL and DON NDR, and his appointment to UBL NDR editorship will help ensure their continued alignment. Key changes under consideration for UBL 2.0 NDR are the adoption of the UN/CEFACT Core Component Type schema module and the UN/CEFACT Unqualified Datatype schema module. Additionally, for version 2.0 the UBL NDR requires that all attributes must be globally declared, including ID and Code.

The UBL NDR specification "documents the naming and design rules and guidelines for the construction of XML components for the UBL vocabulary..." The UBL NDR specification "has several primary and secondary targets that together constitute its intended audience. Our primary target audience is the members of the UBL Technical Committee. Specifically, the UBL Technical Committee will use the rules in this document to create normative form schema for business transactions. Developers implementing ebXML Core Components may find the rules contained herein sufficiently useful to merit adoption as, or infusion into, their own approaches to ebXML Core Component based XML schema development. All other XML Schema developers may find the rules contained herein sufficiently useful to merit consideration for adoption as, or infusion into, their own approaches to XML schema development...

UBL NDR rules are categorized/labeled according to type: ATD: Attribute Declaration; ATN: Attribute Naming; CDL: Code List; CTD: ComplexType Definition; DOC: Documentation; ELD: Element Declaration; ELN: Element Naming; GNR: General Naming; GTD: General Type Definition; GXS: General XML Schema; IND: Instance Document; MDC: Modeling Constraints; NMC: Naming Constraints; NMS: Namespace; RED: Root Element Declaration; SSM: Schema Structure Modularity; STD: SimpleType Definition; VER: Versioning.

Overview of the OASIS UBL NDR [Version 1.0] Specification

The OASIS Universal Business Language (UBL) Technical Committee was chartered to address problems caused by competing XML business-to-business document standards through the creation of a universal XML business language. UBL "builds on the work of the electronic business XML (ebXML) initiative. The ebXML effort is an initiative to develop a technical framework that enables XML and other payloads to be utilized in a consistent manner for the exchange of all electronic business data."

The UBL Technical Committee established a UBL Naming and Design Rules Subcommittee with the charter to "recommend to the TC rules and guidelines for normative-form schema design, instance design, and markup naming, and write and maintain documentation of these rules and guidelines". The Universal Business Language (UBL) Naming and Design Rules specification produced by the UBL TC "documents the rules and guidelines for the naming and design of XML components for the UBL library. The UBL library consists of ebXML CCTS Business Information Entities (BIEs). UBL XML schemas are defined through the application of UBL Naming and Design Rules (NDRs) to an underlying data model mapped to the Core Component types. The UBL NDR specification conveys a normative set of XML schema design rules and naming conventions for the creation of business based XML schema for business documents being exchanged between two parties using XML constructs defined in accordance with the ebXML Core Components Technical Specification."

Chapter 2 of the NDR describes the relationship of UBL to ebXML Core Components. "The Core Components concept defines a new paradigm in the design and implementation of reusable syntactically neutral information building blocks. The essence of the Core Components specification is captured in context neutral and context specific building blocks. The context neutral components are defined as Core Components (ccts:CoreComponents). The context specific components are defined as Business Information Entities (ccts:BusinessInformationEntities), where a BIE is 'a piece of business data or a group of pieces of business data with a unique Business Semantic definition'.

The UBL library "defines how each of the ccts:BusinessInformationEntity components map to an XSD construct. In defining this mapping, UBL has analyzed the CCTS metamodel and determined the optimal usage of XSD to express the various ccts:BusinessInformationEntity components... UBL continues to work with UN/CEFACT and the Open Applications Group to develop a single normative schema for representing ccts:CoreComponentTypes..."

Chapter 3 'General XML Constructs' defines UBL rules related to general XML constructs to include: Overall Schema Structure; Naming and Modeling Constraints; Reusability Scheme; Namespace Scheme; Versioning Scheme; Modularity Strategy; Schema Documentation Requirements.

Chapter 4 of the UBL NDR presents 'Naming Rules'. The UBL component library, as a syntax-neutral representation, is fully conformant to the rules of CCTS and ISO 11179. "The UBL syntax-specific XSD instantiation of the UBL component library in some cases refines the CCTS naming rules to leverage the capabilities of XML and XSD. Specifically, truncation rules are applied to allow for reuse of element names 1288 across parent element environments and to maintain brevity and clarity."

Chapter 5 covers 'Declarations and Definitions' in connection with the use of W3C XML Schema, where "elements are defined in terms of complex or simple types and attributes are defined in terms of simple types. The rules in Chapter 5 govern the consistent structuring of these type constructs and the manner for unambiguously and thoroughly documenting them in the UBL Library. Since UBL elements and types are intended to be reusable, all types must be named. This permits other types to establish elements that reference these types, and also supports the use of extensions for the purposes of versioning and customization..."

Chapter 6 treats 'Code Lists'. "UBL has determined that the best approach for code lists is to handle them as schema modules. In recognition of the fact that most code lists are maintained by external agencies, UBL has determined that if code list owners all used the same normative form schema module, all users of those code lists could avoid a significant level of code list maintenance....To make this mechanism operational, UBL has defined a number of rules..."

Chapter 7 contains 'Miscellaneous XSD Rules' which are are aimed at supporting consistency in the further development of UBL as a business standard vocabulary: "to ensure consistency, it is necessary to address the optional features in XSD that are not addressed elsewhere."

Chapter 8 on 'Instance Documents' formulates several rules to ensure consistency in UBL instance documents, judged essential in a trade environment. The rules address: use of a global element, defined as the root element in the schema as its root element; validation against XML schemas; identification of character encoding with the XML declaration; schema instance namespace declaration; non-use of empty elements...

References:

• PDF version of DocBook NDR 2.0 draft. 15-March-2007. See the improved version of 11-April-2007 in the package UBL-NDR-Docbook-2007-04-11.zip, with PDF.
• Universal Business Language (UBL) Naming and Design Rules. Edited by Mavis Cournane (Cognitran Limited), Mark Crawford (LMI), and Mike Grimley (US Navy). With contributions by Bill Burcham (Sterling Commerce), Fabrice Desri (France Telecom), Matt Gertner (Schemantix), Jessica Glace (LMI), Arofan Gregory (Aeon LLC), Michael Grimley (US Navy), Eduardo Gutentag (Sun Microsystems), Sue Probert (CommerceOne), Gunther Stuhec (SAP), Paul Thorpe (OSS Nokalva), Jim Wilson (CIDX). Document identifier: 'cd-UBL-NDR-1.0.1', characterized as "NDR Draft Document for UBL 2.0". Published 2005-08-11. See recent change log files.
• Universal Business Language (UBL) Naming and Design Rules. Publication Date: 15-November-2004. 104 pages. Approved by vote of the OASIS membership as an OASIS Standard. Document identifier: 'cd-UBL-NDR-1.0.1'. Lead Editor: Mark Crawford (LMI). Produced by members of the OASIS UBL Technical Committee. UBL Naming and Design Rules Subcommittee Co-chairs: Mavis Cournane (Cognitran Ltd), Mark Crawford (LMI), and Lisa Seaburg (Aeon LLC). Past Chair: Eve Maler (Sun Microsystems). Contributors: Bill Burcham (Sterling Commerce), Fabrice Desri (France Telecom), Matt Gertner (Schemantix), Jessica Glace (LMI), Arofan Gregory (Aeon LLC), Michael Grimley (US Navy), Eduardo Gutentag (Sun Microsystems), Sue Probert (CommerceOne), Gunther Stuhec (SAP), Paul Thorpe (OSS Nokalva), Jim Wilson (CIDX).
• "XML Naming and Design Rules Specifications Published by OASIS, UN/CEFACT, and Navy CIO."
• Universal Business Language (UBL) Naming and Design Rules. Second Committee Draft Candidate. See the note above on the revised Committee Draft, "...UBL Naming and Design Rules have been approved by the UBL TC and are now in the process of submission for OASIS Standardization..."
• OASIS UBL Technical Committee
• UBL FAQ document
• Contact: Jon Bosak (Sun Microsystems) and Mark Crawford (LMI), UBL TC Co-Chairs.
• "Universal Business Library (UBL) and Core Components"
• "ebXML Core Components". References.
• ebXML Technical Architecture specification v1.04

UN/CEFACT XML Naming and Design Rules Technical Specification

In March 2006, The UN/CEFACT Forum announced the publication of version 2.0 of the XML Naming and Design Rules technical specification. "The specification allows users to identify, capture and maximize the re-use of business information expressed as XML schema components. It ensures consistent and efficient use of XML in a business-to-business and application-to-application environment. It can be utilized wherever business information is being shared or exchanged among and between enterprises and government agencies worldwide using XML schema." See: XML Naming and Design Rules Version 2.0. 17-February-2006. 121 pages. Project Team Leader: Mark Crawford (SAP Labs US). Lead Editor: Paula Heilig (Worldspan). Editors: Gunther Stuhec (SAP AG), Margaret Pemberton (Diskray), and Garret Minakawa (Oracle/OAGI). source PDF. "This UN/CEFACT — XML Naming and Design Rules Technical Specification describes and specifies the rules and guidelines that will be applied by UN/CEFACT when developing XML schema. This technical specification provides a way to identify, capture and maximize the re-use of business information expressed as XML schema components to support and enhance information interoperability across multiple business situations. Corrigendum, Submitted by the UN/CEFACT Forum Management Group for UN/CEFACT Technical Specification "XML Naming and Design Rules Version 2.0". Reference: Corr: ECE/TRADE/CEFACT/2006/13/Corr.1. 19-April-2006. 2 pages. Sources: The reference page (United Nations Centre for Trade Facilitation and Electronic Business, XML Naming and Design Rules). [Corrigendum source PDF]

Together with the OASIS UBL NDR specification, this document is one of the foundational NDRs developed in accordance with the UN/CEFACT Core Components Technical Specification (CCTS). Mark Crawford (Project Team Leader) serves on several of the NDR working groups, and has worked to harmonize them as far as possible.

Scope and Focus: The specification can be employed wherever business information is being shared or exchanged amongst and between enterprises, governmental agencies, and/or other organizations in an open and worldwide environment using XML schema for defining the content of the information exchange.

This NDR technical specification forms the basis for standards development work of technical experts developing XML schema based on information models developed in accordance with the UN/CEFACT Core Components Technical Specification — Part 8 of the ebXML Framework (CCTS). The CCTS specification has subsequently been published as ISO/TS 15000-5 ebCCTS ebXML Electronic Business Extensible Mark-up Language, Part 5: ebCCTS ebXML Core Components Technical Specification, Version 2.01 (2003-11-15)...

Audience: The primary audience for this UN/CEFACT — XML Naming and Design Rules Technical Specification are members of the UN/CEFACT Applied Technologies Group who are responsible for development and maintenance of UN/CEFACT XML schema. The intended audience also includes the wider membership of the other UN/CEFACT Groups who will participate in the process of creating and maintaining UN/CEFACT XML schema...

"The UN/CEFACT - XML Naming and Design Rules were developed in close coordination with other XML standards efforts. In particular, the OASIS Universal Business Language Technical Committee Naming and Design Rules were instrumental in developing this document. Additionally, contributions were also received from: SWIFT; U.S. Department of the Navy; U.S. Environmental Protection Agency; U.S. Federal CIO Council XML Working Group; OpenTravel Alliance; Australia Electricity & Gas Industry; CIDX; EAN/UCC; European Transmission System Operators; PIDX."

Overview of the UN/CEFACT ATG2 NDR [Version 2.0] Specification

Following a Section 4 Introduction, Section 5 "General XML Construct" defines rules related to general XML constructs, including Overall Schema Structure; Relationship to CCTS; Naming and Modelling Constraints; Reusability Scheme; Modularity Strategy; Namespace Scheme; Versioning Scheme.

The XML Constructs: "UN/CEFACT XML design rules will be closely coupled with CCTS. UN/CEFACT XSD Schema will be developed from fully conformant Business Information Entities that are based on fully conformant Core Components."

Naming and Modelling Constraints: "UN/CEFACT XSD Schema are derived from CCTS and UN/CEFACT Modelling Methodology (UMM) process modelling and data analysis. The UN/CEFACT library contains fully conformant CCTS dictionary entry names as well as truncated XML element names developed in conformance with the naming constraint rules specified below. The XML fully qualified XPath ties the information to its standardized semantics as described in the underlying CCTS construct and CCTS Dictionary Entry Name, while the XML element or attribute name is a truncation that reflects the hierarchy inherent in the XML construct. There are differences in the rules for naming of elements, attributes, and types..."

"UN/CEFACT deliberated adopting a type based approach (named types), a type and element based approach, or an element based approach. A type based approach for XML management provides the closest alignment with the process modelling methodology described in UMM. Type information is beginning to be accessible when processing XML instance documents. Post schema-validation infoset (PSVI) capabilities are beginning to emerge that support this approach, such as data-binding software that compiles schema into ready-to-use object classes and is capable of manipulating XML data based on their types. The most significant drawback to a type based approach is the risk of developing an inconsistent element vocabulary where elements are declared locally and allowed to be reused without regard to semantic clarity and consistency across types. UN/CEFACT manages this risk by carefully controlling the creation of BBIEs and ASBIEs with fully defined semantic clarity that are only usable within the ABIE in which they appear. This is accomplished through the relationship between BBIEs, ASBIEs and their parent ABIE and the strict controls put in place for harmonization and approval of the semantic constructs prior to their XSD instantiation..."

Section 6 'General XML Schema Language Conventions' addresses Constraints on Schema Construction; Attribute and Element Declarations; Type Definitions; Use of XSD Extension and Restriction; Annotation). Section 7 'XML Schema Modules' describes the requirements of the various XML schema modules that will be incorporated within the UN/CEFACT library.

Section 8 'XML Instance Documents' expresses various rules relating to instances (character coding, empty elements, xsi:type). "In order to be UN/CEFACT conformant, an instance document must be valid against the relevant UN/CEFACT compliant XML schema. The XML instance documents should be readable and understandable by both humans and applications, and should enable reasonably intuitive interactions. It should represent all truncated tag names. An XPath navigation path should describe the complete semantic understanding by concatenating the nested elements. This navigation path should also reflect the meaning of each dictionary entry name of a BBIE or ASBIE..."

References:

• XML Naming and Design Rules Version 2.0. 17-February-2006. 121 pages. Project Team Leader: Mark Crawford (SAP Labs US). Lead Editor: Paula Heilig (Worldspan). Editors: Gunther Stuhec (SAP AG), Margaret Pemberton (Diskray), and Garret Minakawa (Oracle/OAGI). [source PDF]
• XML Naming and Design Rules. Draft Version 1.2. 8-September-2005. 123 pages. File Reference: 'NamingAndDesignRules_1.2_8sep.doc'. Posted to the UBL TC List 2005-09-12 by Sylvia Webb. [cache .doc, source ZIP file]
• XML Naming and Design Rules. Draft 1.1a. 16-February-2005. 111 pages. Project Team Leader: Mark Crawford (LMI). Editors: Gunther Stuhec (SAP AG), Paula Heilig (Worldspan), Margaret Pemberton (Diskray), and Garret Minakawa (Oracle/OAGI). "This UN/CEFACT Technical Specification has been developed in accordance with the UN/CEFACT/TRADE/22 Open Development Process (ODP) for Technical Specifications. It has been approved by the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) Applied Techniques Group (ATG) for implementation verification in accordance with Step 6 of the ODP." Also available from Core.gov.
• UN/CEFACT XML Naming and Design Rules. Draft 1.1. 14-January-2005. 141 pages. Document identifier: 'NamingAndDesignRules_1.1.doc'. Project Team Leader: Mark Crawford (LMI). Editors: Gunther Stuhec (SAP AG), Paula Heilig (Worldspan), Margaret Pemberton (Diskray), Garret Minakawa (Oracle/OAGI). Contributors: Hisanao Sugamata (ECOM-Japan), Frank Lin (GCOM), K.K. Suen (EAN Hong Kong), Luc Mouchot (CNAM-TS), Thomas Bikeev (EAN.UCC), Jostein Frxmyr (EDISYS), Sue Probert (SEPIA eb), Alain Dechamps (CEN), Michael Dill (GEFEG).
• UN/CEFACT Applied Technology Group (ATG)
• ATG 2 XML Assembly Documents/Productions Rules WG. Chartered to focus on XML syntax-related work to include development, maintenance and technical assessment of: Schema Design Rules; Schema Production; XML expressions of ebXML Core Components; XML expressions of ebXML Context Methodology; UML to XML Methodologies.
• "Electronic Business Extensible Markup Language (ebXML) — Part 5: ebXML Core Components Technical Specification, Version 2.01 (ebCCTS)". Proof version: 118 pages. Reference number ISO/TS 15000-5:2005(E). Summer 2005. Note: The ISO version ISO/TS 15000 Part 5 standardizes "Core Components Technical Specification — Part 8 of the ebXML Framework 15 November 2003 Version 2.01." [source .ZIP, cache]
• Contact: Mark R. Crawford (Chair, UN/CEFACT Applied Technologies Group)

US Department of the Navy XML Naming and Design Rules

According to an announcement from the UBL Technical Committee, the U.S. Department of the Navy "has mandated XML naming and design rules based on the work of the OASIS UBL Technical Committee. Liaison in this effort was provided by Michael Grimley, member of the DON XML Working Group and the UBL TC, assisted by Mark Crawford of LMI Government Consulting. In addition to the Department of the Navy, the UBL NDRs are already serving as the basis for design rules issued by the Chemical Industry Data Exchange association (CIDX) and UN/CEFACT, the UN body responsible for electronic trade facilitation."

In January 2005 the US Department of the Navy CIO "signed out the latest version [Version 2.0] of the DON XML Naming and Design Rules. These rules... provide for implementation of ISO 11179 concepts and ISO 15000-5 ebXML Core Components in XSD Schema." The U.S. Department of the Navy XML Naming and Design Rules Final Version 2.0 was published by the Office of the DON Chief Information Officer as part of the DoD Net-Centric Data Strategy.

"The DON XML Naming and Design Rules, Version 2.0, updates and supersedes the DON XML Developers Guide, Version 1.1. XML NDR provides the DON XML developer with a clear and comprehensive set of development rules and guidance that will standardize XML across the DON and promote global interoperability."

Summary:

"NDR Version 2.0 complies with joint requirements as embodied in DoD's net-centric data strategy, helps FORCEnet architects and system developers to achieve their requirement for a common structure and language for information handling, and enables the discovery and use of common data across the naval enterprise. XML, an open standards-based technology, is a key enabler of the Department's net-centric data strategy and this XML NDR provides the DON XML developer with a clear and comprehensive set of development rules and guidance that will standardize XML across the DON and promote global interoperability..." [product description]

"The DON NDR specifies the CCTS as the basis for DON XML information analysis. Developers should read the CCTS for a more thorough understanding of the methodology and CCTS terminology (ABIE, BBIE, BIE, etc.)... Core components provide a syntax neutral representation of data elements that will enable global interoperability across the DON by standardizing the way developers name data elements. The CCTS provides detailed rules for documenting data elements by creating units that are semantically unambiguous and interoperable. CCTS core components are interoperable units of data and will ultimately become the XML data elements that are exchanged among DON organizations...

The other key international XML standard relevant to the development of the DON NDR is the Universal Business Language (UBL) specification, developed by the Organization for the Advancement of Structured Information Systems (OASIS). OASIS developed the UBL NDR based on the CCTS; the UBL NDR describes how to implement CCTS in XML schema. The OASIS UBL rules provide a foundation for the DON NDR. In addition, by using the OASIS UBL rules, the DON can leverage the significant work that the OASIS Technical Committee (TC) has contributed to develop an XML standard for global interoperability..."

"... The NDR provides additional rigor necessary to efficiently and effectively operate in a net-centric data-sharing environment. These rules move the DON forward to ensure that all XML is based on a consistent set of schema through the application of open standards that align with the Federal Enterprise Architecture Data Reference Model and Global Information Grid. The result will be an environment that is sustainable, responsive, and agile.

The NDR is the product of expertise and energies contributed by representatives from 13 key Navy, Marine Corps, and Secretary of the Navy organizations who participated in the DON XML Working Group. To ensure these rules are applicable and current, the DON Chief Information Officer (DON CIO) has established the XML Business Standards Council and is proceeding to charter the Net-Centric Technical Standards Council to serve as liaison to organizations developing national and international standards for XML and Web Services technologies.

All commands in the Navy and Marine Corps that are developing systems that use XML, in accordance with our DON XML Policy, should apply these standards in order to maximize interoperability and enable a net-centric environment for enhancing supportability of operations across the Department..."

References:

• Department of the Navy XML Naming and Design Rules. Final Version 2.0. Office of the DON, Chief Information Officer. January 2005. 168 pages. Appendices include: Appendix A. Rules Tables; Appendix B. Bibliography; Appendix C. Glossary/Acronyms; Appendix D. Schema Examples; Appendix E. Approved XML Specifications. Version note: "The initial release of the DON naming and design rules was DON XML Developers Guide Version 1.0 (29-October-2001). The subsequent release, DON XML Developers Guide Version 1.1, followed the same naming convention. The name change was necessary to release a subset of the DON XML developers guide, before completing the comprehensive developers guide. Thus, the DON NDR is versioned as Version 2.0 and will be incorporated into the DON XML Developers Guide Version 2.0 (or subsequent version) thereafter." Available from Core.gov and doncio.navy.mil
• DON NDR Overview. Presented to the XML.gov XML Community of Practice. September 22, 2004. [cache]

US National Information Exchange Model (NIEM) NDR

On August 7, 2007, a Draft Version 1.2 for the National Information Exchange Model Naming and Design Rules was released. The U.S. National Information Exchange Model (NIEM) is a U.S. Federal, State, Local and Tribal interagency initiative providing a foundation for seamless information exchange. NIEM was launched on February 28, 2005, through a partnership agreement between the U.S. Department of Justice (DOJ) and the U.S. Department of Homeland Security (DHS) and signed by Chief Information Officers.

The NIEM provides a concrete semantic model, leveraging concepts from W3C XML Schema, RDF and the ISO/IEC Standard 11179 Metadata Registries. This semantic model underlies all NIEM-conformant schemas, as well as NIEM-conformant instance data. XML data that follows the rules of NIEM imply specific meaning. The XML Schema components used in NIEM are selected to clarify the meaning of XML data. NIEM provides a framework, within which XML data may be understood to have specific meaning. In general, one limitation of XML is that it does not describe the meaning of an XML document. NIEM adds to the XML specification a guide to determining the meaning of any given document. The rules for NIEM-conformant schemas and instances are in place to ensure that a specific meaning can be derived from data. That is, the data makes specific assertions, and those assertions are well-understood, since they are derived from the rules for NIEM... NIEM defines rules for XML schemas which enforce the NIEM conceptual model. The schemas which follow these rules are referred to as NIEM-conformant schemas...

The Naming and Design Rules (NDR) document specifies schemas for use with the National Information Exchange Model (NIEM). The NIEM is an information sharing framework based on the World Wide Web Consortium (W3C) Extensible Markup Language (XML) Schema standard. NIEM specifies a set of reusable information components for defining standard information exchange messages, transactions, and documents on a large scale: across multiple communities of interest and lines of business. These reusable components are rendered in XML schemas as type, element and attribute definitions that comply with the W3C XML Schema specification. The W3C XML Schema standard enables information interoperability and sharing by providing a common language for describing data precisely. The constructs it defines are basic metadata building blocks — baseline data types and structural components. Users employ these building blocks to describe their own domain-oriented data semantics and structures. Rules that profile allowable XML Schema constructs and describe how to use them help ensure that those components are consistent and reusable....

The NDR document is organized into sections covering the following topics: The NIEM Conceptual Model discusses the underlying semantic model for NIEM; Guiding Principles discusses the principles which serve as the foundation and guidelines for the rules; Relation to Standards discusses the use of the key standards used in the development of NIEM; XML Schema Design Rules discusses the rules for using XML Schema constructs in NIEM-conformant schemas; Modeling Rules discusses the rules for additional structure and constraints needed to build NIEM-conformant schemas; XML Instance Rules discusses the rules for NIEM-conformant XML instance documents; Naming..."

From: NIEM Newsletter: Documentation, May 23, 2007: "While the [NDR has its] own release cycles and is not tied specifically to the NIEM 2.0 "Harmony" release, there was a recognized urgency that the NDR and User Guide be produced and closely aligned with the release of NIEM 2.0. The 'NDR' guide documents the criteria used in creating NIEM, and better enables users to develop NIEM-conformant exchanges. This is particularly valuable as users develop extension schemas to address needs beyond the scope of NIEM and the various representative domains."

On W