federal xml naming and design rules and guidance: potential next steps ken sallken sall, saic xml...

Federal XML Naming and Design Rules and Guidance: Potential Next

Steps

Ken Sall, SAIC

XML Community of Practice

Presented at NIST

March 15, 2006

2

2

Agenda

• Status: Recent Events and Work Remaining

• Current NDRG Outline

• Code Examples

• Comments Yet to be Addressed

• Significant Assumptions

• Potential Ways Forward

• Strawman XML Schema for NDRG Rules Summary

• Open Discussion

3

3

NDRG Status – Recent Events

• Jan. 14: Sections 1-3 posted.

• Feb. 8: LMI’s responses posted to Mr. Sall’s comments regarding 14 Jan. draft (in the form of modified Sections 1-3)

• Feb. 10: Example XML Schemas and Instances posted to CORE.gov.   

• Feb. 21: Commenter call covering Sec. 1-3.  

• Feb. 22: Sections 4-7 posted.

• Mar. 6: Cease Work Instruction issued by GSA/OPG.

• Mar. 7: Consolidate Comments and Responses to Sec. 4-7 posted; very few “responses” to our comments.

• Sec. 4-7 Commenter call scheduled for Mar. 8 cancelled.

Aside: UN/CEFACT approved their NDR version 2.0 on 7 March 2006.

4

4

NDRG Status (cont.) – Work Remaining

1. Numerous comments yet to be addressed, esp. Sec. 4-7.

2. Which version of Sec. 1-3 to use?

3. Code List Section 6 need lots of work.

4. Generate Table of Contents

5. Appendix A: Federal XML Naming and Design Rules and Guidelines Checklist – see XSD strawman on later slides

– App. B: Approved Acronyms and Abbreviations - governance

– App. C: Metadata Components – redundant

– App. D: Approved Representation Terms - governance

6. Appendix E: Technical Terminology – non-XSD terms

7. Code Examples (see later slides)

8. Maintaining CORE.gov site?

9. Contact Robin Cover to update his NDRG section.

5

5

Current NDRG Outline as of March 6, 2006

1. Introduction (13 pages)

o Purpose

o Scope

o Assumptions

o Audience

2. General XML Constructs (42 pages)

3. Developing Data Element Dictionary Content (12 pages)

4. Developing XML Content (35 pages)

5. Extending and Restricting Types (2 pages)

6. Code Lists and Identifier Lists (4 pages) – very weak yet very important

7. XML Instances (2 pages)

Total Page Count (without front and back matter): 105 pages

6

6

20 Rule Categories (Table 1-1)

Rule prefix token Value

ATD Attribute Declaration

ATN Attribute Naming

CDL Code List

CTD ComplexType Definition

DEN Data Element Dictionary Entry Names and Definitions

DOC Documentation

ELD Element Declaration

ELN Element Naming

GNR General Naming

GTD General Type Definition

GXS General XML Schema

IND Instance Document

MDC Modeling Constraints

NMC Naming Constraints

NMS Namespace

RED Root Element Declaration

SSM XML Schema Structure Modularity

STD SimpleType Definition

STR Standards Requirements

VER Versioning

Are all categories still used?

7

7

Code Examples from 10 Feb.

8

8

Code Examples – Work Remaining

• A README.html would be a good idea, perhaps with a link to each file, describing its purpose or role.

• A diagram that shows the interrelationships among these files would be helpful. For example, what are the dependencies? [among ISO, IANA, UNECE, Federal, DLA]

• The XML instances were generated so they have dummy data. Greater semantic value would be gained by replacing the dummy values with more instance-specific strings, numbers, etc. While this could be tedious, there are only 2 of these and they are small.

9

9

Code Examples – Work Remaining (cont.)

• README.html should explain how the ISO, IANA, and UNECE files do not necessary comply with the NDRG. They do not include the required documentation, it seems. This would be okay as an example of leveraging existing standards without modification.

• Use of xsd:documentation child elements based on (original) CCTS namespace is confusing and inconsistent.

• Other?

10

10

Comments Yet to be Addressed

• Sections 4-7: 101 comments from Mike Grimley, Joe Chiusano, and Ken Sall

• Section 1-3: some comments remain unresolved, since there are two versions of Sec. 1-3.

11

11

Major Objections from IC MWG

Common terrorism-related information sharing standards would not comply because the NDRG:

• Prohibits the use of attributes (crucial to the IC for security markings; already deployed).

• Disparages xsd:choice.

• Prohibits acronym/abbreviation use.

• Prohibits xsd:union need for our date/time extension of the various XSD date/time types.

• Etc.

12

12

Significant Assumptions About Scope

• XML Technologies out of scope

– Addresses only W3C XML Schema (WXS, aka XSD)

– Subset of XML concerned mainly with transaction-based systems

– Ignores DTD, RELAX NG and Schematron

– Ignores DOM, SAX, XSLT, XSL-FO, WSDL, SOAP, XQuery, etc.

• Governance

– Who will enforce with what sanctions?

• Registry

– Central or federated? Who will fund?

– How will element or type conflicts be resolved?

• Security

– How can agencies comply if they must restrict access?

13

13

Potential Ways Forward (not mutually exclusive)

1. Minimal effort: Publish “as is” to wider audience

– Knit together sections, add ToC and Appendices

– What audience? CIO Council’s Architecture and Infrastructure Committee (AIC)? Specific agency CIOs?

2. Solicit volunteers to edit next version (lead editor and assistants)

• Participants will influence justifications, objections, etc.

• Editor and contributors names should appear in final document

3. Ask for funding to complete work. (GSA/OGP? AIC?)

[continued]

14

14

Potential Ways Forward (cont.)

4. Ask AIC to assign oversight committee.

5. Determine Core NDRG rules (absolute MUSTs).

6. Develop XML Schema to represent rules so they can be processed and extracted differently by different agencies.

7. Work with UBL Technical Committee, especially G. Ken Holman and Anthony Coates to develop code list mechanism.

15

15

Why Propose an XML Schema for NDRG Rules?• Ease of processing/filtering via XSLT

– Find all MUSTs and MUST NOTs.

– Find all SHOULDs and SHOULD NOTs.

– Find all rules with no objections.

– Find rules with objections that have no response.

– Find rules with no justifications.

– Find MUST/MUST NOT or SHOULD/SHOULD NOT rules that have exceptions.

– Create rule summary tables by category (since sections mix rules from different categories).

• Eat our own dog food. Make schema an informative example, including xsd:documentation as per NDRG.

16

16

NDRG Rule Schema – Strawman 1

17

17

NDRG Rule Schema – Strawman 1 (cont.)

18

18

Sample Rule Instance (shows 3 rules)

19

19

Sample Rule Instance (cont.)