Six

Implementing XML Guidelines for
the Integrated Acquisition

Environment (IAE) & eTravel
Presented to the
CIO Council XML Working Group
June 16, 2004
Ken Sall
(ksall@SiloSmashers.com)
Copyright © 2004 Kenneth B. Sall. All Rights Reserved.
Outline
 Federal XML Guidance Sources:

– FEA, CIOC, DON, EPA
 International Guidance Sources:

– ISO 11179, ebXML Core Components, and UBL
 Data Normalization for the eTravel Service
 ISO 11179/Core Component/UBL Modeling for the

Integrated Acquisition Environment
 CORE.gov Registry and Repository
 Summary and Conclusions
2 Copyright © 2004 Kenneth B. Sall. All Rights Reserved.

Federal Enterpise Architecture (FEA)
Business and Performance-Driven Approach
Performance Reference Model (PRM)

• Inputs, Outputs, and Outcomes
• Uniquely Tailored Performance Indicators
Interoperability / Information Sharing

Business Reference Model (BRM)
• Lines of Business
(Business-Context Driven)
• Agencies, Customers, Partners
Service Component Reference Model (SRM)

• Service Domains, Service Types
• Business and Service Components
Data and Information Reference Model (DRM)

• Subject Areas, Classifications, Data Elements,
• Data Properties, Data Representations
Technical Reference Model (TRM)

• Service Component Interfaces, Interoperability
• Technologies, Recommendations
3 Source:
Source:FEAPMO.gov
FEAPMO.gov
Federal XML Guidance Sources
 CIO Council, XML Working Group, “XML Developer’s Guide” [draft,
dated April 2002]:
http://xml.gov/documents/in_progress/developersguide.pdf
 DON XML Working Group, “XML Developer’s Guide”, Version 1.1 [dated
May 2002] and related material [See “Library” and then “Developer’s
Guide”; guide contains a very useful glossary; library includes a useful
three-page XML Schema checklist] [TBD – link is broken ]
https://quickplace.hq.navy.mil/quickplace/areatypes/navyxml/main.nsf
 EPA’s “XML Design Rules and Conventions for the Environmental

Exchange Network” [dated September 2003]. This long and
comprehensive two-part document presents many XML design issues,
contains a helpful “Summary of XML Rules” (Appendix A), and covers
several issues that are unresolved as of this writing:
– http://www.exchangenetwork.net/documents/XML_DRC_Section_1.pdf
– http://www.exchangenetwork.net/documents/XML_DRC_Section_2.pdf
 “Recommended XML Namespace for Government Organizations” [dated

August 2003] – This guidance is controversial:
http://xml.gov/documents/completed/lmi/GS301L1_namespace.pdf

International Guidance Sources
 JTC 1/SC 32 ISO/IEC 11179: Information technology --
Specification and standardization of data elements -- Part 5:
Naming and identification principles for data elements
 UN/CEFACT Techniques and Methodologies Group:

ebXML Core Components
– ebXML Adoption Update as of Dec. 2003
 OASIS Technical Committee: Universal Business Language

(UBL), Version 1.0 (OASIS “Committee Draft”, May 2004)
– UBL: A Lingua Franca for Common Business Information
– UBL Reader , the free UBL variant of GEFEG EDIFIX
 Other eGovernment Sources: UK, Hong Kong (common schema

), Denmark, Germany, New Zealand, etc. Some mature
implementations.

ISO 11179: Data Element Naming
 Consider these ISO 11179-based element names:
– Employee Last Name
– Payment Card Expiration Date
– Tree Height Measure
– Cost Budget Period Total Amount
 Object Class - objects that share the same attributes,

operations, methods, relationships, and semantics (e.g.,
Employee, Payment Card, Tree, Cost)
 Property Term – property that the data element represents

(e.g., Last Name, Expiration Date, Height, Total)
 Representation Term – basic data type (e.g., Text [for Name],

Date, Measure, Amount, etc.)
 Object Class and Property Term can have Qualifiers (e.g.,

Budget Period)
[Object
[ObjectClass
ClassQualifier]
Qualifier]++Object
ObjectClass
Class++[Property
[PropertyTerm TermQualifier]
Qualifier]++Property
Property
6 Term
Term++Representation
RepresentationTerm Term
UN/CEFACT Core Components (ebXML)
 Methodology for developing a common set of

semantic building blocks that represent the general
types of business data in use today and provides for
the creation of new business vocabularies and
restructuring of existing business vocabularies.
 Core Component Type – basic concept without any

business context (e.g., Quantity)
 BIE – Business Information Entity = Core Component

with business context (e.g., Quantity Shipped)

UN/CEFACT ebXML Core Components
 ABIE – Aggregate BIE; several related BIEs (e.g.,

Address [consists of BIEs for Street, City, State,
Zip, etc.]); relates to Object Class
 ASBIE – Association BIE; represent relationships

between 2 or more Object Classes (e.g., Work
Address, Home Address, Shipping Address)

Core Components Documents
 Approved Documents
– UN/CEFACT - Core Component Technical Specification Version 2.01 (2003
– UN/CEFACT TMG - General Document Download Section [

http://www.untmg.org/doc_tmg.html]
– UN/CEFACT - Modeling Methodology - Meta Model - Revision 12 (2003-01-17)
– UN/CEFACT - UMM User Guide Revision 12 (2003-09-22)

– ebXML - Business Process Specification Schema v1.10 (2003-10-18)
– ebXML - Business Process Specification Schema v1.01 (2001-05-11)
 Documents for TMG Review (not for implementation)

– CC User Guide V20031030 Revision 10A

UBL Technical Committee
 OASIS Universal Business Language TC includes link to the UBL

1.0 release and downloadable documents.
 Goal: to develop a standard library of XML business documents

(purchase orders, invoices, etc.) by modifying an already existing
library of XML schemas to incorporate the best features of other
existing XML business libraries.
 The TC will then design a mechanism for the generation of context-

specific business schemas through the application of
transformation rules to the common UBL source library. UBL will
become an international standard for electronic commerce freely
available to everyone without licensing or other fees.
 Highly recommended intro: Eve Maler’s "XML for e-Business"

[July 2003; tutorial on UBL, Core Components, and ISO
11179]
http://www.ibiblio.org/bosak/ubl/tut/csw-xml-for-ebusiness.ppt
10 Source:
Source:OASIS
OASIS
UBL: A Lingua Franca for
Common Business Information
 “UBL is designed to facilitate data interchange between entities that
may not use common vertical industry vocabularies. A good example
might be a scenario involving an electronic equipment manufacturer, a
hospital, and a chemical supplier.”
 “Rather than adopt each of the vertical industry vocabularies, the

hospital could eventually conduct business within healthcare in HL7
and all others in UBL...UBL could be the interchange to each of the
many formats an organization may interact with. “
11 Source:UBL:
Source: UBL:AALingua
Lingua Franca
Francafor forCommon
CommonBusiness BusinessInformation
Information
Selected UBL Sub-Committees
* Code List SC - Create "standard" and "stock" code lists, and template
http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-clsc
* Library Content SC - Library of BIEs, Schema, examples, customization
http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-lcsc
* Naming and Design Rules SC - Rules for Schema design and element naming
http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-ndrsc
Forms Presentation SC - Formatting Specifications
http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-fpsc
Implementation SC - Collate issues discovered during implementation phase
http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-isc
Tools and Techniques SC - Utilities such as spreadsheets and scripts
http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-ttsc
GSA's
GSA'sMarion
MarionRoyal
Royalisisco-chair
co-chairof
ofLibrary
LibraryContent
ContentSC.
SC.
12 LMI's
LMI'sMark
MarkCrawford
Crawfordisisco-chair
co-chairof
ofNaming
Naming&&Design
DesignRules
RulesSC.
SC.
UBL NDR: Naming and Design Rules
 Long checklist of Do's and Don't for moving from

BIE/ASBIE/ABIE to XML Schema.
 Rules are in flux.
 Some rules are debatable (e.g., xsd:choice not

allowed) or perhaps context-specific.

UBL Code Lists
 Clever but complicated mechanism for creating

separate XML Schema for each code list (e.g., Country
codes, FIPS codes, etc.)
 Goal is for standards organizations such as ISO and

NIST to take ownership of these XML Schema.
 Everyone else "includes" the code list schema they

need without worrying if it's up-to-date.
 For example, IAE might designate itself as maintainer

of U.S. procurement-related code lists.

eTravel eGov Initative
 In fiscal year 2001, agencies processed roughly 2.4 million employee
travel vouchers totaling over $9 billion.
 GSA’s eTravel Initiative “[p]rovides a government-wide web-based

service that applies world-class travel management practices to
consolidate federal travel, minimize cost and produce superior
customer satisfaction. The eTravel Service will be commercially hosted
to minimize technology costs to the government and guarantee
refreshed functionality.”
 “From travel planning and authorization to reimbursement, end-to-end

service will leverage administrative, financial and information
technology best practices to realize significant cost savings and
improved employee productivity.”
 Three 10-year contracts—worth $450 million combined—are expected

to cut federal travel management costs by as much as 50 percent.
 12/23/03: FTR Amendment requiring agencies to complete adoption of

eTS by September 2006.
 Sites (multiple vendor award):

– http://www.govtrip.com/govtrip/site/index.jsp (Northrop Grumman Mission Systems (NGMS))
– http://cwgt.com/default.asp (Carlson Wagonlit Government Travel, Inc. (CWGT))
– http://www.fedtraveler.com/ (Electronic Data Systems Corp. (EDS) )
eTravel Data Modeling Process
 Started with 40 poorly defined elements in the Federal Travel Regulations (see
“Appendix C to Chapter 301—Standard Data Elements for Federal Travel”).
 Focus on U.S. Federal travel, not on international harmonization.
 Given 3 months (10 man months) to complete work due to RFP schedule.
 Data call responses received from 17 of the 24 BRM agencies.
 Identified 385 elements (279 for exchange, 106 for data warehouse).
 Arranged elements into “groups” (e.g., Official Duty Station) and larger functional
“categories” (e.g., Traveler Profile), analogous to XML Schema complex types and
schema, respectively.
 Worked with agencies to normalize names. NOTE: Did not follow ISO 11179.
 Published results as GFI via an attachment to the eTravel Service RFP on
FedBizOpps: “to provide eTravel Service offerors with details concerning the
standard data elements identified to date by the Government as needed across
agencies for exchange between eTS and agency business systems. The goal is to
create a standard data set for input and output that is common across agencies,
making it easier and less costly for agencies to integrate with the eTS.”
 Multiple awards; 3 vendors delivering XML Schema based on our attachment.
 Hope to eventually align with non-profit OpenTravel Alliance.

eTravel Data Modeling Spreadsheet

eTravel XSD Evaluation Criteria

Integrated Acquisition Environment (IAE)
 The Federal government spends roughly $190 billion to $220 billion on
the acquisition of goods and services each year, making it the largest
purchaser in the world. There are over 315,000 vendors registered in the
Central Contractor Registration (CCR) system.
 GSA’s Integrated Acquisition Environment (IAE) E-Government initiative

is creating a secure business environment that facilitates and supports
cost-effective acquisition of goods and services in support of agency
mission performance.
 Common acquisition functions that benefit all agencies, such as the

maintenance of information about suppliers (e.g., capabilities, past
performance histories) are managed as a shared service.
 Associated web sites include:

– www.BPN.gov
– www.ICD.gov [new: Interagency Contract Directory]
– www.EPLS.gov
– www.FedBizOpps.gov
– www.FedTeDS.gov
– https://www.FPDS.gov
– www.PPIRS.gov
– www.WDOL.gov
IAE Business Areas and Standard
Transactions
 IAE is composed of 4 business areas:
– Business Partner Network (BPN)
– eMarketplace
– Intra-governmental Transactions (IGT)
– Acquisition Information Reporting (AIR)
 Objective of Standard Transactions is to develop a Standard

Vocabulary to facilitate exchange of data between and within agencies.
 In October 2003, the PMO (Program Management Office) published

initial definitions of Standard Information Exchanges and
Standard Vocabulary based on an analysis of the existing interfaces for
five of the shared IAE systems:
– CCR (Central Contractor Registration),
– FPDS-NG (Federal Procurement Data System Next Generation),
– PPIRS (Past Performance Information Retrieval System),
– IGT (Intra-governmental Transactions), and
– FedReg (Federal Registration).
 A primary goal is to maximize interoperability with other agency,

federal lines-of-business, and external (industry, state and local,
international) vocabularies.

IAE Conceptual Architecture (partial)

IAE Data Modeling Process
 The process used in defining the IAE Standard

Vocabulary is based on the general approach
outlined in the FEA DRM:
– Data modeling using UML (Unified Modeling Language)
– ISO/IEC 11179 data element naming
– UBL and UN/CEFACT Core Component principles.
– Followed by XML Schema development to define the precise structure
of Information Exchange payloads.

IAE Data Modeling Process [cont]
 The data modeling and naming process results in Business
Information Entities (BIEs), which are data elements with a
business context.
 An Aggregate Business Information Entity (ABIE) is a

collection of related pieces of business information that
together convey a distinct business meaning in a specific
business context. Expressed in modeling terms, it is the
representation of an Object Class, in a specific business
context.
 In XML Schema, an ABIE becomes a complex type (e.g.,

ContactInformation). Ultimately, modular transactional and
validation XML Schema will result from combining the ABIEs
into Information Exchanges. Back office and agency systems
can then apply XSLT stylesheets to map their data elements to
or from the IAE Standard Vocabulary.

IAE Data Modeling Process [cont]
 For Information Exchanges, an IAE-specific process was used.
 Procurement SMEs identified 73 Information Exchanges that

encompassed all steps in the acquisition process (to date).
 Of these, 33 Information Exchanges apply to the IAE Portal IOC.
 Particular Information Exchanges were then associated with

specific shared systems.
 Data elements were associated with the exchange as Sent,

Received, Both, or Neither.
 Information Exchanges with their designed data elements were

then reviewed by SMEs.
 Normalized ISO/Core Component/UBL element names were then

substituted for the system-specific data element names.

Result: IAE Standard Vocabulary
 Version 1.0 – 9/31/03

– Data Call in Early 2003
– 450 data elements
– 5 shared systems (CCR, FPDS-NG, PPIRS, FedReg, IGTE)
– Early UBL 0.7
 Version 2.0 – 6/30/04

– Data Call in March 2003
– 1,300 data elements
– All 20 shared systems
– UBL 1.0 (Committee Draft)
– 33 Information Exchanges for 4 shared systems in Portal IOC

IAE XML Implementation Questionnaire
1. Which XML standards have you selected for project use?
2. Which international standards do you support?
3. Explain briefly how you decide on the XML element names used in your system. How do they
relate to business names?
4. Describe briefly the case convention you follow when naming XML elements.
5. Do your XML elements include acronyms and abbreviations? If so, how do you decide which
acronyms and abbreviations will be known to all of your business partners?
6. Is your XML fully documented, especially with comments or annotations in XML Schema, with
appropriate headers, etc.?
7. Are you using XML Schema or DTDs for your data models?
8. To what degree do you use attributes? How do you decide whether to make something an
attribute vs. an element?
9. To what extent do your XML Schema use global type and element definitions vs. local
definitions?
10. How do you represent code lists (enumerations) in your XML?
11. How do you constrain data values to a range?
12. What is the XML namespace you have defined for your system? What other namespaces do
you use?

IAE Summary XML Guidance
 Published by the IAE Program Management Office in August

2003 and updated February 2004.
 The purpose of the document is to provide summary guidance

concerning the use of XML technology for the IAE eGov
initiative. The goal is to highlight the key points from the major
references and Web sites that XML developers should consult
for federal guidance and governance.
 Since this document is a high level summary, it is assumed

that, whenever necessary, developers will refer to the sources
listed at the end of the document for more authoritative and
definitive information and governance.

IAE Summary XML Guidance
Purpose
Guidance Areas
1. Selecting XML Standards for Project Use
2. Importance of International Standards
3. Creating ISO 11179 Names
4. Creating XML Element Names from Business Terms
5. Case Conventions
6. Usage of Acronyms and Abbreviations
7. Adding Comments and Metadata
8. When to Use XML Schema vs. DTDs
9. Schema Development Methodology
10. When to Use Attributes vs. Elements
11. Global vs. Local Elements and Attributes

IAE Summary XML Guidance [cont]
12. Enumeration of Data Values (Code Lists)
13. Constraining Data Values
14. XML Namespaces
15. Web Services
16. Extensible Stylesheet Language Transformations (XSLT)
17. XML Software Tools
18. Unresolved Issues
Key Federal XML References and Web Sites
1. XML Guidance Documents
2. Related Guidance and Methodology
3. Related Web Sites

To request a copy, email
Glossary integrated.acquisition@gsa.gov and cc:
Kenneth.Sall@gsa.gov

IAE XML QuickPlace Area

Element
Naming
Procedure

IAE UBL Modeling Spreadsheet
• Identifier  Data Format
• Original Data Source  Min Length, Max Length
• Original Source ID  Owning Agency
• Original Source Data Element Name  Comments
• Definition  Data Flow
• XML Tag Name  IAE SS Source
• Dictionary Entry Name  IAE Associated Object Qualifier
• ABIE/ASBIE/BBIE  IAE Associated Object
• Object Class Qualifier  IAE Business Rules
• Object Class Term  IAE Min Value, IAE Max Value
• Property Term Qualifier  IAE Default Value
• Property Term  IAE Code List
• Representation Term Qualifier  IAE Type
• Representation Term  IAE SS Interface Element Name
• Data Type Qualifier  IAE SS Destination
• Data Type  IAE SS Name
• Associated Object Class Qualifier  Reviewer Initials
• Associated Object Class Term  Core Component
• Business Term  UBL Source
• Min Occurrence, Max Occurrence 
32 LMI Status - Reviewed, Harmonized, Submitted
IAE UBL Modeling Example
• Identifier - 12889
• Original Data Source
• Original Source ID
• Original Source Data Element Name - SELLER_ANNUAL_REVENUE
• Definition - Total revenue from Intra-governmental sales for the previous fiscal year
• XML Tag Name
Seller Party IntraGovernmental Sales Amount
• Dictionary Entry Name
• ABIE/ASBIE/BBIE
• Object Class Qualifier - Seller
• Object Class Term - Party
• Property Term Qualifier – IntraGovernmental Sales
• Property Term - Amount
• Representation Term Qualifier
• Representation Term - Amount
• Data Type Qualifier
• Data Type
• Associated Object Class Qualifier
• Associated Object Class Term
• Business Term
•
33 Min Occurrence, Max Occurrence – 0, 1
IAE UBL Modeling Example [cont.]
 Data Format
 Min Length, Max Length – 0, 15
 Owning Agency
 Comments
 Data Flow
 IAE SS Source - FedReg
 IAE Associated Object Qualifier
 IAE Associated Object
 IAE Business Rules - Mandatory for Seller business Types. All Numeric Data but stored in character format.
 IAE Min Value, IAE Max Value
 IAE Default Value
 IAE Code List
 IAE Type – Alphanumeric ?
 IAE SS Interface Element Name - Annual Revenue
 IAE SS Destination - User Input
 IAE SS Name - IGTE, IGTS
 Reviewer Initials
 Core Component
 UBL Source
 LMI Status - Reviewed, Harmonized, Submitted

GSA’s CORE.gov Registry/Repository
 To improve interagency collaboration on component-based development.
 To improve efficiency of development of component-based applications.
 To support e-Gov initiatives.
 To be user-friendly, efficient and effective.
 To promote stakeholder participation.
 To support OMB mandates for FEA development.
 To refine and manage the component lifecycle process.

IAE.CORE.gov Structure

Summary and Conclusions
 Full compliance with Federal and International XML guidance is time-
intensive. Requires active buy-in from all partners.
 Active participation of Subject Matter Experts in all phases is crucial

for success.
 Element naming is the first step toward defining robust information

exchanges and XML Schema to implement them.
 Objective evaluation and performance criteria are lacking.
 Coordinating disparate systems across numerous agencies poses

additional challenges that are out of the scope of XML (i.e., change
management, political barriers, etc.).
 Less than rigorous data modeling efforts may be fruitful if carrying the
work forward becomes a requirement in the RFP.
 eTravel: Time constraint due to RFP deadlines.
 IAE: International scope, 4 times as many data elements, 20 shared

systems, data modeling well underway.

Six

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Six

Uploaded by

Copyright:

Available Formats

Implementing XML Guidelines for

the Integrated Acquisition

 Federal XML Guidance Sources:

 International Guidance Sources:

 Data Normalization for the eTravel Service

 ISO 11179/Core Component/UBL Modeling for the

 CORE.gov Registry and Repository

 Summary and Conclusions

2 Copyright © 2004 Kenneth B. Sall. All Rights Reserved.

Performance Reference Model (PRM)

Interoperability / Information Sharing

Service Component Reference Model (SRM)

Data and Information Reference Model (DRM)

Technical Reference Model (TRM)

 EPA’s “XML Design Rules and Conventions for the Environmental

 “Recommended XML Namespace for Government Organizations” [dated

4 Copyright © 2004 Kenneth B. Sall. All Rights Reserved.

 UN/CEFACT Techniques and Methodologies Group:

 OASIS Technical Committee: Universal Business Language

 Other eGovernment Sources: UK, Hong Kong (common schema

5 Copyright © 2004 Kenneth B. Sall. All Rights Reserved.

 Object Class - objects that share the same attributes,

 Property Term – property that the data element represents

 Representation Term – basic data type (e.g., Text [for Name],

 Object Class and Property Term can have Qualifiers (e.g.,

 Methodology for developing a common set of

 Core Component Type – basic concept without any

 BIE – Business Information Entity = Core Component

7 Copyright © 2004 Kenneth B. Sall. All Rights Reserved.

 ABIE – Aggregate BIE; several related BIEs (e.g.,

 ASBIE – Association BIE; represent relationships

8 Copyright © 2004 Kenneth B. Sall. All Rights Reserved.

– UN/CEFACT TMG - General Document Download Section [

– UN/CEFACT - UMM User Guide Revision 12 (2003-09-22)

 Documents for TMG Review (not for implementation)

9 Copyright © 2004 Kenneth B. Sall. All Rights Reserved.

 OASIS Universal Business Language TC includes link to the UBL

 Goal: to develop a standard library of XML business documents

 The TC will then design a mechanism for the generation of context-

 Highly recommended intro: Eve Maler’s "XML for e-Business"

 “Rather than adopt each of the vertical industry vocabularies, the

Forms Presentation SC - Formatting Specifications

 Long checklist of Do's and Don't for moving from

 Rules are in flux.

 Some rules are debatable (e.g., xsd:choice not

13 Copyright © 2004 Kenneth B. Sall. All Rights Reserved.

 Clever but complicated mechanism for creating

 Goal is for standards organizations such as ISO and

 Everyone else "includes" the code list schema they

 For example, IAE might designate itself as maintainer

14 Copyright © 2004 Kenneth B. Sall. All Rights Reserved.

 GSA’s eTravel Initiative “[p]rovides a government-wide web-based

 “From travel planning and authorization to reimbursement, end-to-end

 Three 10-year contracts—worth $450 million combined—are expected

 12/23/03: FTR Amendment requiring agencies to complete adoption of

 Sites (multiple vendor award):

 Focus on U.S. Federal travel, not on international harmonization.

 Data call responses received from 17 of the 24 BRM agencies.

 Multiple awards; 3 vendors delivering XML Schema based on our attachment.

 Hope to eventually align with non-profit OpenTravel Alliance.

17 Copyright © 2004 Kenneth B. Sall. All Rights Reserved.

18 Copyright © 2004 Kenneth B. Sall. All Rights Reserved.

 GSA’s Integrated Acquisition Environment (IAE) E-Government initiative