SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors
NEWS
Cover Stories
Articles & Papers
Press Releases
CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG
TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps
EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
|
| News: Cover Stories |  |  |
| XML Naming and Design Rules Specifications Published by OASIS, UN/CEFACT, and Navy CIO. |
Contents
Update 2005-08-19: See the news story "Initiatives Ramp Up Work on XML Naming and Design Rules Specifications."
[January 31, 2005] 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. The UBL NDR specification "provides guidelines for the construction of XML components for the UBL vocabulary, conveying 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." The UN/CEFACT ATG2 NDR "describes and specifies the rules and guidelines that will be applied by UN/CEFACT when developing XML schema; 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." The DON NDR "addresses many key aspects of XML schema architecture that are critical to effecting successful data management and harmonization (an XML data management approach, XML namespace and modularity, and versioning) to to provide the DON XML developer with a clear and comprehensive set of XML development rules and guidance that will standardize XML across the DON and promote global interoperability."
The UBL Naming and Design Rules document is representative of concerns addressed by all three NDR specifications: "Overall Schema Structure; Naming and Modeling Constraints; Reusability Scheme; Namespace Scheme; Versioning Scheme; Modularity Strategy; Schema Documentation Requirements; Naming Rules; Declarations and Definitions; Code Lists; Miscellaneous XSD Rules." The DON NDR also covers information analysis rules, data management rules, schema modularity rules, and security rules.
Appendix A "UBL NDR Checklist" summarizes the UBL rules, and these are organized in an alphabetized category order: Attribute Declaration Rules; Attribute Naming Rules; Code List Rules; ComplexType Definition Rules; ComplexType Naming Rules; Documentation Rules; Element Declaration Rules; General Naming Rules; General Type Definition Rules; General XML Schema Rules; Instance Document Rules; Modeling Constraints Rules; Naming Constraints Rules; Namespace Rules; Root Element Declaration Rules; Schema Structure Modularity Rules; Standards Adherence Rules; SimpleType Naming Rules; SimpleType Definition Rules; Versioning Rules.
Guidelines for XML schema construction and component naming as delineated in the three NDR specifications are framed against the backdrop of methodologies for information analysis and data element design standardized in the UN/CEFACT Core Components Technical Specification — Part 8 of the ebXML Framework (CCTS). CCTS has now been published as an ISO Technical Specification: ISO/TS 15000-5 ebCCTS. ebXML Electronic Business Extensible Markup Language, Part 5: ebCCTS ebXML Core Components Technical Specification, Version 2.01 (2003-11-15). The CCTS itself is based upon ISO/IEC 11179 Information Technology — Metadata Registries.
The common methodology and core components model of the CCTS framework have made alignment of the three NDR specifications possible. The Core Components specification "presents a methodology for developing a common set of semantic building blocks that represent the general types of business data in use today and provides for the creation of new business vocabularies and restructuring of existing business vocabularies. The Core Components concept defines a new paradigm in the design and implementation of reusable syntactically neutral information building blocks. Syntax-neutral Core Components are intended to form the basis of business information standardization efforts and to be realized in syntactically specific instantiations such as ANSI ASC X12, UN/EDIFACT, and XML representations such as UBL."
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. UN/CEFACT XML design rules are closely coupled with CCTS. UN/CEFACT XSD Schema are developed from fully conformant Business Information Entities that are based on fully conformant Core Components. The DON NDR specifies the CCTS as the basis for DON XML information analysis."
Harmonization of the three NDR documents has also been made possible through the high level of cooperation between participants in several standards organizations contributing to the NDR development. Mark R. Crawford (LMI Senior Research Fellow and XML Lead) has played an influential role in convergence efforts; he is OASIS UBL TC Vice Chair, Chair of the UN/CEFACT XML Syntax Working Group, Editor of UN/CEFACT Core Components, and XML Technical Consultant to the Department of the Navy. The UBL TC works closely with the UN/CEFACT ATG Working Group 2 (XML Assembly Documents/Production Rules — ATG2), with UN/CEFACT TBG17 WG (Harmonisation), and with the OAGi Core Components Work Group to bring about convergence in the naming and data modeling rules. Michael Grimley is the official US Department of the Navy representative to the UBL TC, member of the Department of the Navy XML Working Group, and has played an instrumental role in aligning the aligning the Department of the Navy work efforts with those of UBL.
Where the three NDR specifications differ in minor ways with respect to scope, focus, or design strategy, the differences arise naturally from each specification's development context, dependencies, and domain applicability; these differences are sometimes reflected in the "Guiding Principles" outlined in the specifications.
The ATG2 NDR "Guiding Principles" calls out explicit relationship to UMM ("UN/CEFACT XSD Schema will be based on UMM metamodel adherent Business Process Models") and clarifies that UN/CEFACT XML design rules will support schema creation through handcrafting as well as automatic generation. The ATG2 Reusability Scheme then notes that "UN/CEFACT is committed to transitioning to an object based approach for its process models and core components implementation efforts as supported in both UMM and CCTS... a type based approach for XML management provides the closest alignment with the process modelling methodology described in UMM... All element declarations for BBIEs and ASBIEs must be locally declared within the parent ABIE type. Although ATG follows a local element design approach, in fact, each local element declaration is unique across the full range of types, because the elements instantiations of the underlying Core Components Model that goes through a rigorous harmonization and approval process in building the UN CEFACT Core Component Library."
Element declarations in the UBL NDR are global, based upon the UBL Reusability Scheme statement that "the effective management of the UBL library requires that all element declarations are unique across the breadth of the UBL library; all element declarations must be global with the exception of ID and Code which must be local." The DON NDR follows UBL in the use of (mostly) global element declaration: "All element declarations must be global with the exception of Identifiers, Measures, and Codes, which may be declared as local elements if, and only if, approved by the Functional Namespace Coordinators (FNC) and Business Standards Council (BSC)."
The developers expect that with additional work, there will be almost complete functional alignment between the three NDR specifications. Complete bibliographic detail and further description of the three NDR specifications are provided below.
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 Desré (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). UN/CEFACT XML Naming and Design Rules. Draft 1.1. 14-January-2005. 141 pages. Document identifier: 'NamingAndDesignRules_1.1.doc'. Location: ATG downloads. 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 Frømyr (EDISYS), Sue Probert (SEPIA eb), Alain Dechamps (CEN), Michael Dill (GEFEG). "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."
"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." 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."
The Universal Business Language (UBL) Naming and Design Rules specification was submitted to the OASIS membership for standardization in December 2004 and has been announced as an approved OASIS Standard (January 24, 2005). Several OASIS member organizations certified that they are successfully using the UBL Naming and Design Rules: Sun Microsystems, Hitachi Systems & Services, Ltd., OSS Nokalva, Denmark Ministry of Science, Technology & Innovation, Center for Document Engineering, University of California at Berkeley, University of Hong Kong, and Korea CALS/EC Association. "The UBL NDR document specifies naming and design rules and guidelines for the construction of XML components for the UBL vocabulary. It is normative with regard to UBL 1.0 schemas and is also expected to be useful to other XML schema developers, in particular those implementing ebXML Core Components."
The OASIS UBL Technical Committee continues work on the NDR [early 2005] as part of the UBL version 1.1 design work. At its McLean, Virginia, USA meeting of 31-January-2005 through 04-February-2005, the UBL TC members will review the CCTS schema modules proposed by UN/CEFACT ATG2. The TC maintains an NDR Tracking Sheet [v5, posted by Mavis Cournane, .XLS source].
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.
UN/CEFACT ATG Working Group 2 (ATG2) 'XML Assembly Documents/Production Rules' was formed 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, and UML to XML Methodologies."
The XML Naming and Design Rules Version 1.1 of 14-January-2005 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.
The UN/CEFACT NDR was 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 the document," so that the structure and content are highly similar.
The XML Naming and Design Rules "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... it may 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."
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..."
"The Department of the Navy XML Naming and Design Rules, Version 2.0, updates and supersedes the DON XML Developers Guide, Version 1.1. 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..." [spec Introduction]
"... 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.
The DON XML NDR can be downloaded from the web at www.doncio.navy.mil. If you have questions concerning DON XML policy and guidance, or would like to participate in our DON XML initiatives, you can contact us from the DON CIO webpage.
As we implement solutions that leverage the benefits of XML, adherence to the NDR is critical. Your support is essential for the Department to successfully transform to an interoperable, net-centric environment and to align with the DoD Net-Centric Data Strategy. I encourage you to participate in the DON XML working groups that will continue to provide necessary standards, guidance, and harmonization processes to support XML implementation initiatives across the DON and to assure alignment with emerging Federal and Department of Defense net-centric strategies...
The DON CIO recognizes that not all projects and systems will be able to take advantage of this technology immediately. In that event, please coordinate with my staff to develop a migration path that will allow you to implement conformant XML solutions in the future. If you have questions concerning DON XML policy and guidance, or would like additional information about DON XML initiatives, please contact my DON CIO point of contact for Data Management, Mr. Bob Green, at 703-607-5654, or via email at robert.a.qreen2@navy.mil..."" [D.M. Wennergren, Department of the Navy Chief Information Officer, January 18, 2005]
Section 2 'Information Analysis Rules' "summarizes the DON XML information analysis approach and the development of the syntax neutral model. The information analysis process produces a set of data elements documented with appropriate metadata, such as CCTS component types. CCTS component types must be Aggregate Business Information Entities (ABIEs), Association Business Information Entities (ASBIEs), Basic Business Information Entities (BBIEs), or DataTypes (qualified or unqualified)...
Section 3 'Data Management Rules' addresses rules for consistent XML schema creation by all DON stakeholders. These rules must provide concise and clear guidance on the design and use of XML. More important, these rules must clearly articulate the which, why, and how DON XSDs will be designed. Chief among the design decisions the DON must address is how to declare XML elements...
Section 4 'Namespace and Schema Modularity Rules' notes that "The DON enterprise architecture must conform to higher-level DoD architecture frameworks, guidance, and specifications. In addition, the DON standard for XML namespaces will continue to interoperate with the DoD registry... The purpose of this section is to summarize the DON XML namespace and schema modularity approach. The BSC approved the namespace and schema modularity approach after significant research, analysis, and discussion...
Section 5 'Versioning Rules' specifies that "version information must be contained in both in the
schema and in the schema's target namespace. This section will detail the DON versioning rules for both namespace and schema. The DON process for identifying and harmonizing schema components into the
enterprise means that new components will need to be added to the 1.0 enterprise namespace at intervals and new versions of existing components will need to be added to higher versioned namespaces...
Section 6 documents 'General XML Rules' based upon W3C XML Schema. Section 7 covers 'Naming, Definition, and Declaration Rules'.
Section 8 'Code List Rules' follows the guiding principle is that the DON library should identify and use external standardized Code List Schema modules rather than develop its own DON-native Code List Schema modules.
The DON has determined that the best approach for code lists is to handle them as schema modules. Because most code lists are maintained by external agencies, the DON has determined that if code list owners all use the same normative form schema module, all users of those code lists could avoid a significant level of code list maintenance...
Section 9 covers 'XML Instance Rules'. Section 10 'Security Rules' summarizes the DON XML security rules and approach. The DON NDR has adopted the W3C and OASIS XML security standard recommendations as the DON standard for securing and signing XML communications. Specifications references include XML Encryption Syntax and Processing; Decryption Transform for XML Signature; XML-Signature Syntax and Processing; Security Assertion Markup Language (SAML); Extensible Access Control Markup Language (XACML); WS-Security.
According to a 2005-01-26 posting from Garret Minakawa (Oracle, co-editor of the UN/CEFACT NDR), OAGi is "a full voting member of UN/CEFACT ATG2, and is also an Editor of the ATG2 NDR. [The OAGi Core Components Work Group] 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. In some cases, however, there are still differences between ATG2 and OAGIS 9.0..."
- UBL references:
- UN/CEFACT references:
- U.S. DON references:
- UN/CEFACT and ebXML Core Components references:
- ebXML Core Components - Overview
- Relationship of UBL to ebXML Core Components
- References for Core Components
- "UN/CEFACT ebXML Core Components Technical
Specification Approved for Implementation Verification."
- "Core Components Technical Specification — Part 8 of the ebXML Framework." UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business). CCTS. 15-November-2003. Version 2.01. 113 pages. Previous version: UN/CEFACT — Core Components Technical Specification, Version 2.0 of 11-August-2003. "This [2.1] edition is an updated version of Core Components Technical Specification Version 2.0, first published 11-August-2003; it merely incorporates a title correction and minor first-edition errata related to ebXML references as a convenience to readers." To become an ISO Technical Specification as Part 5 of ISO/TS 15000. ZIP sources: CEFACT, OASIS.
- ISO/PRF TS 15000-5. Electronic Business Extensible Markup Language (ebXML) -- Part 5: ebXML Core Components Technical Specification, Version 2.01 (ebCCTS). Approval stage (for ISO Technical Specification) as of 2004-12-02.
- ISO/TS 15000-5 ebCCTS. ebXML Electronic Business Extensible Markup Language, Part 5: ebCCTS ebXML Core Components Technical Specification, Version 2.01 (2003-11-15). See Result of Voting on New Work Item Proposal ISO/TC154N466," ISO/TC154N466 Add.1, posted on 2004-11-09 by François Vuilleumier (ISO/TC154 chair + ISO7372MA secretary) with note of press release to be issued by the UN/CEFACT Secretariat in Geneva, ebCCTS now an ISO Technical Specification, results of the ballot in file 154n466a1. Alt sources: OAGI Core Components Work Group List and OASIS ebxml-jc list (PDF). Original from 154n466a1 ebXML votes TS15000-5.pdf via ISO/TC154 portal.
- UN/CEFACT — Core Components User's Guide. Version 1.0. 16/30-October-2003. 96 pages. Also referenced as the Core Components Primer. PDF source from the the website of the Electronic Commerce Platform in the Netherlands (courtesy Fred van Blommestein) "This user guide is approved after completion of the TMG review process that ended 21-September-2003. This document contains information to guide in the interpretation or implementation of the UN/CEFACT ebXML Core Components Technical Specification... The primer illustrates the discovery and implementation of Core Components by elaborating two real life examples in detail: the Boeing Part Ordering System and the EAN.UCC Delivery Process for Fast Moving Consumer Goods (FMCG). It should be used as a supplemental document to the ebXML Core Components Technical Specification. This primer shows how the employment of the Core Components methodology may be used for analysing the needed information flows in cross-organisational processes and how it can lead to information models and communication systems that are usable internationally and cross-industry..." Note 2004-10-30 from Mark R. Crawford (Chair, UN/CEFACT XML Syntax Working Group; Editor, UN/CEFACT Core Components) "... the Core Components User's Guide is an unofficial document that has never received a final formal review or approval within CEFACT."
- "ebXML Core Components and UBL - A Recipe for eBusiness Data Interoperability." By Sue Probert (Commerce One). Presented at XML Europe 2003. The ebXML Core Components Technical Specification "is part of the larger ebXML framework. Specifically, the Core Components specification provides the basis for the ebXML payload by providing a new approach to creating reusable, semantically neutral, information building blocks. The OASIS UBL, OAG, EAN-UCC, SWIFT, UN/CEFACT, ANSI ASC X12 and a host of other standards organizations are already using this new approach as the basis for building interoperable XML business standards... This presentation will present an overview of the United Nations ebXML Core Components Technical Specification and will explain how the OASIS UBL (Universal Business Library) TC has built a foundation set of XML procurement schemas upon this specification. In addition, this presentation will explain how such an approach provides the data interoperability benefits which are pre-requisites for successful XML B2B adoption..."
- "ebXML Core Components. The Master Data Dictionary?" By Michael C. Rawlins and from Lisa M. Shreve. April 16, 2002.
- "Organisations Providing Specific Support to the ebXML Core Component Effort." European ebXML Information Centre. 2003-10-21 or later. "Each of the organizations below have committed to submit the business content of their XML payloads as Candidate Core Components to the UN/CEFACT ebXML Core Components:
- UN/CEFACT TBG17 WG (Harmonisation). "Working Group TBG17 (Harmonisation) is responsible for Project P1 — Business Process and Core Components Harmonisation. "The purpose of the project is to take responsibility for ensuring the consistency and harmonisation of Business Process models and Core Components across business domains and sectors by developing a concise and well-defined library of business terms and business data semantic definitions for the structuring of data exchanges in a syntax neutral manner. The scope of this project is the collation of Business Process models and their corresponding definitions of business Core Components, which presents the requirements of cross industry domains in a consistent and analysable manner. Analysis and harmonisation will result in a catalogue, which will form the foundation of the UN/CEFACT Global Business Process and Core Components Library." See the TBG Project 1 Overview and TBG17 Terms of Reference. For details contact Marion A. Royal or Alan Stitzer.
- Open Applications Group Core Components Work Group. "The OAGi Core Components work group is reviewing the existing OAGIS standard in order to add the UN/CEFACT CoreComponentTypes to a future release of OAGIS. Also the group is identifying the larger grained Components or BIEs of OAGIS. These larger grained components are being submitted for inclusion/consideration for the global CoreCompenents that are being proposed by UN/CEFACT." The UBL v1.0 Committee Draft's Appendix G.3.3 ('Common CCTS Schemas') clarifies that the UBL schemas for Core Component Types and Datatypes "were developed in cooperation with representatives of the Open Applications Group, Inc., but the versions currently used by the two organizations are not yet identical. Differences between the CCTS schemas used in UBL 1.0 and OAGIS 9.0 have been identified in these five areas: (1) Naming of Supplementary Components as attributes; (2) Use of XSD normalizedString for code, identifier, and text components; (3) Use of XSD built-in dataypes requiring format Supplementary Components — Date Time, Indicator and Numeric; (4) Restrictions on Binary Object for Graphic, Picture, Sound and Video data type; (5) Patterns for Indicator data type. A common set of CCTS schemas are expected to be available for UBL 1.1 and will be included at that time. This is not expected to affect the validity of UBL 1.0 instances." Contact Project Leader Garret Minakawa (Oracle).
|
 | Receive daily news updates from Managing Editor, Robin Cover.
 |
|
