1. Federal XML Naming and Design Rules and Guidelines Paul Macias

2. P A G E 2 The Situation Document needs to be updated to reflect decisions of September meeting –Implemented Scope, Purpose, and Audience decisions –Need text to touch on governance, security, and definition of minor version –Need adjust some rules to reflect meeting decisions on applicability to agencies –Need to improve section describing modular approach –Need to distinguish structure requirements for different types of schema Biggest need is for contextual explanation of rules and examples

3. P A G E 3 Background Slides From September XML CoP Meeting

4. P A G E 4 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

5. P A G E 5 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.

6. P A G E 6 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

7. P A G E 7 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

8. P A G E 8 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.

9. P A G E 9 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

10. P A G E 10 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

11. P A G E 11 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

12. P A G E 12 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

13. P A G E 13 Namespaces Eliminating minor versioning of namespaces from 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

14. P A G E 14 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

15. P A G E 15 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