"Naming and Design Rules and Guidelines - Status Update"
Federal XML Naming and Design Rules and Guidelines Paul Macias Agenda • Scope & Audience • Hierarchy • Governance • Namespaces • Versioning • Schema Structure • Content Models • Next Steps PAGE 2 Tweaked Scope & Audience • Scope – Removed instances of “all” that could lead readers to think that rules were mandatory for every circumstance. Seemed to override the optionally aspects of the NDRG. • Audience – Clarified the applicability to developers supporting agencies PAGE 3 Scope This Federal XML Naming and Design Rules and Guidelines document is intended for use by Executive Branch Departments and Agencies (hereinafter referred to as Agency) that employ XML, including commercial and government off-the-shelf XML related product implementations. It should be used by 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. PAGE 4 Audience • Developers of Federal Enterprise Schema – Those that will achieve federal enterprise status • Developers of Agency Schema and Government organizations looking for guidance – Agency level development not intended for federal • Agency level developers interested in fostering interoperability – Agency level development not initially intended for federal but wanting to position for the future possibility • Private sector organizations who wish to track or support government efforts PAGE 5 Standards Hierarchy XML Standard Components. It is Federal policy to VCS use existing XML components when practical, as opposed to developing new XML components. When selecting existing components, Federal Agencies should adhere to the following order of precedence (highest to lowest): (1) Appropriate Horizontal Business Voluntary Consensus Standards (2) Appropriate Vertical Business Voluntary Consensus Federal Standards (3) Federal-level enterprise standards (4) Federal-level cross functional and functional initiative Agency standards (such as multi LOB, LOB, e-gov, community of practice) (use e-gov as an example) (5) Department/Agency level enterprise standards PAGE 6 Standards Hierarchy Principles • Adopt Solutions from Highest Level – Reuse solutions that already exist in higher levels of the hierarchy. • Promotion to Higher Standards – Lower levels of the hierarchy are encouraged to promote development of solutions to their requirements at the highest appropriate level. (i.e. participate in VCS standards) • Extension of Higher Standards – Extend from higher standards for requirements that are not in the domain for higher level standards to address. PAGE 7 Standards Hierarchy Principles • Business Standards – Addresses components for business areas • UBL Library • UN/CEFACT Library • Technical Standards – Addresses more of the infrastructure • XML 1.1 • SOAP PAGE 8 Governance Principles • Will distinguish between governance of the NDRG and governance of standards. • Assumes a governance structure similar to FESMC for EDI will manage components – Agencies may decide to organize oversight of components along common business areas, such as finance or materials management • A run-time registry should be available to store the components PAGE 9 Modularity • Three Approaches under consideration – Monolithic • Single Namespace • One schema per process, idea, or information requirement • No imports – Reuse • Root Schema with all content imported • Unique namespace for each schema • Common modules for reusables (data elements and generic data elements), standard data types, code lists, identifier lists – Unique • Root Schema with all content imported • Unique namespace for each schema • Unique schema modules for each data element i.e. an address would be a stand alone schema in a unique namespace P A G E 10 Modularity Model • Reuse for the Federal Enterprise Message Root Schema Module Schemas Assembly – 0..* External Standards Body Reusable Entities Schema Single Include Import Module – Unqualified DataTypes Namespace 0..* Import Other External Internal Schema Import 0..* Reusable Entities – Qualified DataTypes Module(s) Schema Module 4..* – Complex Data Element Reusables – Simple Data Element Reusables Federal Federal Qualified 1 Complex Data 1 • DataTypes (FQDT) Agencies will be advised to use Schema Module 1 Elements Schema Module reuse, but may adopt another model 1 1 1 1 Federal Unqualified Federal DataTypes (FUDT) Simple Data Elements 1 Schema Module Schema Module 1 0..* 0..* Source Standards Source Standards Identifier List (IL) Code List (CL) Unqualified DataType 1 Qualified DataType 0..* Schema 0..* 0..* Schema Schema Module Schema Module 0..* Module(s) Module(s) 1 0..* 0..* 0..* 0..* 0..* External Schema Modules – Individual Namespaces P A G E 11 Namespaces • Eliminating minor versioning of namespaces fro reuse model – Reflects similar leaning in other standards bodies – Dependent on a defining and enforcing what is a “minor” change • If a change does not affect backwards compatibility, then it is a minor change and will not require the namespace to be versioned P A G E 12 Data Structures • Reviewing proper presentation of copyright notices – Example followed from OASIS puts a copyright at the beginning and end of the schema. – Not a mandatory aspect of structure, but verifying what is correct if one is used • Clarifying which aspects of the data structure are mandatory/optional for each type of schema P A G E 13 Document Centric Schema Structure • Example: schemas for tech publications • Will apply a portion of data centric rules to defining document centric schema to foster a similar, minimal level of structure for document centric schemas • Need to consider if document centric schemas should be registered and managed under the same rigor as data centric schemas • Leads to similar registration questions about other types of XML such as XSL-FO P A G E 14 Next Steps • Producing a Second Draft (Oct. 19) • Submit to Emerging Technologies Subcommittee P A G E 15