Federal XML Naming and Design Rules and Guidelines

Paul Macias

P A G E 2

Agenda

• Scope & Audience

• Hierarchy

• Governance

• Namespaces

• Versioning

• Schema Structure

• Content Models

• Next Steps

P A G E 3

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

P A G E 4

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.

P A G E 5

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

P A G E 6

Standards Hierarchy

XML Standard Components. It is Federal policy to 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 Standards

(3) Federal-level enterprise standards(4) Federal-level cross functional and functional initiative

standards (such as multi LOB, LOB, e-gov, community of practice) (use e-gov as an example)

(5) Department/Agency level enterprise standards

VCS

Federal

Agency

P A G E 7

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.

P A G E 8

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

P A G E 9

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

P A G E 10

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 11

Modularity Model

• Reuse for the Federal Enterprise Schemas

– Unqualified DataTypes

– Qualified DataTypes

– Complex Data Element Reusables

– Simple Data Element Reusables

• Agencies will be advised to use reuse, but may adopt another model

Root Schema Module

Internal Schema Module(s)

Message Assembly –

Single Namespace

External Schema Modules – Individual Namespaces

Federal Simple Data Elements

Schema Module

FederalComplex Data

Elements Schema Module

Federal Unqualified DataTypes (FUDT) Schema Module

Federal Qualified DataTypes (FQDT)

Schema Module

Source Standards Unqualified DataType

Schema Module

Code List (CL) Schema

Module(s)

0..*

0..*

0..*

1

0..*

1

1

Identifier List (IL) Schema

Module(s)

1

1

0..*

0..* 0..*

1 1

1

4..*

1

Source Standards Qualified DataType

Schema Module

10..*

0..* 0..*0..*

0..*

1

Include

Import

External Standards Body Reusable Entities Schema

Module

Other External Reusable Entities Schema Module

0..*

0..*

Import

Import

P A G E 12

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 13

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 14

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 15

Next Steps

• Producing a Second Draft (Oct. 19)

• Submit to Emerging Technologies Subcommittee