What Label and Concept Do We Use To Construct XML Tag

1
Proposal The Establishment of a Task Force
within the SHADE Namespace community to address
the challenges of the DoD Enterprise
Mike Lubash 703.607.1166 Mike.Lubash_at_DFAS.mil XML
Team Leader DoD Finance and Accounting Namespace
Manager
2
Agenda

• Background DFAS XML Principles
• - Stakeholders have a choice - multiple sets of
  standards
• - DFAS endorses SHADE as the mechanism to achieve
  interoperability
• - XML development tenets
• Share lessons learned
• - Issues uncovered
• - Share few key XML constructs
• - Address artifact candidate to resolve design
  issues
• Are these good constructs?
• - Call for Task Force to address issues - no pun
  intended

3
DFAS XML Principles
Choice All of DFAS stakeholders have a choice
and we cannot control what they choose.
There will always be multiple standards and
implementations
We need to build a management mechanism flexible
to support the mission...
1. Register We will register all XML tags that
are used by DFAS
applications in the DoD SHADE XML Registry.
2. Alignment Come to agreement - from both
physical and concept levels
4
Delivering Business Value
Alignment
Register
Phase 1
Phase 2
Relationships
Registered Entity
Maximum Payback
1
2
3
4
5
6
Collect
Connect
Communicate
Correlate
Contract / Choose
Catalog
5
DFAS XML Development Tenets
1 - Work within SHADE on Alignment (Phase II)
issues
2 - Public interface centric
3 - Mission Requirements - Align with similar
programs / stakeholders (Business and
Technical)
4 - DoD Architecture-centric - Align DoD
Architecture concepts to many different
physical implementations (map) - CADM (Core
Architecture Data Model) as exists de-emphasizes
Finance Accounting support role i.e.
Fund is not in CADM
5 - Take the past forward - support legacy
environment (map)
6 - Development is business case sponsored and
customer-focus
6
Share Lessons Learned
7
Challenges Questions of XML Design Alignment

• Scope
• - Standards DOD, Federal Government, North
  America, Global
• - Standard/Tool Support just because one can
  use the specification to author a schema doesnt
  mean that tools can interpret the schema or if it
  works effectively at runtime
• Business Layer
• - Dilution of Constraints mandatory become
  optional
• - Varying Granularity resolution differs
  depending on application
• - Codelist reuse yet subset domain values
  between communities
• Registry help from above
• - Multi-field Dependencies no validation
  for dependent elements/attributes
• - Versioning create schema and systems
  that understand change management

8
Versioning
ltSFC xsinoNamespaceSchemaLocationDSFC\XML\SFC
_0_02.xsdgt ltTreasuryCode versionId0.02gt
2. Libraries / Files
1. Roll per logical unit / component (UID)
Versioning at the XML Instance
9
XML Provides Greater Structure and Varying Types
We can take great advantage of the ability to
hold any type and structure we can include
metadata for describing this...
UID
Classword
Legacy
10
Expand DoD Classwords to Accommodate XML
Structures
Classword
Three additional classwords to assist in
describing XML tree structure
11
Classword Details Collection of differing types
to describe a concept or logical unit.
One concept
Different attributes / types
The least restrictive of the three
12
Classword Set Collection of children that are
of same type - equivalent to a rowset query
result from a relational database.
ltRowSetgt ltRowgt ltValuegt3lt/Valuegt ltTitl
egtLibrary of CongressltTitlegt lt/Rowgt
ltRowgt ltValuegt4lt/Valuegt ltTitlegtGovernment
Printing ValueltTitlegt lt/Rowgt lt/RowSetgt
Repeating Group
13
Classword Choice Where the tree branches for
different child types (structures) or differing
default values.
Schema
Instance
A
B
Selected
B
C
D
The most restrictive of the three
14
UID
SHADE Registry
VI304
Dollars
Collaboration Partner 1
Collaboration Partner 2
X12
UnitPrice
EDIFACT
ListPrice
Currency
ltRep href http//www.SHADE.milgtSHADElt/Repgt
ltELEMENT nameListPrice uid VI304 gt
Schema or Template
ltRep href http//www.SHADE.milgtSHADElt/Repgt
ltELEMENT nameUnitPrice uid VI304 gt
Schema or Template
XML Instance
XML Instance
Data
ltListPricegt9.99lt/ListPricegt
ltUnitPricegt9.99lt/UnitPricegt
ltCurrencygtlt/Currencygt
UIDs allow for domain crosswalks and light
transactions
15
Multi-field Requirements
1. Linking additional information, i.e. code list
2. Multi-fields to describe additional structure
based on choice
Case 1
ltName DoDclassWord"Name"gtManagement
Consolidated Working Fundslt/Namegt
Case 2
Just like relational databases, when serializing
data we lose important linkage information which
we usually document via a paper trail. It would
be nice to have a better mechanism.
16
Multi-field Requirements - help from above
In addition to enumeration, we include a
reference to a Registry.
DCR
17
Address Artifactcanary in a coal mine

• Resolve Impediments, Architectural and Design
  Issues

18
Address (4 approaches)

• "DDDS XML"
• Mix-n-match
• Pick-n-choose
• Dual resolution

19
"DDDS XML"
Modeled directly from DDDS addressing the
requirements of the DoD and the DoD only.
20
Mix-n-Match
Intermeshing elements from different standards
(HR-XML, AR/AP, qbXML, "DDDS XML") into one
schema by mapping.
Elements from multiple standards intermeshed/mapp
ed
21
Pick-n-Choose
From the root element, allowing the possibility
of choosing one of several standards (HR-XML,
AR/AP, qbXML, "DDDS XML") and populating just the
subtree of the chosen standard.
22
Dual-Resolution
Creating elements to account for the superset of
all elements from a set of chosen standards
(HR-XML, AR/AP, qbXML, and "DDDS XML"). High and
low resolutions are made available for elements
where applicable.
Low Resolution
High Resolution
23
Dual-Resolution (contd.)
The following depicts how we can handle the
challenge of exposing two levels of resolution
1. Simple PrimaryText
ltPrimaryTextgt1931 Jefferson Davis Hwy, CM-3, Room
315lt/PrimaryTextgt 2. More fielded with
PrimaryTextDetails
Global
ltPrimaryTextDetailsgt ltPrimaryTextgt1931
Jefferson Davis Hwy, CM-3, Room 315
lt/PrimaryTextgt ltStreetNumbergt1931lt/StreetNum
bergt ltStreetNamegtJefferson Davis
Hwy.lt/StreetNamegt ltBuildingIDgtCM-3lt/Building
IDgt ltSuitegt315lt/Suitegt lt/PrimaryTextDetailsgt
Local
24
Tradeoffs

• "DDDS XML"
• Exclusionary (DoD-only thinking)
• Limited scope
• Mix-n-match
• Quickly becomes very complex for developers
• Too many confusing decisions for users
• Pick-n-choose
• Many standards (which to include?)
• Complex mappings on the backend to a potential
  RDBMS
• Dual-Resolution
• Addresses high and low ends of complexity
  spectrum but leaves out the middle

25
Summary

• We as namespace managers need to make sure SHADE
  is in position to provide DoD enterprise
  alignment to support to our business cases.
• - We need to build mechanisms that can record
  entities and handle relationships to multiple
  entries/standards
• - We need to capture rationale alignments at
  business and technical levels
• Call for a task force to address critical phase
  II (Alignment) issues
• - Continue work to flesh out solutions to
  challenges introduced in this presentation
• - How do we build on established DoD
  architecture models? How do we deal with the
  quality of the DDDS (Defense Data Dictionary
  System)?
• - Define enterprise core components, instances
  such as Address, person, organization, etc. and
  develop the Namespace procedure for dealing
  with any issues raised

26
Thank you
If it isnt used, it isnt a standard