Federal XML Naming and Design Rules and Guidelines. Mark Crawford

Transcription

1 Federal XML Naming and Design Rules and Guidelines Mark Crawford

2 Agenda Purpose Scope Audience Sources Terminology Modularity Namespaces Versioning Content Next Steps P A G E 2

3 The purpose of this document is to provide a set of rules and guidelines that will enable development of: a flexible federal modularity model that defines the structure for creating interoperable schema and schema modules a clearly defined namespace scheme that ensures consistency across Agencies a versioning scheme that will support consistency in versioning of government schema a Federal canonical schema for base Data Types specific NDR s by government agencies or communities of practice that build on this document a reference to use for a mapping of different agency NDR s to each other P A G E 3

4 The purpose of this document is to provide a set of rules and guidelines that will enable development of: (cont d) consistent, reusable XML components that may be made available for reuse such as: Schema s such as reusable code lists and identifier lists Simple and Complex Types Elements Attributes a set of tools to facilitate ease of development, validation, and interoperability P A G E 4

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

6 Audience (not yet vetted) 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 P A G E 6

7 Sources Voluntary Consensus Standards Bodies OASIS Universal Business Language Technical Committee UN/CEFACT Government NDRs Department of the Navy Environmental Protection Agency Global Justice P A G E 7

8 Terminology The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in Internet Engineering Task Force (IETF) Request for Comments (RFC) 29. Non-capitalized forms of these words are used in the regular English sense. P A G E 8

9 Modularity is key to reuse Modularity Model Must Be: Structured Flexible Consistent P A G E 9

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 0

11 Modularity Model Reuse Approach Root Schema Module Internal Schema Module File W3C XML Schema Type Complex Data Reusable Modules Unqualified Data Type Module Other Standards Body Modules.. * Qualified Data Type Module Namespace Identifier List Module Code List Module Simple Data Module P A G E

12 Modularity Model Root Schema Message Assembly Single Namespace Root Include Internal Schema Module(s) Import Import Import External Standards Body Reusable Entities Schema Module Other External Reusable Entities Government and Source Standards Body Schema External s Individual Namespaces A Root Schema is a single concept like an Order, Invoice, OMB 300, SF2, Document, Book, or some other logical grouping of information. P A G E 2

13 Modularity Model Importing Data Types From Standards UBL and other standards bodies are converging on UN/CEFACT Data Type schema modules Message Assembly Single Namespace Internal Schema Module(s) Root Include Import Import Import External Standards Body Reusable Entities Schema Module Other External Reusable Entities UBL and other standards bodies are converging on single approach to code lists Source Standards Unqualified DataType Source Standards Qualified DataType Identifier List (IL) (s) Code List (CL) (s) External s Individual Namespaces P A G E 3

14 What Data Types Amount (xsd:decimal) Binary Object (xsd:base64binary) Graphic Sound Video Code (xsd:normalizedstring) Date Time (xsd:datetime) Date (xsd:date) Time (xsd:time) Identifier (xsd:normalizedstring) Indicator (xsd:boolean) Measure (xsd:decimal) Value Rate Percent Numeric (xsd:decimal) Quantity xsd:decimal) Text (xsd:string) Name (xsd:string) P A G E 4

15 A Data Type Example <xsd:complextype name="amounttype"> <xsd:annotation> <xsd:documentation> <Component> <ComponentType>DT</ComponentType> <DictionaryEntryName>Amount. Type<:DictionaryEntryName> <Definition>A number of monetary units specified in a currency where the unit of the currency is explicit or implied.<definition> <RepresentationTerm>Amount</RepresentationTerm> </Component> </xsd:documentation> </xsd:annotation> <xsd:simplecontent> <xsd:restriction base="cct:amounttype"> <xsd:attribute name="amountcurrencyid" type="xsd:normalizedstring" use="required"/> <xsd:attribute name="amountcurrencycodelistversionid" type="xsd:normalizedstring" use="optional"/> </xsd:restriction> </xsd:simplecontent> </xsd:complextype> P A G E 5

16 Modularity Model Introducing the Federal Common Schema Reusing the Standards Body Schema Creating 4 Federal Enterprise Schema Unqualified DataTypes Message Assembly Single Namespace Internal Schema Module(s) Root Include Import 4..* Import Import External Standards Body Reusable Entities Schema Module Other External Reusable Entities Qualified DataTypes Complex Data Element Reusables Address Federal Qualified DataTypes (FQDT) Federal Complex Data Elements Person Organization Simple Data Element Reusables Federal Unqualified DataTypes (FUDT) Federal Simple Data Elements First Name Last Name Birthdate Source Standards Unqualified DataType Source Standards Qualified DataType Identifier List (IL) Code List (CL) Schema Schema Module(s) Module(s) Code and Identifier Lists External s Individual Namespaces P A G E 6

17 Flexibility for Everyone Government organizations and initiatives can leverage standards body and federal schema Organizations can create organizationally unique Qualified and unqualified Data Types Complex Data Element reusables Simple data element reusables Code Lists Identifier Lists Message Assembly Single Namespace Federal Qualified DataTypes (FQDT) Federal Unqualified DataTypes (FUDT) Source Standards Unqualified DataType Internal Schema Module(s) Federal Complex Data Elements Federal Simple Data Elements Root Source Standards Qualified DataType Include Import Agency Complex Data Elements 0.. Agency Simple Data Elements External s Individual Namespaces 4..* Import Import Agency Supplemental Qualified DataTypes (ASQDT) Schema Module Agency Supplemental Unqualified DataTypes 0.. (ASUDT) Identifier List (IL) Code List (CL) Schema Schema Module(s) Module(s) External Standards Body Reusable Entities Schema Module Other External Reusable Entities Note: relationships between shcema modules in different namespaces are xsd:import P A G E 7

18 Namespaces Initial Recommendation Mandate hierarchical URN scheme Consensus SHOULD use URN and hierarchy scheme. MAY use URL hierarchy scheme P A G E 8

19 Namespaces st Level Domain NID of US Second Level Domain Organization Hierarchy. In this case GOV Third Level Domain Specific Government Hierarchy EPA, OMB, DoD, Treasury Fourth Level Domain Agency Level Hierarchy USN, USAF, IRS, FMS Fifth Level Domain Resource Type Schema or Other as Identified Sixth Level Domain Resource Status Seventh Level Domain Resource Name P A G E 9

20 Versioning Consensus on: <name>-<major >.<non-zero>[.<revision>] To be determined: Minor versioning of namespaces Use of namespaces for schema location URN or URL for schema location P A G E 20

21 Schema Content Modularity, Namespaces and Version is important, But: What about the Schema Content? P A G E 2

22 Schema is All About Data Data Concept Entity Relationship Diagram Data Model ISO 79 Data Element Classification Structure Entity (Type) Object Class Data Element Concept Attribute (Type) Property Representation Generic Data Element Data Element (Type) Source: ISO 79 Source: ISO 79 P A G E 22

23 Transforming Data to XML Simple XSD Transformation Entity Relationship Diagram Data Model Entity (Type) ISO 79 Data Element Classification Structure Object Class Global Element/ xsd:complextype Property Global Element/ xsd:complextype Attribute (Type) Representation xsd:complextype or xsd:simpletype P A G E 23

24 Handling Class Associations An associated class is treated as a simple data element with a global element declaration and complex type definition P A G E 24

25 Next Steps Continue to work through comments to first draft Finalize modularity Finalize versioning Finalize namespace Flesh out content P A G E 25