Developing a common set of federal NDRs

1
Developing a common set of federal NDRs

• Mark Crawford
• Draft
• April 28, 2005

2
Non Controversial versus Valuable

• Every developer has their own perspective on how
  best to create schema
• Non-controversial rules typically add little
  value to any sort of standardization or
  interoperability
• For rules to have value, they must be cohesive
• they must bind together to create an environment
  where a specific set of schema can be developed

3
Focus Areas

• Modularity
• are we going to adopt the generally accepted
  modularity models to maximize reuse
• Common schema by agency
• Common schema for federal government
• Namespaces
• Promulgate a federal namespace strategy similar
  to what LMI has previously proposed
• Versioning
• major/minor
• Element declarations
• local/global
• Attributes
• yes/no/maybe/limited

4
Focus Areas

• Type definitions
• named/anonymous
• simple/complex
• Rules for type compositors
• Naming rules
• Extension/restriction/redefinition/customization
• Code lists as enumerations or modules
• Annotation
• Documentation

5
Issues

• Adoption of W3C XSD as preferred solution
• Processing instructions in schema
• Differentiations between document centric and
  data centric rules
• Role of schematron
• Support for polymorphic processing
• Role of other XML specifications
• Modeling Methodology

6
Sources

• Voluntary Consensus Standards
• OASIS UBL
• UN/CEFACT
• Government Proprietary
• DON
• Global Justice
• EPA
• Others

7
Some Examples Simple Changes

• UBL XML element, attribute and type names MUST
  be in the English language, using the primary
  English American spellings provided in the xx
  version of the Oxford English Dictionary.
• UBL XML element, attribute and type names MUST
  be consistently derived from CCTS conformant data
  element ISO 11179 dictionary entry names.
• UBL XML element, attribute and type names
  constructed from cctsDictionaryEntryNames data
  element ISO 11179 dictionary entry names MUST NOT
  include periods, spaces, other separators, or
  characters not allowed by W3C XML 1.0 for XML
  names.

Text appearing in courier underline would be
deleted Text appearing in red italic font would
be added
8
Some Examples Simple Changes

• A UBL global element name based on a cctsABIE
  object class MUST be the same as the name of the
  corresponding xsdcomplexType to which it is
  bound, with the word "Type" removed.
• A UBL global element name based on an generic
  data element unqualified cctsBBIEProperty MUST
  be the same as the name of the corresponding
  xsdcomplexType to which it is bound, with the
  word "Type" removed.

Text appearing in courier underline would be
deleted Text appearing in red italic font would
be added
9
Some Examples Simple Changes

• For every class identified in the UBL model, a
  named xsdcomplexType MUST be defined.
• A UBL xsdcomplexType name based on an object
  class cctsAggregateBusinessInformationEntity
  MUST be the cctsDictionary Entry Name of the
  class with the any separators removed and ith
  the"Details" suffix replaed wth and the word
  "Type appended.

Text appearing in courier underline would be
deleted Text appearing in red italic font would
be added
10
Some Examples - Modularity

• Concepts redefined
• Some modules renamed
• New agency modules

Reusable ClassModule
Source StandardsModule
11
Some Examples - Namespace Rules

• Every UBL-defined or -used schema module, except
  internal schema modules, MUST have a namespace
  declared using the xsdtargetNamespace attribute.
• Every UBL-defined or -used schema set version
  MUST have its own unique namespace.
• urnununeceuncefactltschematypegtltstatusgtltnamegt
  ltmajorgt.0.ltrevisiongt
• urnusgovdoddonusnlognavsup1.0

Text appearing in courier underline would be
deleted Text appearing in red italic font would
be added
12
Recommended Course of Action

• Pick initial source
• Recommend UBL for NDR
• UN/CEFACT for datatyping schema
• Determine canonical form
• Recommend W3C XSD
• Categorize rules by
• Ability to auto validate
• Ability to auto generate
• Contribution to interoperability
• Support for DRM concepts
• Recommend solutions to issues

13
Recommended Course of Action

• Strip off all modeling methodology aspects of
  rules
• Transform any CCTS constructs to generally
  accepted data element constructs
  (Class/Atributes/Representation/Association)
• Transform modularity to reflect revised data
  element constructs
• Transform namespaces to federal namespace
  recommendation
• Approve draft rules
• Create draft schema and sample instances
• Develop Federal NDR Document