- Naming and Design Rules (NDR) Specifications
- ACORD Naming and Design Rules (NDR)
- Danish XML Project: OIOXML Naming and Design Rules
- EPA Exchange Network XML Design Rules and Conventions
- Federal XML Naming and Design Rules Project
- Global Justice XML Data Model (GJXDM) Naming and Design Rules
- Hong Kong OGCIO Interoperability Framework for E-Government
- IRS XML Naming and Design Rules
- OAGIS Naming and Design Rules (NDR)
- OASIS LegalXML Exchange Document Methodology, Naming, and Design Rules (MNDR) Subcommittee
- Universal Business Language (UBL) Naming and Design Rules
- UN/CEFACT XML Naming and Design Rules Technical Specification
- US Department of the Navy XML Naming and Design Rules
- US National Information Exchange Model (NIEM) NDR
- Related Topics
- General References: Articles, Papers, News
This [provisional draft] document supplies references to several specification efforts focused upon design and naming rules for XML components (types, elements, attributes), XML schema module names, namespace names, data elements, domain models, and related constructs. It also references guidelines for best practices in the construction of IRI/URI identifiers for formal and informal technical specifications.
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
- 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 email@example.com, 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."
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..."
- 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
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..."
- 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.
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 ..." (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..."
- 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 firstname.lastname@example.org.
- FED-XML-NDR Project document list
- Contacts: Mark Crawford, Tim Mathews (project owners - initially)
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..."
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.]
- "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:  A product of the Global XSTF;  Technical specification;  Specify how GJXDM is actually defined;  Format as close as possible to UBL NDR document, where appropriate;  Use/copy/borrow appropriate wording from UBL NDR document, or from other inputs;  Specify rules and rationale for rules. What Spec Will NOT Do or Be:  not a projection of UBL/CCTS on GJXDM;  not a comparison of UBL and GJXDM;  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]
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...
- E-Government Interoperability Framework
- Office of the Government Chief Information Officer (OGCIO)
- XML Schema Design and Management Guide:
- Contact: IFCG Standing Office
"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.
- "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:
"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.
- 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)
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 2007, members of the OASIS LegalXML Integrated Justice Exchange Document Methodology, Naming, and Design Rules Subcommittee published Integrated Justice Exchange Document Methodology, Naming, and Design Rules (MNDR) for GJXDM Version 3.0.3 as an OASIS Committee Recommendation. The purpose of this document is to establish guidance on how to develop Global Justice XML Data Model (GJXDM) Information Exchange Package Documentation. The document provides step by step guidelines for the analysis, high level object modeling, GJXDM mapping, construction, and customization of all components of GJXDM conformant information exchange packages, including instance document examples.
Earlier (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]
Integrated Justice Exchange Document Methodology, Naming, and Design Rules (MNDR) for GJXDM Version 3.0.3. OASIS Committee Recommendation. April 03, 2007. 107 pages. Reference: 'wd-ijtc-MNDR-1.1'. Edited by 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). Produced by members of the OASIS LegalXML Integrated Justice Exchange Document Methodology, Naming, and Design Rules Subcommittee, part of the OASIS LegalXML Integrated Justice TC. TC Chairs: Ellen Perry (MTG Management Consultants) and John Ruegg (LA County Information Systems Advisory Body - ISAB). 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). Note: The sponsoring TC closed in 2008-08. [source]
"The purpose of this document is to establish guidance on how to develop Global Justice XML Data Model (GJXDM) Information Exchange Package Documentation. The document provides step by step guidelines for the analysis, high level object modeling, GJXDM mapping, construction, and customization of all components of GJXDM conformant information exchange packages, including instance document examples. The document does not address instructions and requirements regarding messaging and other end-to-end transaction requirements. This document seeks to achieve and support interoperability beyond what is provided by XML Schema and the GJXDM by defining standard development methodologies, best practices and exchange artifacts that meet the needs of technical and business users. It leverages and extends standards defined elsewhere in the technical and justice communities, including rules defined and endorsed by GTRI, the XSTF, OASIS, and W3C... This work incorporates proven work developed by other groups, including GJXDM methods and standards and OASIS UBL. For example, this work is patterned after the successful development of similar methodology, naming, and design rules in the OASIS UBL Technical Committee. In developing these proposed rules and guidelines, the subcommittee consulted and collaborated with other groups in the justice community — including but not limited to the GJXDM Training and Technical Assistance Committee (GTTAC), the Global XML Structure Task Force (XSTF), and the IJIS Institute XML Advisory Committee. In consulting with these groups, the subcommittee sought to incorporate or reference, as appropriate, any existing or emerging work product... GJXDM conformance, as defined by the GJXDM Implementation Guidelines, is a core objective of this specification. The GJXDM is an XML standard designed specifically for justice information exchanges, providing law enforcement, public safety agencies, prosecutors, public defenders, and the judicial branch with a tool to effectively share data and information in a timely manner. The GJXDM provides a library of reusable components that can be combined to automate justice information exchanges. The GJXDM removes the burden from agencies to independently create exchange standards. Because of its extensibility, there is more flexibility to deal with unique agency requirements and changes. Through the use of a common vocabulary that is understood system to system, GJXDM enables access from multiple sources and reuse in multiple applications..."
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.
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.
[November 20, 2009] "Universal Business Language (UBL) 2.0 Naming and Design Rules. Public Review Draft 02. 6-November-2009. Edited by Mike Grimley (US Navy) and Mavis Cournane (Cognitran Limited). Produced by members of the OASIS Universal Business Language (UBL) Technical Committee. The public review started 16-November-2009, and ended 1-December-2009. This specification was previously submitted for a 60-day public review, announced September 13, 2006. See the November 16, 2009 announcement Public Review of Universal Business Language (UBL) 2.0 Naming and Design Rules - 15 day review. Available in HTML format , XML format, and PDF (cache/archive). See also the Comment Resolution Log and announcement for previous Public Review of UBL NDR v2.0 (60-day) on September 13, 2006, with that 'prd-UBL-NDR-2.0' version.
The Naming and Design Rules specification "documents the naming and design rules and guidelines for the construction of XML components for the UBL vocabulary. It conveys a normative set of XML schema design rules and naming conventions for the creation of UBL schemas for business documents being exchanged between two parties using XML constructs defined in accordance with the ebXML Core Components Technical Specification. The UBL NDR primary objectives are to provide the UBL TC with a set of unambiguous, consistent rules for the development of extensible, reusable UBL schemas..."
Background: "XML is often described as the lingua franca of e-commerce. The implication is that by standardizing on XML, enterprises will be able to trade with anyone, any time, without the need for the costly custom integration work that has been necessary in the past. But this vision of XML-based "plug-and-play" commerce is overly simplistic. Of course XML can be used to create electronic catalogs, purchase orders, invoices, shipping notices, and the other documents needed to conduct business. But XML by itself doesn't guarantee that these documents can be understood by any business other than the one that creates them. XML is only the foundation on which additional standards can be defined to achieve the goal of true interoperability. The Universal Business Language (UBL) initiative is the next step in achieving this goal. The task of creating a universal XML business language is a challenging one. Most large enterprises have already invested significant time and money in an e-business infrastructure and are reluctant to change the way they conduct electronic business. Furthermore, every company has different requirements for the information exchanged in a specific business process, such as procurement or supply-chain optimization. A standard business language must strike a difficult balance, adapting to the specific needs of a given company while remaining general enough to let different companies in different industries communicate with each other... The UBL effort addresses this problem by building on the work of the electronic business XML (ebXML) initiative. UBL is organized as an OASIS Technical Committee to guarantee a rigorous, open process for the standardization of the XML business language. The development of UBL within OASIS also helps ensure a fit with other essential ebXML specifications..."
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...
- 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
[January 08, 2010] On January 08, 2010, UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business) posted a 'News' notice for an "approved publication of UN/CEFACT XML Naming and Design Rules Technical Specification Version 3.0 of 17-December-2009. This specification enables the XML syntax binding of CCTS Version 3.0 and Data Type Catalogue Version 3.0 artefacts, and is available" [online]. See the reference page XML Naming and Design Rules, and the blog article by Mark Crawford (SAP Labs), "XML NDR Version 3.0 Finalized". Details:
UN/CEFACT XML Naming and Design Rules Technical Specification Version 3.0. 17-December-2009. 217 pages. Abstract: "This XML Naming and Design Rules specification defines an architecture and set of rules necessary to define, describe and use XML to consistently express business information exchanges. It is based on the World Wide Web consortium suite of XML specifications and the UN/CEFACT Core Components Technical Specification. This specification will be used by UN/CEFACT to define XML Schema and XML Schema documents which will be published as UN/CEFACT standards. It will also be used by other Standards Development Organizations who are interested in maximizing inter- and intra-industry interoperability... This UN/CEFACT technical specification has been developed in accordance with the UN/CEFACT/TRADE/R.650/Rev.4/Add.1/Rev.1 Open Development Process (ODP) for technical specifications. The UN/CEFACT Applied Technology Group (ATG) has approved it for distribution. This technical specification contains information to guide in interpretation or implementation. Specification formatting is based on the Internet Society's Standard RFC format. Distribution of this document is unlimited. This version: UN/CEFACT XML Naming and Design Rules, Version 3.0 of 17 December, 2009. Previous version: UN/CEFACT XML Naming and Design Rules, Version 3.0 Draft of November 16, 2009. This document may also be available in these non-normative formats: XML, XHTML with visible change markup. See also translations. Copyright © 2009 UN/CEFACT, All Rights Reserved.... Contact Information: ATG2 - Jostein Frømyr (EdiSys Consulting AS), NDR Project Lead - Mark Crawford (SAP Labs LLC), and Lead Editor - Michael Rowell (Oracle Corporation)... [cache/archive]
[November 16, 2009] United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) XML Naming and Design Rules. Version 3.0. Implementation Verification, Second Iteration. 30-July-2009. 201 pages. NDR - ODP6 - Implementation Verification. Official release August 04, 2009. Copyright © 2009 UN/CEFACT, All Rights Reserved. Produced by members of the UN/CEFACT Applied Technologies Group. ATG2 Chair: Jostein Frømyr (EdiSys Consulting AS); Project Team Leader: Mark Crawford (SAP Labs LLC, U.S.); Lead Editor: Michael Rowell (Oracle Corporation / OAGi). See sources in the ZIP archive, with file listing. Status: "This UN/CEFACT technical specification is being developed in accordance with the UN/CEFACT/TRADE/R.650/Rev.4/Add.1/Rev.1 Open Development Process (ODP) for technical specifications. The UN/CEFACT Applied Technology Group (ATG) has approved it for broad public review. This technical specification contains information to guide in interpretation or implementation... This XML Naming and Design Rules specification defines an architecture and set of rules necessary to define, describe and use XML to consistently express business information exchanges. It is based on the World Wide Web consortium suite of XML specifications and the UN/CEFACT Core Components Technical Specification. This specification will be used by UN/CEFACT to define XML Schema and XML Schema documents which will be published and UN/CEFACT standards. It will also be used by other Standards Development Organizations who are interested in maximizing inter- and intra-industry interoperability.
[August 18, 2008] UN/CEFACT XML Naming and Design Rules Version 3.0. First Public Review (NDR — ODP5 — Public Review). Edited by Michael Rowell. United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT). 2008-08-07. 144 pages. See the public review guidelines for 'NDR - ODP5 - Public Review'. The document status was described by Mark Crawford (Standards Architect, GEPG Standards Management and Strategy, SAP Labs) on August 10, 2008: Applied Technologies Group (ATG) is pleased to announce that the NDR v3p0 is now at ODP5 - public review. This version incorporates CCTS 3.0 and sets the stage for the forthcoming UCM. It has been developed in partnership with repreesentatives from a number of standards development organizations who have committed to its adoption. The public review period will run from now until 20-September-2008. Comments in the form of: line number, current text, proposed text, reason for change, submitter should be sent to email@example.com and firstname.lastname@example.org. Prefered file format is excel, but any format is accepted..." Status: This UN/CEFACT technical specification is being developed in accordance with the UN/CEFACT/TRADE/R.650/Rev.4/Add.1/Rev.1 Open Development Process (ODP) for technical specifications. The UN/CEFACT Applied Technology Group (ATG) has approved it for broad public review. The technical specification contains information to guide in interpretation or implementation. Specification formatting is based on the Internet Society's Standard RFC format. Distribution of this document is unlimited. This version: 'UN/CEFACT XML Naming and Design Rules, Version 3.0 1st Public Review of 7 April 2008'. Previous version: 'UN/CEFACT XML Naming and Design Rules, Version 3.0 ODP 5 Draft ATG Review 2 of 23 July 2008'.
Produced by ATG2: ATG2 Chair: Jostein Frømyr (EdiSys Consulting AS). Project Team Leader: Mark Crawford (SAP Labs LLC US). Lead Editor: Michael Rowell (Oracle Corporation / OAGi) Contributors: Chuck Allen (HR-XML), Dipan Anarkat (GS1), Serge Cayron (CORD), Anthony Coates (Independent), David Connelly (OAGi), Mavis Cournane (Independent), Alain Dechamps (CEN), Michael Grimley (US Navy), Paul Hojka (APACS), Kevin Smith (Independent), Gunther Stuhec (SAP AP), Jim Wilson (KCX / CIDX). This version OF UN/CEFACT - XML Naming and Design Rule was created to foster convergence among Standards Development Organizations (SDOs) with close coordination with these organizations: ACORD, CIDX, GS1, HR-XML, OASIS Universal Business Language (UBL) Technical Committee, Open Application Group (OAGi).
This XML Naming and Design Rules specification defines an architecture and set of rules necessary to define, describe and use XML to consistently express business information exchanges. It is based on the World Wide Web consortium suite of XML specifications and the UN/CEFACT Core Components Technical Specification. This specification will be used by UN/CEFACT to define XML Schema and Schema documents which will be published and UN/CEFACT standards. It will also be used by other Standards Development Organizations who are interested in maximizing inter- and intra-industry interoperability.
Goals: This technical specification has been developed to provide for XML standards based expressions of semantic data models representing business information exchanges. It can be employed wherever business information is being shared in an open environment using XML Schema to define the structure of business content. It describes and specifies the rules and guidelines UN/CEFACT will use for developing XML schema and schema documents based on CCTS conformant artefacts and information models developed in accordance with the UN/CEFACT CCTS Technical Specification Version 3.0.
Audience: The audience for this UN/CEFACT - XML Naming and Design Rules Technical Specification are: (1) Members of the UN/CEFACT Applied Technologies Group who are responsible for development and maintenance of UN/CEFACT XML Schema; (2) The wider membership of the other UN/CEFACT Groups who participate in the process of creating and maintaining UN/CEFACT XML Schema definitions; (3) Designers of tools who need to specify the conversion of user input into XML Schema definitions adhering to the rules defined in this document; (4) Designers of XML Schema definitions outside of the UN/CEFACT Forum community. These include designers from other standards organizations and companies that have found these rules suitable for their own organizations.
Assumptions: The schema created as a result of employing this specification should be made publicly available in a universally freely accessible library as schema documents. UN/CEFACT will maintain their XML schema as published documents in an ebXML compliant registry and make its contents available to any government, individual or organization who wishes access. Although this specification defines schema components as expressions of core component artefacts, it can also be used by non-CCTS developers for other class based expressions of logical data models and information exchanges. This specification does not address transformations via scripts or any other means. It does not address any other representation of Core Component artefacts. For example, OWL, Relax NG, XMI and others are outside the scope of this document...
Note: "The purpose of the UN/CEFACT Applied Technologies Group is to create and maintain the United Nations trade, business and administration document structures that are deployed by a specific technology or standard, such as UN/EDIFACT, UN Layout Key, UN e-docs or XML. Additionally, ATG has been given responsibility for the development and maintenance of the UN/CEFACT Data Type catalogue in support of CCTS. ATG2 is responsible for the XML Naming and Design Rules (NDR). [source PDF from ATG]
[March 2006] 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..."
- UN/CEFACT XML Naming and Design Rules Version 3.0. First Public Review (NDR — ODP5 — Public Review). Edited by Michael Rowell. United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT). 2008-08-07. 144 pages.
- 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)
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."
"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..."
- 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]
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)
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 Wednesday, August 22, 2007 at the Global Justice Information Sharing Users' Conference 2007 (2:45 p.m. -4:00 p.m., Session E), Mark Kindl and Webb Roberts of GTRI gave a "NIEM 2.0 Technical Walkthrough and Introduction to the Naming and Design Rules." Abstract: "This session is a walkthrough of significant content changes, features, tools, and architecture for NIEM 2.0. The model, its associated products, and significant revisions and features will be discussed. The presenters will review and discuss new functions and capabilities added to the core set of NIEM tools that support creation of IEPDs and migration between NIEM versions. This session will provide an introduction to the NIEM Naming and Design Rules (NDR) and will include relation to existing standards, schema rules, NIEM-specific modeling rules, naming rules, and XML instance rules..."
- National Information Exchange Model Naming and Design Rules. Draft Version 1.2. August 7, 2007. 126 pages. Edited by Webb Roberts (Georgia Tech Research Institute), Susan Liebeskind (Georgia Tech Research Institute), and Mark Kindl (Georgia Tech Research Institute). This document specifies the data model, XML components, and XML data for use 10 with the National Information Exchange Model (NIEM) version 2.0. The document is a draft specification for NIEM-conformant XML components. It represents the design that has evolved from the collaborative work of the NIEM Business and Technical Architecture Committees (NBAC and NTAC) and their predecessors. This version of the specification is a product of the NIEM Program Management Office (PMO), but has NOT been officially approved by either the PMO or the NIEM governance committees (NBAC and NTAC). Send comments on this specification via email to email@example.com.
- NIEM NDR v1.2 references: NIEM NDR Version 1.2 [source], and corresponding text format without line numbers [source]. Also: PDF format with line numbers, and text format with line numbers. With NIEM Draft NDR 1.2 Errata.
- Earlier version: NIEM NDR September 30, 2006. National Information Exchange Model Naming and Design Rules and Data Modeling Guidelines. Draft Version 0.3. 81 pages.
[Section TBD. Schema design, naming, namespace versioning, namespace URIs, etc.]
[August 05, 2007] UN/CEFACT/UBL XML Naming and Design Rules Analysis. By Michael Grimley. Posted to the UBL TC discussion list. A first draft of a document providing UN/CEFACT - UBL NDR comparison and analysis has been posted to the document repository of the OASIS Universal Business Language (UBL) Technical Committee by Michael Grimley. Specifically, it provides a comparison and analysis of Version 2.0 of the UN/CEFACT and UBL NDRs. Version 2.0 of the UN/CEFACT XML Naming and Design Rules technical 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." Mark Crawford (SAP Standards Architect) wrote in a posting to the XML Developers List (26-April-2007): "The CCTS standards stack consists of CCTS. It requires the use of no other specification — UN/CEFACT or other—for implementation. The UN/CEFACT CCTS standards stack however does have a defined XML NDR as part of the stack — for use by UN/CEFACT. Further CCTS does not require any syntax specific set of rules. In fact its power is in its syntax neutrality and its context mechanisms. [David Carver had said: 'There are actually three XML NDRs for CCTS: (1) UBL 2.0 NDR, (2) ATG2 XML NDR 2.0 and 1.0, (3) OAGIs 9 v0.7 NDR'] Actually, there are many more and I am not sure I would include OAGi 9 at this point. The US Department of the Navy for example has their own CCTS NDR. What is interesting is that many SDOs have realized — driven in large part by their membership — that it makes no sense to have different flavors of NDRs and that yes there is real value in being able to auto generate schema from the business models. OAGi, GS1, CIDX, ACORD, UN/CEFACT, UBL, RosettaNet, AIAG, and others have come together to work collaboratively on the next set of UN/CEFACT XML NDRs that will serve as a convergence point for all of these organizations." [canonical source .doc format]
[April 15, 2007] ATG2 Report. From ECE/TRADE/C/CEFACT/2007/4, GE.07-22582. 15-April-2007. Economic Commission for Europe Committee on Trade, Centre for Trade Facilitation and Electronic Business. Thirteenth session: Geneva, 14-16 May 2007. Item 4 of the provisional agenda: Report on UN/CEFACT FORUM Activities Since the 12TH Plenary Session. "UN/CEFACT Applied Technologies Group (ATG) convened during the UN/CEFACT Forum meetings in New Delhi and Dublin. It also held face-to-face meetings in September 2006 in Waldorf, Germany, and in January 2007 in Washington, D.C... (a) Completed production and an audit of a total of 48 XML schemas with release candidate status in support of D06B, including [an] Unqualified Data Type Schema; this schema contains the XML expression of all CCTS conformant Unqualified Data Types. This is an update of the schema published with the release of the NDR specification and incorporates changes made to the supporting code lists... (b) Conducted a successful face-to-face meeting in Waldorf, Germany, during September 2006. Representation from OAGI, ACORD, and GS1 facilitated discussions on making the UN/CEFACT XML NDRs the accepted methodology for adoption by all standards organizations... (c) Conducted a meeting in Washington, D.C., during the week of 15-January-2007 at which representatives from nine different SDOs and a number of U.S. Government agencies contributed to significant progress in achieving a common understanding and alignment of the application of XML NDRs and the use of Core Data Types. ATG is gaining recognition as the venue of choice for achieving convergence in XML methodologies across vertical standards organizations. This will result in significant improvements in interoperability and will greatly facilitate trade... (d) Continued work on the XML NDR V3.0 Project. This project is currently in step 3 of ODP. Significant progress was made on the next version of the XML NDR Specification. The specification will be aligned with the forthcoming CCTS 3.0, and will contain a converged set of XML Schema NDRs that will allow other Standards development organizations (SDOs) such as OAGi, ACORD, STAR, GS1, CIDX, RosettaNet, UBL and others to transition from their own standards to those of UN/CEFACT..." [source]
[December 29, 2006] "XML Serialization of Core Components: Phase 2." By Mark Crawford. SAP Blog. December 29, 2006. "The UN/CEFACT Core Component Technical Specification is the bedrock of the CCTS Standards Stack. At the other end of that stack lies the UN/CEFACT XML Naming and Design Rule Specification. UN/CEFACT uses the XML NDR specification to provide for XML serialization of its CCTS based core component library into XML Schema for B2B messages. As with CCTS, the XML NDR specification plays a key role for SAP in defining the XML serializations of the SAP Netweaver Core and Global Data Types. UN/CEFACT is now embarked on developing the next version of the NDR specification, and SAP will play a key role in that effort. The UN/CEFACT XML NDR specification is a UN/CEFACT profile of the W3C XML Schema Definition (XSD)Language specification. The NDR specification provides for XML syntax serialization of syntax neutral core components in a precise and consistent manner using a well documented, unambiguous rule set. Following these rules, one can transform syntax neutral data model components such as a 'shipping address' from: 'Shipping Address. Details': [Shipping Address. Identification. Identifier], [Shipping Address. Line One. Text], [Shipping Address. Line Two. Text], [Shipping Address. Building. Name], [Shipping Address. Building. Identifier], [Shipping Address. City. Name], [Shipping Address. Country Sub-Division. Identifier], [Shipping Address. Country. Identifier], [Shipping Address. Postcode. Code] to its corresponding XSD element and type expressions [example XML schema definitions]... As you can see in the example, a number of naming and design rules are in play, to include: (1) Truncation - Identifier to ID, elimination of the object class name for leaf elements (no ShippingAddress), removal of duplicate consecutive terms (PostcodeCode to Postcode) (2) Structure - global element declaration of class name (ShippingAddress), named complex type definition (ShippingAddressType), and local element declarations of class properties (ID, LineOne, LineTwo, BuildingName, BuildingID, CityName, CountrySubDivisionID, and Postcode) UN/CEFACT is currently engaged in developing the next version of the CCTS. As the NDR specification is a companion specification, it is logical that work begin on the next version of the NDR as well. In recognition of this, UN/CEFACT has announced the formation of the NDR project team, and described the project effort to create version 3.0 of the NDR specification. That project definition specifies three key components to the NDR project: [i] Preserving alignment between CCTS, the NDR, and other standards in the CCTS standards stack; [ii] Driving convergence between the UN/CEFACT XML NDR and those of other standards bodies interested in stablishing formal relationships with UN/CEFACT, to include OAGi, GS1 Global (XML Design Rules), RosettaNet, CIDX, ACORD, AIAG, and OASIS UBL; [iii] Establishing relationships between UN/CEFACT and the other organizations with the W3C XML Schema Working Group to drive user-based requirements in XSD. UN/CEFACT defines the scope of the NDR project as providing rules and guidelines for normative-form schema design, instance design, and markup naming that is consistent with the UN/CEFACT Core Components and related technical specifications. These rules and guidelines will be used to create UN/CEFACT schema expressions of business models, and may also be used by other organizations consistent with their business requirements.."
[August 11, 2006] XML NDR. Resources from the SAP Developer Network. "The United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) XML Naming and Design Rules Technical Specification (UN/CEFACT XML NDR) describes how ISO 15000-5 CCTS (Core Component Technical Specification) syntax independent components are systematically represented in XML Schema. The NDR is an implementation profile of, and produces schema and instances that are fully conformant to the World Wide Web Consortium (W3C) XML Schema Definition (XSD) Language Recommendation. Alongside basic definitions for each schema component, this specification sets out rules to ensure that the schema components are universally deployable in a specific business context. The specification rules, in conjunction with the underlying CCTS source data components, also ensure the schema components contain semantics that are unambiguous for all types of business information. The UN/CEFACT XML NDR plays a key role in SAP. Specifically, The CCTS conformant SAP Global Data Types (GDTs) provided by SAP NW for SAP ESA's business oriented interfaces are being represented in XML Schema following the guidelines of the XML NDR technical specification..."
[August 04, 2006] "Getting Started with UN/CEFACT XML NDR for CCTS." SAP Developer Network (SDN) Contribution. By Gunther Stuhec and Mark Crawford. August 04, 2006 PDF format. 9 pages. "The United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) XML Naming and Design Rules Technical Specification (UN/CEFACT XML NDR) describes how ISO 15000-5 CCTS (Core Component Technical Specification) syntax independent components are systematically represented in XML schema and XML instances. This specification is a CCTS implementation profile for the W3C XML Schema Definition (XSD) Language Recommendation, and schema developed in accordance with the XML NDR specification will be fully XSD conformant. Included are rules to ensure that CCTS conformant components are consistently expressed as XML — regardless of the business context or purpose. The specification contains a set of rules governing extension and restriction, version management, design, and runtime to ensure that components remain fully interoperable. A key aspect of the extension and restriction approach is that all changes to the underlying data model components are always made first to the data models and then expressed in the schema. As such, xsd:redefine and xsd:extension are tightly controlled. This approach guarantees the general consistency for the unambiguous and common understandable composition of semantic information at every syntax level, not just its XML expression. The specification also provides for the XML instantiation of the predefined CCTS Core Data Types (CDTs) as a fixed set of XML Schema types. These CDTs represent the basis for all CEFACT element declarations and must be used in a CCTS conformant XML Schema. The XML instantiation of CCTS components can be used for representing internal data structures, for accomplishing internal data flows and external business message data exchange, and for every aspect of XML based frameworks, such as web services. CCTS conformant SAP Global Data Types (GDTs) provided by SAP NW for SAP ESA's business oriented interfaces are being represented in XML Schema following the guidelines of the XML NDR technical specification..."
[March 07, 2006] "A Tool Kit for Implementing XML Schema Naming and Design Rules." By Josh Lubell and Serm Kulvatunyou (US National Institute of Standards and Technology). Presented at XML 2005 (November 15, 2005). "A tool kit being developed at the National Institute of Standards and Technology (NIST) encodes XML schema Naming and Design Rules in a computer-interpretable fashion, enabling automated rule enforcement and improving schema quality... Organizations developing XML schemas often establish Naming and Design Rules (NDRs) in order to maximize interoperability and quality. NDRs are a good way to help enforce best practices, a particular modeling methodology (such as the Core Components Technical Specification - CCTS), or conformance to standards such as ISO 11179 (Naming and Design Principles for Data Elements). But no single set of Naming and Design Rules can satisfy everyone's requirements. As a result, NDRs are proliferating... To complicate matters further, most NDRs are standardized as presentation-oriented documents to be read by humans. They are not easily machine-interpretable. Ambiguities and lack of automation make rule enforcement difficult. On the other hand, if rules are encoded in a computer-interpretable form, then a single implementation is chosen, ambiguities disappear, and the rules can be applied automatically as part of XML schema validation. If schemas are automatically generated using a software tool, then NDR conformance can be built into the schema generation process... NDRs tend to be authored in proprietary binary word processor formats and lack any explicit document structure. As a result, it is hard to compare NDRs with one another or to track changes between different versions of an NDR. Therefore, NDR developers are inclined to reinvent the wheel rather than maximize reuse of existing NDRs. The following barriers prevent NDRs from improving schema interoperability and quality: NDR proliferation, absence of NDR document structure, lack of automated rule enforcement, and limited versioning and traceability. This paper explores methods for removing these barriers. We first discuss some implementation issues, using a rule from the Universal Business Language (UBL) NDR as an example. Next, we present a methodology for implementing NDRs and a prototype system using our methodology. We conclude with some observations regarding our experience... The proposed QoD Exchange Schema representa the Naming and Design Rules in a QoD test profile; this schema is provided both in RELAX NG and in the World Wide Web Consortium (W3C) XML Schema Definition Language, the latter generated from the former using James Clark's Trang software..." See also the slides; cache PDF.
[October 19, 2005] "Federal XML Naming and Design Rules and Guidelines." XML.gov presentation by Paul Macias. NDRG Status Update. Also in .PPT format [source].
[September 19, 2005] "XML Group Updating Federal Design Guidebook." By Joab Jackson. From Government Computer News (September 19, 2005). "The U.S. General Services Administration, the Homeland Security Department, and the Federal CIO Council are collectively revamping a widely used federal guide for creating Extensible Markup Language-based schemas. The revision will bring the XML Developers Guide, first drafted in 2002, in line with more recently adopted best practices, according to Mark Crawford, a senior research fellow for LMI Consulting of McLean, Va. LMI supports GSA's Office of Governmentwide Policy for the effort, which is undertaking the work along with the Federal CIO Council's XML Community of Practice and DHS' Metadata Center of Excellence. The research firm will present a report on the group's progress Wednesday at the monthly XML Community of Practice meeting. At least one other government technology group has taken notice of the document. The Intelligence Community Metadata Working Group Staff submitted a paper detailing its issues with the new draft. Chaired by Tim West of the Defense Intelligence Agency, the working group represents 15 U.S. intelligence federal agencies. The group now estimates that the changes in the guidelines would affect up to 35 projects within its agencies. The group is taking a number of existing guidelines as the basis for the revamped document, including the Universal Business Language from OASIS. It will also use material from the U.N. Centre for Trade Facilitation and Electronic Business and borrow from individual agency guidelines from the Department of the Navy, the Environmental Protection Agency, the IRS and others..."
[August 19, 2005] "Initiatives Ramp Up Work on XML Naming and Design Rules Specifications." Several industry and government initiatives are now gaining momentum in related efforts to create formal rules/guidelines for naming XML components: XML namespace names, types, elements, attributes, code list enumerations, domain models, etc. The naming specifications are aimed at optimizing semantic interoperability, modularity, extensibility, maintainability, and data element re-use through best-practice design of XML Schemas and related business components.
[August 17, 2005] "Federal XML Naming and Design Rules and Guidelines." By Mark Crawford (LMI). Presented at the XML Community of Practice (xmlCoP) Meeting, August 17, 2005. Department of Justice (DOJ), Office of Justice Programs Building, 810 Seventh Street, NW, Washington, DC. 25 slides. Also PDF. See the summary/extract. [source]
[August 09, 2005] Federal NDR Comparison. Draft document, compares ATG/DON/IRS/UBL NDR documents to the draft Federal NDR. Reference: 'NDR Comparison.xls'. 87 pages (PDF format). The spreadsheet has 397 identified topics (rules) drawn from the five NDRs. [source .xls spreadsheet]
[July 29, 2005] "An Unconventional XML Naming Convention." By Eric van der Vlist. Weblog de Eric van der Vlist. July 29, 2005. "I am not a big fan of naming conventions but I don't like to be obliged to follow naming conventions that do not seem to make sense! [...] It happens that the conventions most of my customers have to follow are the UN/CEFACT XML Naming and Design Rules Version 1.1 (PDF). Per ebXML and UBL, they state that: Following the ebXML Architecture Specification and commonly used best practice, Lower Camel Case (LCC) is used for naming attributes and Upper Camel Case (UCC) is used for naming elements and types. I think that these rules do not make sense for a couple of reasons... My preferred naming conventions for XML schemas (and those that I am going to follow in the future for projects that are not tied to other conventions) is to use LCC for element and attribute names and UCC for type and group names (or RELAX NG named patterns). Sticking to this rule will give consistency with the Object Oriented world and allow me to get rid of suffixes to distinguish between what can be seen in the instance documents (elements and attributes) and what belongs to schemas (types, groups or RELAX NG named patterns)..."
[July 28, 2005] "Emerging Federal XML Schema Guidance." Federal NDR (XDG). Prepared by the United States Intelligence Community Metadata Working Group (IC MWG). Page last modified 7/28/2005 or later. "An effort began in May 2005 to update the April 2002 Draft Federal XML Developer's Guide, one of the federal sources of XML Schema guidance for the various IC MWG standards. The current working title of the new document is the Federal XML Naming and Design Rules, although it is likely to be renamed the US Federal XML Developer's Guide. This emerging guidance document is based on three variants of Naming and Design Rules (NDR) documents from OASIS UBL, UN/CEFACT, and the Department of the Navy... Members of the IC MWG staff are actively tracking this federal guidance effort. Our major objections are collected below. Note that the June 9, 2005 guidance draft contains very few examples and little justifcation for most of its rules. We are very interested in encouraging your direct input to this effort..." Contact: Kenneth.B.Sall@saic.com in an email message with 'Subject: XDG Feedback'.
[July 19, 2005] Federal XML Naming and Design Rules: Changes Proposed by the IC Metadata Working Group Staff. Position paper prepared by the Intelligence Community Metadata Working Group Staff. ADNI/CIO/ICCIO/ISC — IC MWG. July 19, 2005. Posted Friday, July 22, 2005. 17 pages. "The IC MWG includes participants from all 15 of the IC agencies... The Intelligence Community Metadata Standard for Publications (IC MSP) is a set of XML schemas for generic publication types, along with documentation in the form of a data element dictionary and an implementation guide. The schemas are implemented in two syntaxes; XML document type definitions (DTDs) and W3C XML Schemas. The standard has been developed as a cooperative effort in response to requests by numerous organizations within the IC to have an IC-wide mandated XML model to support interoperability of intelligence content across producers and consumers of information within the Community... This position paper covers aspects of the draft Federal XML Naming and Design Rules,1 dated June 9, 2005, which are incompatible with certain practices and needs of the Intelligence Community (IC), as promulgated by the IC Metadata Working Group (IC MWG). Our community has been developing and using XML Schemas and DTDs for many years. We have enthusiastically promulgated the guidelines from the April 2002 Draft Federal XML Developer's Guide and would like to be able to leverage the emerging 2005 guidance as well. However, the June 2005 draft contains a number of rules that would severely conflict with work the IC MWG has already completed, impacting up to 35 organizations affected by IC policy on metadata and metadata markup. The rules also interfere at a technical level with some of the near term changes planned by the IC MWG..." Also available in Word .doc format; PDF from CORE.gov, PDF from XML.gov
[May 20, 2005] "SAP User Experience Report on XML Schema." Prepared by: Ümit Yalçinalp, David Burdett, and Gunther Stuhec (SAP Platform EcoSystem Industry Standards). May 20, 2005. Submitted to the W3C as input to the W3C Workshop on XML Schema 1.0 User Experiences, June 21-22, 2005, Oracle Conference Center, Redwood Shores, CA, USA. This paper is SAP's User Experience Report on XML Schema. "The SAP NetWeaver application platform on which ESA is built provides SAP's environment for: writing business applications, process integration, business integration as well as people and information integration. Our integration server provides proxies to existing applications that utilize XML Schema for building Web Services. Our development tools, J2EE and ABAP based language environments also require access to and processing of XML Schema based documents. In addition, vertical business vocabularies are expressed using XML Schema which is crucial for business integration and application development... Development of XML business vocabularies is important for SAP. Therefore, SAP actively participates in and is a key contributor to: (1) The UN/CEFACT Core Component specification (CCTS) that specifies the content of commonly used data components such as Address, Line Item, etc in a syntax neutral way, and (2) The UN/CEFACT XML Naming and Design Rules for CCTS (NDR) that specifies a set of rules and restrictions for XML Schema usage that can be used to define core components as XML for interoperability. In essence the XML Naming and Design rules define a 'profile' of XML Schema that reduces the complexity and variability of XML business vocabularies. The profile defines best practices as well as which features of XML Schema to use. Certain aspects of XML Schema are not permitted and/or found useful, such as redefine, extensibility with substitution groups and xs:any. Further restrictions have only been used to restrict values by facets (for values) and extensions have only been used to add attributes to existing types. Hence, the complexities of XML Schema authoring have been reduced when building business vocabularies..." [On] Global vs. Local Element Declaration: Different types of declaration [Russian Doll, Salami Slice, Venetian Blind, Garden of Eden] lead to completely different representations of XML instances. The biggest concern here is that these XML instances can never be validated by XML Schema, where different types of element declarations are used. For example the Universal Business Language (UBL) and UN/CEFACT cannot align their approaches for designing business documents because they use different design patterns. This means that, even though they use the same CCTS approach with similar or identical semantics, the XML instances will always be different..."
[January 31, 2005] "XML Naming and Design Rules Specifications Published by OASIS, UN/CEFACT, and Navy CIO." Three closely aligned specifications governing XML naming and design rules have been approved for public release. Each of the NDR specifications builds upon the methodolgy and syntax-neutral object model specified by the Core Component Technical Specification (CCTS) published by UN/CEFACT in conjunction with OASIS as Part 8 of the ebXML framework. The Universal Business Language (UBL) Naming and Design Rules from the OASIS UBL Technical Committee has been approved as an OASIS Standard. The UN/CEFACT XML Naming and Design Rules produced by the Working Group 2 of the UN/CEFACT Applied Technology Group (ATG) has been approved by the United Nations Centre for Trade Facilitation and Electronic Business for implementation verification in accordance with Step 6 of the UN/CEFACT/TRADE/22 Open Development Process (ODP). 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 supersedes the DON XML Developers Guide, Version 1.1. The NDR specifications have very similar goals, aimed optimizing semantic interoperability, modularity, extensibility, maintainability, and data element re-use through best-practice design of business components.
[January 25, 2005] "Navy Steams Ahead With Official XML Rules." By Susan M. Menke. From Government Computer News (January 25, 2005). "The Navy has taken the federal lead in setting enterprisewide naming and design rules, or NDRs, for use of Extensible Markup Language in all systems. NDR 2.0 will go public today on the Navy's site. Navy Department CIO David M. Wennergren said in a memo that the rules will ensure that all service systems exchanging data with XML are 'based on a consistent set of schema' to align them with the Defense Department's network-centric data strategy and the Federal Enterprise Architecture Data Reference Model. NDR 2.0 also will give the Navy's ForceNet a common structure for handling information, Wennergren said. The service's NDR, under way since 2001, 'adheres to the Office of Management and Budget's policy for voluntary consensus standards' instead of idiosyncratic standards, said Mark L. Crawford, senior research fellow at LMI Government Consulting of McLean, Va. Crawford said the XML mandate puts the Navy 'absolutely in the lead' among agencies. 'No other agencies to my knowledge have reached a Version 2.0.' The Navy has taken an active part in international standards groups such as the World Wide Web Consortium and the Organization for the Advancement of Structured Information Standards, he said. NDR 2.0 follows the Universal Business Language naming and design rules..."
[November 2004] "How the US Federal Government is Using XML: One Year Later." By Kenneth Sall (SiloSmashers). Presented at XML 2004 Conference and Exhibition (November 15-19, 2004, Washington, DC, USA). "It is certainly no coincidence that the DON XML Work Group, an OASIS UBL subcommittee on Naming and Design Rules (no longer operational), and the UN/CEFACT Applied Technologies Group (ATG) are each authoring a document that has 'Naming and Design Rules' in its title. The UN/CEFACT XML Naming and Design Rules, Draft 1.0 published in August 2004, is the first of these NDRs to be made publicly available. According to the acknowledgements in that document, '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.' Contributions from various other organizations are listed, including the U.S. Department of the Navy, U.S. Environmental Protection Agency, U.S. Federal CIO Council XML Working Group, among others. Note: At the time of this writing, the agenda for the 22 September 2004 XML Working Group (or Community of Practice) indicated that there would be a discussion of the DON XML Naming and Design Rules (NDR) and Related Standards, and tentatively lessons learned in applying the DON NDR, and, perhaps very significantly, establishment of DON NDR as Governmentwide good practices through the CIOC/AIC. Also a UBL version of Naming and Design Rules is rumored to be in circulation. See XML.gov presentations for 22 September 2004 to follow-up this topic..."
[August 25, 2004] "UN/CEFACT Applied Technologies Group Releases XML Naming and Design Rules Specification." The Applied Technologies Group (ATG) of the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) has announced the release of a UN/CEFACT XML Naming and Design Rules (NDR) specification for public review. The UN/CEFACT — XML Naming and Design Rules "describes and specifies the rules and guidelines that will be applied by UN/CEFACT when developing XML schema specifications. It 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." According to the design goals, the XML Naming and Design Rules specification "can be employed wherever business information is being shared or exchanged amongst and between enterprises, governmental agencies, and/or other organisations in an open and worldwide environment using the XML schema language for defining the content of the information exchange. This specification will form the basis for standards development work of technical experts developing XML schema specifications based on information models developed in accordance with the UN/CEFACT — Core Components Technical Specification — Part 8 of the ebXML Technical Framework (ISO 15000-5 Candidate)."
[December 2003] "Naming and Design Rules for E-Government — The Danish Approach." By Mikkel Hippe Brun (National IT and Telecom Agency) and Brian Nielsen (National IT and Telecom Agency). Presented at XML 2003. "Reuse from different namespaces requires that the same XML Schema Naming and Design Rules are used. XML Schema Naming and Design Rules (NDR) are key to successful application integration in E-Government. The Danish approach is to rely heavily on reuse of atomic schema fragments from a large number of namespaces related to different authorities and international standardization initiatives, such as the OASIS Universal Business Language (UBL). The Danish naming and design rules differ in a number of ways from the naming and design rules of UBL. The paper will present the naming and design rules and the rationale leading to the differences with UBL naming and design rules... The Danish XML Committee has decided to embrace and re-use ebXML and UBL Core Components. This decision is a challenge since these vocabularies are composed from weakly defined elements and types. The approach taken is to define a number of national namespaces which are strongly typed versions of the ebXML and UBL namespaces. The criteria is that for each element in the national namespace - it must be possible to transform the element into the corresponding ebXML or UBL namespace. This approach and its applicability for other national XML initiatives is discussed..." [cache PDF]
[October 16, 1999] Naming and Capitalization Conventions for Elements and Attributes in Legal XML Documents." By Rolly Chambers. For the Legal XML Work Group. Document Number: UN_10001_1999_10_16. "This Unofficial Note proposes some basic conventions for naming and capitalizing XML elements and attributes in DTDs or schema for XML Legal Documents... [It] proposes some conventions to guide developers in naming and capitalizing XML element tags and XML attributes in DTDs or schema for XML legal documents. There are no established formal conventions for naming or capitalizing XML elements or attributes. The absence of formal conventions for naming or capitalizing XML elements and attributes can lead to needless confusion and can complicate efforts to develop names for XML elements and attributes in DTDs or schema for legal documents. The XML Specification allows users virtually unlimited freedom to create names for XML elements and attributes. Thus, different authors might use the tags <Phone>, <telephone_number>, <phoneno>, <Tel> or <PhoneNumber> to describe the same item of information without running afoul of the XML specification. The use of different abbreviations also is permitted in XML. However, allowing a plethora of tag names and/or abbreviations for information in an XML Legal document adds unnecessary and unwanted complexity to efforts to develop standard tags..." [source]