# Table of Contents {#table-of-contents .unnumbered}

[Table of Contents i](#table-of-contents)

[List of Figures ii](#list-of-figures)

[**1.** Executive Summary 1](#executive-summary)

[1.1 Stakeholders & Benefits 3](#stakeholders-benefits)

[**2.** The Integrated Acquisition Environment
5](#the-integrated-acquisition-environment)

[2.1 eMarketplace 5](#emarketplace)

[2.2 Business Partner Network (BPN) 6](#business-partner-network-bpn)

[2.3 Acquisition Information Reporting (AIR)
6](#acquisition-information-reporting-air)

[2.4 Intra-governmental Transactions Exchange (IGTE)
7](#intra-governmental-transactions-exchange-igte)

[2.5 Standard Transactions 7](#standard-transactions)

[**3.** Standard Transactions Details 8](#standard-transactions-details)

[3.1 What are Standard Transactions? 8](#what-are-standard-transactions)

[3.2 The IAE Standard Transactions Process
8](#the-iae-standard-transactions-process)

[3.3 Developing IAE Standard Vocabulary
9](#developing-iae-standard-vocabulary)

[3.4 Standard Transactions Vocabulary, Version 1.0
11](#standard-transactions-vocabulary-version-1.0)

[3.5 Data Element Renaming Process for Standard Transactions 1.1
12](#data-element-renaming-process-for-standard-transactions-1.1)

[3.6 Alphanumeric, String or Text? 14](#alphanumeric-string-or-text)

[3.7 Boolean Values 14](#boolean-values)

[3.8 Length vs. MaxLength 14](#length-vs.-maxlength)

[3.9 Dates and Time 14](#dates-and-time)

[3.10 Currency Amounts 15](#currency-amounts)

[3.11 Identifiers vs. Codes 16](#identifiers-vs.-codes)

[3.12 When Other Elements are Necessary
17](#when-other-elements-are-necessary)

[3.13 Acronyms and Abbreviations 17](#acronyms-and-abbreviations)

[3.14 Code Lists Gap Analysis and Recommendations
18](#code-lists-gap-analysis-and-recommendations)

[3.15 XML Guidance for IAE: Naming and Design Rules
18](#xml-guidance-for-iae-naming-and-design-rules)

[3.16 Maintaining and Expanding Standard Transactions
19](#maintaining-and-expanding-standard-transactions)

[Appendix A: Data Element Standardization Process
20](#appendix-a-data-element-standardization-process)

[Appendix B: Creating ISO/IEC 11179 Names
24](#__RefHeading___Toc103747496)

[Appendix C: Key Acquisition Scenarios
27](#appendix-c-key-acquisition-scenarios)

[Appendix D: IAE Acronyms 28](#appendix-d-iae-acronyms)

[Appendix E: Glossary of Terms 29](#appendix-e-glossary-of-terms)

[Appendix F: References 35](#appendix-f-references)

# List of Figures {#list-of-figures .unnumbered}

[Figure 1 - The IAE High Level Conceptual Architecture
2](#__RefHeading___Toc100659697)

[Figure 2 - Standard Transaction Process 9](#_Ref52268021)

[Figure 3 - Inputs into building the Standardized Vocabulary
10](#_Ref52271330)

# **Executive Summary**

The Integrated Acquisition Environment (IAE) is one of 24 e-Government
initiatives in the President's Management Agenda. The IAE value
proposition recognizes acquisition has common functions, which can be
consolidated through a multi-agency, shared services environment. Figure
1 shows the high level conceptual architecture for IAE. The vision is to
create a secure business environment that facilitates and supports
cost-effective acquisition of goods and services in support of mission
performance.

![](media/image3.png){width="6.798611111111111in"
height="6.424305555555556in"}

[]{#__RefHeading___Toc100659697 .anchor}Figure 1 - The IAE High Level
Conceptual Architecture

The target audience for this document is the Federal Acquisition
Community that includes Federal Agency Acquisition, Information
Management, and Finance organizations as well as private companies
providing acquisition and financial commercial-off-the-shelf or custom
software to federal agencies.

The objectives of this document are to:

1.  Introduce and describe IAE Standard Transactions and its role in
    enabling the interoperability of systems across the IAE environment;

2.  Explain the role of Standards in establishing interoperability in a
    shared systems environment;

3.  Describe the process used to develop and maintain IAE Standard
    Transactions;

4.  Refine definitions, data element names and constraints of the
    Standard Vocabulary based on analysis of the existing interfaces for
    four of the shared IAE systems that were included in the Standard
    Transactions v1.0 -- Central Contractor Registration (CCR), Federal
    Procurement Data System -- Next Generation (FPDS-NG),
    Intragovernmental Transaction Exchange (IGTE), and Federal
    Registration (FedReg).

## 1.1 Stakeholders & Benefits {#stakeholders-benefits .unnumbered}

The success of IAE Standard Transactions and their ability to support
improved acquisition processes is dependant on ongoing involvement and
support from the acquisition community. [Table 1]{.mark} outlines the
major stakeholders and benefits of IAE Standard Transactions for the
acquisition community.

[Table 1]{.mark}: Major stakeholders and benefits of the IAE Standard
Transaction

+------------+---------------------------------------------------------+
| **Sta      | **Benefits**                                            |
| keholder** |                                                         |
+============+=========================================================+
| Federal    | Increased interoperability among systems in IAE that    |
| A          | support end-to-end processes                            |
| cquisition |                                                         |
| Community  | Greater flexibility to incorporate new/changed          |
|            | requirements or capabilities                            |
+------------+---------------------------------------------------------+
| Federal    | One common approach and vocabulary for interacting with |
| Finance    | IAE shared systems                                      |
| Community  |                                                         |
|            | Less time and cost to implement new/changed financial   |
|            | integration requirements                                |
+------------+---------------------------------------------------------+
| Federal    | Reduction in cost/time to develop and maintain systems  |
| I          |                                                         |
| nformation | Robust, secure, managed integration environment         |
| Technology |                                                         |
| Community  | Increase staff experience and expertise with modern     |
|            | data standardization and integration technologies       |
|            |                                                         |
|            | Alignment with Federal Enterprise Architecture (FEA)    |
|            | Data Reference Model (DRM)                              |
+------------+---------------------------------------------------------+
| Vendors    | One common approach and vocabulary for interacting with |
|            | IAE shared systems                                      |
|            |                                                         |
|            | Less time and cost to respond to new/changed Federal    |
|            | Government requirements                                 |
|            |                                                         |
|            | Less time and cost to introduce new/changed             |
|            | capabilities                                            |
|            |                                                         |
|            | Increased commonality between how they interact with    |
|            | the Federal Government and their other customers (State |
|            | & Local, Industry, International)                       |
+------------+---------------------------------------------------------+
| COTS       | Only need to support one common approach and vocabulary |
| Providers  | in their products for integration with IAE shared       |
|            | systems                                                 |
|            |                                                         |
|            | Increased capability for sophisticated integration with |
|            | IAE shared systems and end-to-end processes             |
|            |                                                         |
|            | Increased commonality between solutions developed for   |
|            | Federal Government and other customers (State & Local,  |
|            | Industry, International)                                |
+------------+---------------------------------------------------------+

# **The Integrated Acquisition Environment**

The President's Management Agenda on E-Government established the IAE
initiative in 2001 to develop a secure business environment that
facilitates and supports cost-effective acquisition of goods and
services in support of mission performance throughout the government.
The Office of Acquisition Services, with the General Services
Administration as the Managing Partner, leads the IAE development. Over
300 representatives from 65 agencies have participated in IAE working
groups to help define and implement the IAE vision.

Federal agencies have been actively using electronic commerce and
working toward increasing efficiencies within the government's
acquisition process in response to legislation and policy changes.
However, lack of coordination among agencies has led to duplication of
effort, stove-piped information systems, lack of data/messaging
standards, lack of scale, and insufficient leverage.

The premise of a government-wide Integrated Acquisition Environment is
that it be more successful and cost-effective than stand-alone agency
processes.

The IAE will leverage the Internet and the technology infrastructure
currently existing in government agencies and will also leverage
existing and emerging government capabilities. IAE will be built on the
framework of a shared services model where no single organization has
\"ownership\", rather the services are a constellation of capabilities
built on standards and accessible over the Internet. The IAE will serve
as the focal point for various services and will provide the
capabilities that can be leveraged by the acquisition community
stakeholders to conduct business across the government.

The major elements of IAE include five broad Business Areas:

-   eMarketplace

-   Business Partner Network (BPN)

-   Acquisition Information Reporting (AIR)

-   Intra-governmental Transactions (IGT)

```{=html}
<!-- -->
```
-   Standard Transactions

Each of these is discussed below.

## 2.1 eMarketplace  {#emarketplace .unnumbered}

eMarketplace will provide market research capabilities for buyers and
sellers. Initially, it established a government database of existing
interagency contracts, to facilitate discovery and enable smarter
business decisions. This Interagency Contract Directory (ICD) will be
incorporated in the FPDS-NG and will enable future analysis of business
duplication to improve spend leverage. The intra-governmental sources
for supplies and services will also be linked providing user's access to
all government sources (contracts and other agencies awardees) in one
place.

The longer-term vision is to evolve towards integration of e-catalogs in
an effort to eliminate duplicate requirements on our vendors and
facilitate integration with back office finance and acquisition systems.

## 2.2 Business Partner Network (BPN)  {#business-partner-network-bpn .unnumbered}

The Business Partner Network is the business area for the trading
partners for the government -- a one-stop-shop for registering and
accessing vendor information. The BPN includes:

-   Central Contractor Registration (CCR) system that provides a single
    data entry system for vendor information collection and validation.
    CCR maintains the core vendor identification key (using DUNS) and
    Electronic Funds Transfer information that is used by all systems
    across the government. As such, CCR data is shared both with agency
    contract writing systems, and with all government systems that use
    vendor information (e.g. Agency financial systems);

```{=html}
<!-- -->
```
-   Integration with other shared vendor-information systems in the
    Government to provide a single source for all information on a
    vendor to improve competitive sourcing and enable better business
    decisions. Examples include: Online Representations and
    Certifications Application (ORCA) for vendors, the database for the
    required standard representations and certifications required in
    every solicitation; and the Excluded Parties Listing System (EPLS);
    and

-   Validation of data with third parties wherever possible such as
    Taxpayer Identification Number with IRS; DUNS number validation with
    Dun and Bradstreet; 8(a), HUBZone and Small Disadvantaged Business
    status validation with SBA.

## 2.3 Acquisition Information Reporting (AIR) {#acquisition-information-reporting-air .unnumbered}

The IAE Acquisition Information Reporting (AIR) business area is the
focal point for all acquisition reporting across IAE shared and partner
systems. A government-wide procurement reporting and business
intelligence capability is critical to understanding purchasing activity
across the government. This allows the government to develop sourcing
strategies including opportunities to pool spend, negotiate
government-wide contracts, and identify purchasing trends:

-   The Federal Procurement Data System -- Next Generation (FPDS-NG)
    provides the initial foundation for AIR. FPDS-NG is the central
    point for consolidated collection of statistical and management
    information related to government acquisitions. It provides timely
    management data and tailored reporting capability of real-time
    information in an automated environment. It also eliminates the need
    for dozens of feeder systems; and

-   AIR will expand on FPDS-NG by adding reporting capabilities for
    information in other IAE systems, as feasible. Examples include
    Purchase card information from the banks and Intra-governmental
    transaction history.

##  2.4 Intra-governmental Transactions Exchange (IGTE) {#intra-governmental-transactions-exchange-igte .unnumbered}

Many existing processes and systems supporting ordering, billings, and
collections between federal agencies, and between organizations within
some agencies are extremely inefficient. Additionally, matching or
reconciling these transactions is difficult because there is no
standardized process/system. IGT will unify the process and introduce a
standard system with enforced data stewardship roles and
responsibilities. This will streamline the data handling processes,
reduce workload, improve billing accuracy, and reduce payment errors. It
will also significantly improve the ability to identify matching
intra-governmental revenues and expenses for elimination purposes in the
preparation of consolidated financial statements. Finally, the buyer
generated order number and the seller generated invoice number will
provide agencies the data they need to create accounting entries within
their systems.

## 2.5 Standard Transactions  {#standard-transactions .unnumbered}

IAE is critically dependant on interoperability of the shared, agency,
and vendor systems in the acquisition environment. Standard Transactions
establishes standard data elements, business definitions, ownership,
behaviors, and roles and responsibilities for Government acquisition
data. The "common language" provided by Standardized Transactions is a
key enabler for achieving this needed interoperability. Standard
Transactions address both what information has to be exchanged among
systems (standard data exchanges), and what the information means
(standard data element names and semantics) so that all systems can
understand each other. Without Standard Transactions, every system would
need to know how to speak every other system's unique language -- and
would incur the related overwhelming complexity, time, and cost of
incorporating new/changed systems or capabilities.

# **Standard Transactions Details**

## 3.1 What are Standard Transactions? {#what-are-standard-transactions .unnumbered}

The Standard Transactions define the "common language" used to support
interoperability:

-   Between parts of IAE shared systems;

-   Between IAE shared systems and agency back office applications
    (financial, acquisition, program); and

-   Between IAE shared systems and vendor systems.

    Standard Transactions are composed of Standardized Vocabulary that
    defines the MEANING (semantics) and FORM (XML) of the data used in
    the Information Exchanges -- both required if systems are to
    understand each other. The Standardized Vocabulary includes both
    low-level data elements (e.g., name, phone number, etc) and higher
    level constructs (e.g., a contact person with their physical and
    electronic addresses) needed for the Information Exchanges.

## 3.2 The IAE Standard Transactions Process {#the-iae-standard-transactions-process .unnumbered}

[Figure 2]{.mark} reflects the process for developing IAE Standard
Transactions. The development of the Standard Vocabulary may be new to
many readers -- therefore it is discussed below.

A cross agency team of procurement, finance, policy, and information
specialists was established to develop the IAE Standard Transactions.
The cross agency team quickly discovered that despite the governance of
the Federal Acquisition Regulations, there is often significant
variability in the acquisition process between and sometimes even within
agencies as a result of agency implementations.

Using existing work already accomplished by the Department of Defense
and the Joint Financial Management Improvement Program (JFMIP), the team
identified 16 key acquisition scenarios applicable to all federal
agencies. Each scenario documented the specific activities, information
exchanges, and information sources involved.

> []{#_Ref52268021 .anchor}

Figure 2 - Standard Transaction Process

These scenarios were distributed to agencies for review in a November
26, 2002 Memorandum for the Procurement Executive Council. Agency
responses were reviewed, analyzed and used to develop the "Acquisition
Backbone Scenario" a representation of the most complex acquisition
scenario that includes the majority of information exchanges discovered
in all 16 acquisition scenarios.

A listing of the 16 scenarios is included in [Appendix
C](#_Appendix_C:_). The "Acquisition Backbone Scenario" is part of the
supporting documentation.

## 3.3 Developing IAE Standard Vocabulary {#developing-iae-standard-vocabulary .unnumbered}

The IAE Standard Vocabulary is the aggregation of all the data elements
supporting the Information Exchanges needed for interoperability of
systems supporting IAE shared processes. [Figure 3]{.mark} shows the
major inputs that were used in defining the Standard Vocabulary.

[]{#_Ref52271330 .anchor}

Figure 3 - Inputs into building the Standardized Vocabulary

The process used for defining the IAE Standard Vocabulary is based on
the general approach defined in the FEA DRM (see [Appendix
A](#_Appendix_A:_) for details of the process.) As such, it involves a
sophisticated data modeling effort using Unified Modeling Language
(UML), ISO/IEC 11179 data element naming, Universal Business Language
(UBL), and UN/CEFACT Core Components Technical Specification principals.
This is followed by XML Schema development to define the precise
structure of Information Exchange payloads. By leveraging this approach,
IAE:

-   Builds on the experience and expertise of the data standardization
    community; and

-   Maximizes interoperability with other Agency, Federal
    lines-of-business, and external (industry, State & Local,
    international) vocabularies.

```{=html}
<!-- -->
```
-   The companion spreadsheet entitled "Standard Transactions v1.1
    Vocabulary" details the standard data elements identified for IAE.
    These elements are based on the information needed for existing
    interoperability with four of the IAE shared systems: CCR, FPDS-NG,
    IGTE, and FedReg.

## 3.4 Standard Transactions Vocabulary, Version 1.0 {#standard-transactions-vocabulary-version-1.0 .unnumbered}

Version 1.0 of the Standard Transactions vocabulary was defined in a
Microsoft Word table included in the document entitled [*IAE Standard
eTransactions Review Instructions and Forms*, Version 1.0]{.underline}
(Sept. 30, 2003). The data element modeling process was described in the
related document called *[IAE Standard eTransactions Version 1.0
Documentation]{.underline}* (Sept. 30, 2003). The Federal Enterprise
Architecture (FEA) was the main driver behind our approach which
consisted of:

-   Data modeling efforts using Unified Modeling Language (UML)

-   ISO/IEC 11179 data element naming

```{=html}
<!-- -->
```
-   Universal Business Language (UBL) version 0.7, an emerging standard
    from OASIS

-   UN/CEFACT Core Components Technical Specification (CCTS) version 1.9
    principles.

Standard Transactions 1.0 contained 257 elements drawn from five IAE
shared systems: CCR, FPDS-NG, FedReg, IGTE, and PPIRS. For each element,
we defined several columns (characteristics) based on responses to data
calls:

-   Number (the identifier described below)

-   XML Element Name (based on UBL conventions)

-   Basic Information Entity Name (based on ISO/IEC 11179 and CCTS)

-   An agreed upon definition

-   Format

-   Max Length

-   Data constraints, when known

Elements were grouped according to several very broad categories
(below). An identifier of the form "CCCddd" was assigned to each
element, where "CCC" was the three-character abbreviation for the
category and "ddd" was the three-digit number of the element within that
category. The broad categories were as follows:

-   ADR = Address

-   CON = Contact

-   CTR = Contract

-   FIN = Financial

-   ORG = Organization

-   PAY = Payment

-   SOC = Socioeconomic

-   SYS = System

For example, an illustrative row of the Standard Transactions 1.0
vocabulary appears below:

  -------- --------- -------------- ------------------------ -------------- -------- --------------
  No.      XML       Basic          Definition               Format         Max      Constraints
           Element   Information                                            Length   
           Name      Entity Name                                                     

  ADR011   Country   Product        The name that identifies Alphanumeric   50       minLength=0,
                     Origin\_       the territorial division                         maxLength=50
                     Address.       (a chief unit of local                           
                     Country. Text  administration) of a                             
                                    country, as part of an                           
                                    address of the product                           
                                    origin.                                          
  -------- --------- -------------- ------------------------ -------------- -------- --------------

## 3.5 Data Element Renaming Process for Standard Transactions 1.1 {#data-element-renaming-process-for-standard-transactions-1.1 .unnumbered}

In Standards Transactions 1.1, our focus was to refine the element names
that were published in version 1.0, rather than to introduce additional
elements. Wherever possible, we have chosen element names that match
elements from UBL 1.0 (from OASIS). In cases where elements related to
object classes not defined in UBL, we have drawn from the core
components in TBG-17 version 2.01 (from UN/CEFACT) whenever possible.
The elements and core components that comprise these two international
standards are located at:

-   <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl>

-   <http://www.disa.org/cefact-groups/tbg/wg/tbg17_main.cfm>

\[At the time of this writing, the valid link to TBG-17, version 2.01
was:
[http://www.disa.org/cefact-groups/tbg/docs/tbg17/TBG%20CC%20Library%20Version%201_081004.xls](http://www.disa.org/cefact-groups/tbg/docs/tbg17/TBG CC Library Version 1_081004.xls)
.\]

In Standard Transactions 1.1, the Word table has been replaced by a
Microsoft Excel spreadsheet. We introduced a "Parent XML Element Name"
column to provide hierarchical context. We also combined the "Max
Length" and "Constraints" columns into one column called "Constraints".
For example, the sample row above became:

  -------- ------------- ---------------------- ------------- ----------------- -------------- --------------
  No.      XML Element   Parent XML Element     Basic         Definition        Format         Constraints
           Name          Name                   Information                                    
                                                Entity Name                                    

  ADR011   CountryName   ProductOriginAddress   Product       The name that     Alphanumeric   minLength=0,
                                                Origin\_      identifies the                   maxLength=50
                                                Address.      territorial                      
                                                Country. Name division (a chief                
                                                              unit of local                    
                                                              administration)                  
                                                              of a country, as                 
                                                              part of an                       
                                                              address of the                   
                                                              product origin.                  
  -------- ------------- ---------------------- ------------- ----------------- -------------- --------------

There are several points to note from this example:

1.  The identifier "ADR011" has been preserved. This makes it easy to
    compare the Standard Transaction 1.0 and 1.1 names. The order of
    rows has also been maintained. However, 16 elements from PPIRS have
    been removed from version 1.1, so there are what appear to be
    "missing" rows. The PPIRS elements have been removed because that
    system is no longer being managed by the acquisition community under
    the IAE Domain and currently undergoing Business Process
    Reengineering that will lead to redesign.

```{=html}
<!-- -->
```
1.  The XML Element Name has changed, as has the Basic Information
    Entity Name. This is true for most of the elements in the Standard
    Transactions vocabulary.

2.  The Parent XML Element Name gives us context, so the XPath to this
    particular element would be //ProductOriginAddress/CountryName,
    denoting that the parent element may itself have a parent,
    grandparent, etc. in the XML document hierarchy. (For a quick
    introduction to XPath, see
    <http://www.w3schools.com/xpath/xpath_intro.asp> .)

3.  The Constraints column reflects the maxLength (as well as
    minLength), so no other constraint information is needed in this
    case.

As we examined each of the elements previously defined in Standard
Transactions 1.0, we reviewed several different information sources to
determine the best name and constraints:

-   We reconsidered the 1.0 Basic Information Entity (BIE) Name based on
    our current understanding of CCTS 2.01 and ISO/IEC 11179, as well as
    other IAE data modeling performed since 2003.

-   In particular, we reconsidered all components of the BIE: the Object
    Class, the Property Term, the Representation Term, and the typical
    qualifiers that preceded each of the three parts.

-   If UBL 1.0 defined a similar Object Class and Property Term, we
    borrowed that (assuming it was relevant to the definition of our
    element).

-   In other cases, TBG-17 version 2.01 had a more appropriate match, so
    we borrowed that. However, since TBG-17 is Core Components (rather
    than BIEs), we had to add our own qualifiers.

-   In many cases, we needed to revisit the original data dictionary
    entry for the data element as given in the response to our early
    data call since the entry might reveal details that would cause us
    to alter our element name, definition, format and/or constraints.
    For example, if an element was previously indicated as Boolean (an
    "Indicator" in CCTS), but the data dictionary indicated it was a
    single character value (e.g., 'Y', 'N', or 'x"), then we changed the
    format accordingly to Alphanumeric of length = 1.

-   For common Property Terms, we have selected specific maxLength
    constraints. For example:

    -   Telephone, FAX = 25 characters

    -   Name = 75 characters (for elements for which a name is not
        subdivided into 2 or 3 fields)

    -   Given = 25 characters

    -   Middle = 25 characters

    -   Family = 25 characters

    -   CountryName = 50 characters

## 3.6 Alphanumeric, String or Text? {#alphanumeric-string-or-text .unnumbered}

The definition of the term "Alphanumeric" differs depending on the
information technology application. Rather than simply the set of all
letters and digits, we have chosen the broader definition as per
WordNet:
"character set that includes letters and digits and punctuation marks"
and also spaces. Many developers may think of this as "String" (Java) or
"Text" (CCTS).

## 3.7 Boolean Values {#boolean-values .unnumbered}

IAE systems presently implement many different value pairs to represent
Boolean values: {0, 1}, {\'N\', \'Y\'}, {\"no\", \"yes\"}, {\"true\",
\"false\"}, etc. Since our goal is to create XML Schema to support
standard transactions, we need to make it part of migration path for
systems to use the value set that is built-in to the XML Schema
primitive type, xsd:boolean. The legal literal values are: {0, 1, false,
true}. The canonical values are simply {false, true}. Therefore, please
do not use yes/no variants. See
<http://www.w3.org/TR/xmlschema-2/#boolean>

## 3.8 Length vs. MaxLength {#length-vs.-maxlength .unnumbered}

In the accompanying Standard Transactions 1.1 Vocabulary spreadsheet, we
have used term "length" to indicate that the data value has a fixed
length, whereas "maxLength" denotes the upper limit of an element of
variable length.

## 3.9 Dates and Time {#dates-and-time .unnumbered}

A wide variety of date formats are used in IAE shared systems (MMYYYY,
MMDDYY, MMDDYYYY, YYYYMMDD, etc.). Does the year appear first or last?
Is the year 2 or 4 digits? Are there slashes to separate month, date,
and year? Is the date of the month even included? The answers vary
widely across systems. In the accompanying Standard Transactions 1.1
Vocabulary spreadsheet, we have tried to capture the *existing* date
representations in the Constraints column for each element of Format
(datatype) Date.

However, system stewards should initiate analysis to determine the
impact of shifting to a more uniform date format. UBL 1.0 defines both a
DateType and a DateTimeType, based on xsd:date and xsd:dateTime,
respectively. If your system does not care about time of day, use
DateType. XML instance examples of the two types follow:

\<shipDate\>1999-05-21\</shipDate\>

\<cbc:ActualDeliveryDateTime\>2003-02-14T13:30:00\</cbc:ActualDeliveryDateTime\>

In the first example, note that the W3C XML Schema xsd:date format is
**YYYY-MM-DD**; the hyphens are required. In the second example, the
line break after \"02-\" is strictly for printed readability; the XML
must not contain a newline here. Also notice that the xsd:dateTime
format uses the letter 'T' as the time separator; no other character is
permitted, so the format is **YYYY-MM-DD*T*HH:MM:SS**. (Actually, there
are additional details such as time zone and how to omit optional parts
in the W3C specification.)

This date/time format is actually an international standard that
predates UBL and XML Schema, ISO 8601:2000. The normative ISO 8601:2000
reference is
<http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=26780>
. However, a very useful, free informative reference is located at
<http://www.cl.cam.ac.uk/~mgk25/iso-time.html> .

For the UBL reference, see
<http://docs.oasis-open.org/ubl/cd-UBL-1.0/xsd/common/UBL-UnspecializedDatatypes-1.0.xsd>
. For details about the W3C implementation, see the XML Schema Part 2
specification, <http://www.w3.org/TR/xmlschema-2/#date> and
<http://www.w3.org/TR/xmlschema-2/#dateTime> .

## 3.10 Currency Amounts {#currency-amounts .unnumbered}

All monetary values in IAE systems should be expressed in a 15-character
format (maximum length), with a maximum of 12 digits to the left of the
decimal point and 2 digits to the right, with one position reserved for
the decimal point. The highest value is 999,999,999,999.99 (without the
commas). No commas, spaces, dollar signs or other non-digit characters
should be permitted, with the exception of the decimal point (and
possibly a negative sign). In most systems, this will be a floating
point number, but if stored as a string, these character restrictions
must be enforced. In UBL 1.0, the Core Component Type AmountType is used
for currency. It is an extension of the XML Schema built-in type
xsd:decimal and includes two optional attributes. Although the number of
digits is not constrained in UBL, XML Schema allows you to constrain
digits using the "fractionDigits" facet (constraint).

For the UBL reference, see
<http://docs.oasis-open.org/ubl/cd-UBL-1.0/xsd/common/UBL-CoreComponentTypes-1.0.xsd>
. See also the XML Schema Part 2 specification
<http://www.w3.org/TR/xmlschema-2/#decimal> .

## 3.11 Identifiers vs. Codes {#identifiers-vs.-codes .unnumbered}

The distinction between Core Component Types Identifier and Code is
somewhat subtle in UBL 1.0. The definitions from
<http://docs.oasis-open.org/ubl/cd-UBL-1.0/xsd/common/UBL-CoreComponentTypes-1.0.xsd>
follow:

[Code]{.underline}: \"A character string (letters, figures, or symbols)
that for brevity and/or language independence may be used to represent
or replace a definitive value or text of an attribute together with
relevant supplementary information.\"

[Identifier]{.underline}: \"A character string to identify and
distinguish uniquely, one instance of an object in an identification
scheme from all other objects in the same scheme together with relevant
supplementary information.\"

\[The above link also includes 7-9 attributes for both of the Core
Component Types, such as codeListID and
identificationSchemeAgencyName.\]

In IAE shared systems, there are some elements previously called
*Something*Code that are actually Identifiers and others called
*Something*ID that are really Codes. As we re-visited each data element
from Standard Transactions 1.0, we re-evaluated which was the
appropriate designation.

The key determining factor was whether the value set was likely to
change frequently or infrequently. For example, DUNS and SSN are updated
daily (at least). A DUNS number distinguishes or identifies a specific
organization from all other organizations, just as an SSN uniquely
distinguishes one individual from all others. DUNS and SSN are therefore
Identifiers.

In contrast, countries and states do not change often. Abbreviations or
numeric shorthand for countries and abbreviations for states are
relatively stable; the set of possible values can be enumerated in a
code list. Addition of new countries and new states are infrequent
events. Furthermore, the codes used to represent them do not change very
often. These are therefore Codes. Less obvious examples include:

\(a\) A code identifying party receiving transmission; codes agreed to
by trading partners. Originally called Application Rcvrs Code (TXN06).
We have given this the BIE of Receiving\_ Party. Identification.
Identifier because it uniquely distinguishes one party from all others.

\(b\) When considering the type of Indefinite Delivery Vehicle (IDV)
contract, there is a finite set of possible values that can readily be
enumerated. Therefore, the assigned BIE is Contract. Indefinite Delivery
Contract\_ Type. Code.

\(c\) The FIPS Pub. 95 code for the agency of the contracting or funding
office that executed or is otherwise responsible for the transaction was
assigned the BIE of Contracting\_ Organization. Agency\_ Identification.
Identifier.

## 3.12 When Other Elements are Necessary {#when-other-elements-are-necessary .unnumbered}

If our set of elements does not provide certain elements that your
system needs, we recommend that you look first at UBL and then at TBG-17
for guidance. For example, UBL defines BuildingName and BuildingNumber
as optional child elements within the Address xsd:complexType. Since IAE
shared systems do not presently separate this information into discrete
elements, we have specified only StreetName and AdditionalStreetName.
However, you can use BuildingName and BuildingNumber if you need them.

## 3.13 Acronyms and Abbreviations {#acronyms-and-abbreviations .unnumbered}

Federal acquisition is replete with acronyms and abbreviations. On the
one hand, expanding acronyms to form element names removes ambiguity.
However, it makes for unnaturally long element names such as
CommercialAndGovernmentEntityID and
NorthAmericanIndustryClassificationSystemCode that are subject to typing
errors and not likely to be the target of a text search since
procurement people with think of the acronym.

While the guidance from UBL and various [Naming and Design
Rules](#_3.15__XML_Guidance_for_IAE:_Naming_) documents prohibits the
use of acronyms and abbreviations, IAE XML element names
*[may]{.underline}* incorporate acronyms with the following mandatory
restrictions:

-   The acronym *[must]{.underline}* be an established and widely
    understood acronym in the Federal procurement community. Examples
    include, but are not limited to: NAICS, PSC, FSC, CAGE, SIC, SSN,
    TIN, etc. \[Note that DUNS is the only approved procurement-related
    acronym in UBL 1.0.\]

-   Data definitions *[must]{.underline}* expand the acronym, both in
    the relevant data dictionary and in the XML Schema, each acronym
    must be expanded with xsd:documentation.

-   Business Information Entity (BIE) names used for data dictionary
    entries (dictionary entry names) *[may]{.underline}* also use
    acronyms.

-   Abbreviations are not permitted (except for ID, which is approved in
    UBL 1.0).

## 3.14 Code Lists Gap Analysis and Recommendations {#code-lists-gap-analysis-and-recommendations .unnumbered}

In the first quarter of 2005, the IAE PMO performed an analysis of over
a dozen code lists used by various IAE shared systems. Results were
published in April 2005 in the document entitled IAE Code Lists Gap
Analysis and Recommendations with an accompanying spreadsheet. IAE PMO
analysis covers NAICS, CAGE, FSC, PSC, SIC, ISO 3166, as well as various
FIPS codes for agencies, congressional districts, countries, and states.
All IAE system stewards should consult this gap analysis and follow its
recommendations. Many of the data elements listed in our Standard
Transactions Vocabulary 1.1 spreadsheet have value constraints based on
these code lists. In order to achieve true interoperability, it is
crucial that IAE shared systems migrate towards a single, common
authoritative sources for each code list.

Please note that UBL and the various Naming and Design Rules
specifications (see next section) discuss an elaborate and robust code
list mechanism, based on a common XML Schema that can be implemented by
any authoritative source of any code list. For example, if ISO
implemented this XML Schema and produced a version of ISO 3166 (country
codes) based on the schema, interoperability with UBL-based applications
would be achieved. There would never be ambiguity about whether a
particular data element was constrained to values from the 2-character
alpha, 3-character alpha, 3-digit ISO 3166 variants, English or French
or any given version. While the IAE PMO certainly encourages movement
toward this approach, virtually all of the code lists on which we depend
have not yet, to our knowledge, adopted this XML Schema. We will monitor
the situation over time and make appropriate technical updates as
necessary and feasible.

## 3.15 XML Guidance for IAE: Naming and Design Rules {#xml-guidance-for-iae-naming-and-design-rules .unnumbered}

Since the IAE PMO released the document entitled [IAE XML Summary
Guidance
1.1](http://egov.gsa.gov/QuickPlace/e-gov/PageLibrary85256AF00062C488.nsf/h_Toc/53FDB63D77E1F08485256E37006CFD20/?OpenDocument)
in February 2004, a number of XML Naming and Design Rules (NDR)
documents have surfaced from OASIS, UN/CEFACT, and the Department of the
Navy. Since the various NDRs are closely aligned with the UN/CEFACT
[Core Components Technical
Specification](http://www.unece.org/cefact/ebxml/CCTS_V2-01_Final.pdf)
(which is in turn based on ISO/IEC 11179), the IAE PMO strongly
encourages all shared systems and procurement system vendors to study
these documents and consider them (along with the CCTS) as the primary
sources of XML guidance for IAE.

See Robin Cover\'s detailed page, [XML Naming and Design Rules
Specifications Published by OASIS, UN/CEFACT, and Navy
CIO](http://xml.coverpages.org/ni2005-01-31-a.html) which includes
archived copies of the NDRs from three different (but interrelated)
sources:

-   [*Universal Business Language (UBL) Naming and Design
    Rules*](http://xml.coverpages.org/UBL-NDRv10-Rev1c.pdf). Publication
    Date: 15-November-2004. 104 pages. Approved by vote of the OASIS
    membership as an OASIS Standard. Document identifier:
    \'cd-UBL-NDR-1.0.1\'. OASIS source location:
    <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl> .

-   [*UN/CEFACT XML Naming and Design
    Rules*](http://xml.coverpages.org/ATG2-NamingAndDesignRules200501.pdf).
    Draft 1.1. 14-January-2005. 141 pages. Document identifier:
    \'NamingAndDesignRules_1.1.doc\'. UN/CEFACT source location:
    <http://www.disa.org/cefact-groups/atg/downloads/index.cfm> .

-   [*Department of the Navy XML Naming and Design
    Rules*](http://xml.coverpages.org/DON-XML-NDR20050127-33942.pdf).
    Final Version 2.0. Office of the DON, Chief Information Officer.
    January 2005. 168 pages. Navy source location:
    <http://www.doncio.navy.mil/> .

Robin Cover\'s page summarizes, compares, and contrasts the three
different NDRs and is therefore itself a valuable resource in
understanding these emerging sources of international XML guidance.

## 3.16 Maintaining and Expanding Standard Transactions {#maintaining-and-expanding-standard-transactions .unnumbered}

The shared systems are currently in various stages from concept to
prototype, redesign and production. The current information exchanges
and data elements are expected to increase in number and change over
time. To facilitate this growth the IAE Program Management Office will
release Standard Transactions v2.0 at a later date and will incorporate
remaining IAE shared systems. Updates will be published as changes in
the IAE shared systems are identified and documented.

The IAE Standard Transactions need to evolve with IAE interoperability
requirements and capabilities -- both within the IAE domain and with
related areas such as finance, asset management and sales, etc. To
achieve this goal, agency and industry acquisition community members
need to review their interoperability needs on an ongoing basis to
identify any desired changes or additions to the Standard Transaction
Information Exchanges or Vocabulary. They should also review evolving
Federal Registries (e.g., the CORE.gov maintained by GSA for the CIO
Council) to identify any data elements, schema, or integration services
that could be leveraged by IAE.

Desired additions or changes should be submitted to the IAE Program
Management Office by sending email to <integrated.acquisition@gsa.gov>.
You may also request to participate in future discussions about IAE data
elements. As part of this process IAE will also arrange for posting of
the updated Standard Transactions to the appropriate Federal registry(s)
so that they can be shared and reused as widely as possible. The updated
Standard Transactions will be shared with the CIO, CFO as well as the
CAO communities.

# **Appendix A: Data Element Standardization Process** {#appendix-a-data-element-standardization-process .unnumbered}

This appendix describes the process that the Standard Transactions
workgroup uses to develop standard data elements for IAE. Although shown
as a sequence here, several "steps" can be done concurrently and some
are an iterative process.

> **Step 1:** Identify a community of interest among the major players
> in the IAE line of business (and related lines of business where
> appropriate.)

-   Identify Subject Matter Experts (SMEs) who are willing to
    participate in working groups that meet on a regular basis.

-   Establish an electronic collaborative environment to support dialog.

> **Step 2:** Focus initially on atomic units of data needed for
> interoperability (i.e., data that is exchanged among systems or
> processes), rather than trying to define complete data models for all
> business processes and systems.

-   Start with a bottom-up rather than top-down approach.

-   Identify the common building blocks (e.g., Person, Address, etc.)
    that are likely to be reusable across stakeholders for a given
    system as well as across the environment.

> **Step 3:** Collect interface control documents and/or, data
> dictionaries, government regulated element lists, and other
> descriptions of the elements needed for interchange.

-   Initiate data calls, either formally or informally.

-   While it is highly desirable to obtain complete data dictionaries
    and/or formal interface control documents, some stakeholders may not
    be able to provide this level of detail. Be prepared to accept
    simple spreadsheets or even database tables. The essential
    information to capture is:

    -   Data elements names

    -   Element descriptions

    -   Data type or value constraints (length, value ranges, etc.)

    -   Whether the element is repeatable in a particular exchange

    -   Whether the element is mandatory, optional, or conditional

    -   Transactions in which the data element is used

> Note: It is important that shared system stewards update the IAE PMO
> as new versions of data dictionaries become available.
>
> **Step 4:** Analyze collected element lists across business partners
> to normalize element names and to identify groupings of related
> elements as higher-level structures (e.g., object classes). This
> involves using methodology developed by ISO/IEC, UN/CEFACT and OASIS,
> in addition to the better-known Unified Modeling Language (UML)
> techniques. Highlights of these methodologies follow; refer to the
> cited documents for considerable detail.

-   Electronic Business XML (ebXML) is a collaborative effort of two
    major international organizations: **UN/CEFACT** (United Nations
    Center for Trade Facilitation and Electronic Business) and **OASIS**
    (Organization for the Advancement of Structured Information
    Standards). UN/CEFACT is responsible for the Core Components
    Technical Specification and Business Process specifications. OASIS
    oversees the Registry and Repository, Messaging, and Collaboration
    Protocol specifications.

-   The Core Components Technical Specification defines a common set of
    semantic building blocks that represent the general types of
    business data in use today. The Core Components methodology provides
    a way to identify, capture and maximize the re-use of business
    information to support and enhance information interoperability
    across multiple business situations.

-   All ebXML Core Components conform to ISO/IEC 11179 data element
    naming conventions (see Appendix B)

-   When a Core Component is used in a real business circumstance, it
    serves as the basis for a Business Information Entity (BIE). For
    example, ShippingContact and OrderContact are BIEs derived from the
    more generic Contact Core Component.

-   Related BIEs are grouped together to form an Aggregate Business
    Information Entity (ABIE). Example: US\_ Person. Details and US\_
    Address. Details.

-   When one ABIE references another ABIE, you have an Association
    Business Information Entity (ASBIE). For example: US\_ Person. US\_
    Residence. US\_ Address and US\_ Person. US\_ Official. US\_ Address
    .

-   A major goal of the data vocabulary definition process is to arrive
    at a set of BIEs based on Core Components in the context of the Line
    of Business of the initiative.

    -   Schemas will be developed based on information exchange
        requirements identified via business process modeling.
        Information and process modeling and the XML schema creation
        process should be separate and distinct steps.

> **Step 5:** Generate or create XML Schema based on UBL methodology,
> including the identification of data constraints such as enumerations,
> code lists, value ranges, character patterns, lengths, etc.

-   Schema development will take place as a team effort with functional
    data experts, business experts, program managers, and IT specialists
    all involved. (These are likely to be the same or similar team
    needed for the earlier data modeling phase.)

-   The Universal Business Language (UBL) Library is:

    -   An XML-based business language

    -   Built upon existing EDI and XML business-to-business
        vocabularies

    -   Applicable across all industry sectors and domains of electronic
        trade

    -   Designed to be modular, reusable, and extensible

    -   Non-proprietary and royalty-free

    -   Intended to become an international standard for electronic
        commerce

    -   Addresses only a small subset of elements needed for IAE

```{=html}
<!-- -->
```
-   The UBL Library has been designed as a collection of object classes
    and associations expressed as a conceptual model. Specific document
    types are then assembled from these Business Information Entities
    (BIEs) by organizing them into a specific hierarchy. These
    hierarchical models are then transformed using the UBL Naming and
    Design rules into XML Schema syntax.

-   Three levels of content components are defined in UBL:

1.  *Atomic components* that hold individual pieces of information
    typically represented by primitive data types (e.g., \"text,\"
    \"Boolean,\" \"date\") or data types readily derived from these.
    Example: PostalCode of type "text".

2.  *Aggregate components* that hold logically related groups of atomic
    components and sub-aggregates. Example: Address containing
    StreetAddress, PostalCode, StateOrProvince, and Country.

3.  *Document components* that assemble atomic and aggregate components
    to form a self-contained logical unit. The business process context
    provides the requirements for which documents are to be assembled.
    Example: transactional messages within a business process.

-   Aggregate Business Information Entities (ABIEs) become the
    xsd:complexTypes of the XML Schema

> **Step 6:** Contribute XML Schema to the CORE.gov to increase the
> likelihood of reuse:

-   Contact IAE PMO to contribute your XML Schemas to CORE.gov.

-   If you are reluctant to contribute to CORE.gov at this stage,
    contributions should be placed in an IAE registry or web site where
    they are available to the IAE acquisition community.

> **FUTURE - Step 7:** Re-factor to harmonize with vocabularies from
> international groups such as the UN/CEFACT TBG-17 effort.

-   While the IAE is focused on efficiencies and reuse within the
    federal government, it should leverage international standards as
    much as possible. The process outlined above employs the methodology
    developed by several international groups.

-   The BIEs, Core Components, and XML Schema developed by the IAE
    should be contributed to the international efforts upon whose
    methodology they were developed.

-   Such contributions may require IAE to modify is schema to some
    extent, but the result will be improved data exchange capabilities
    at the international level.

The main reference for this process is the "IAE Summary XML Guidance"
which contains a complete reference section. Visit acquisition.gov,
click About IAE link, and then "IAE Summary XML Guidance V. 1.1,
\[2/4/04\]".

# **Appendix B: Creating ISO/IEC 11179 Names** {#appendix-b-creating-isoiec-11179-names .unnumbered}

The description that follows is a considerable simplification of a more
involved process. As such, developers are directed to ISO and UBL
documentation (see [References](#_Appendix_F:__References)) for the
details.

"ISO/IEC 11179 part 5 \[see references\] provides a standard for
creating data elements. This standard employs a dot notation and white
space to separate the various parts of the element and multiple words in
a part respectively. In order to meet XML requirements for component
naming, the ISO 11179 name must be converted to a \[XML\] *Name
Token*[^1]. The ISO 11179 part 5 standard provides a way to precisely
create a data element definition and name. Using or referencing this
name in a schema provides analysts with a better understanding of XML
component semantics, while using business terms as element names
improves readability. Requiring types to conform to ISO 11179
conventions will facilitate automated analysis of schema components
during any harmonization efforts. The upper and lower camel case
conventions are adopted from ebXML." \[DON XML Developer's Guide 1.1,
Section 7.1.3.2\]

An ISO 11179- compliant data element name consists of three parts:

An *"[Object Class]{.underline}"* term, which describes the kind of
thing to which you refer. This Object Class may consist of one or more
words, some of which may be context terms. For example, the ISO/IEC
11179 name 'Acoustic Signal. Frequency. Measure' has the Object Class
'Acoustic Signal'. As another example, consider that the ISO/IEC 11179
name \'EFT\_ Payment. Authorization. Date\' has the Object Class
\'Payment\'.

A *"[Property Term]{.underline}"* which is the property of the thing to
which you refer, which may consist of one or more words. For example,
the ISO/IEC 11179 name 'Acoustic Signal. Frequency. Measure' has the
Property Term 'Frequency'. Also, the ISO/IEC 11179 name \'EFT\_ Payment.
Authorization. Date\' has the Property Term \'Authorization\'.

A *"[Representation Term]{.underline}"* which identifies allowable
values for an element. This list is taken from an enumerated list of
allowable representation types (see below). For example, the ISO/IEC
11179 name 'Acoustic Signal. Frequency. Measure' has the Representation
Term 'Measure'. Another example is the ISO/IEC 11179 name \'EFT\_
Payment. Authorization. Date\' that has the Representation Term
\'Date\'.

Each term may have an additional *qualifier* term (signified by a
trailing underscore) to provide additional information. In the example
above, the Object Class has the qualifier \'EFT\_\' (as in "Electronic
Funds Transfer").

Other examples of ISO/IEC 11179 names include Product. NAICS. Code and
Organization. DUNS. Identifier, neither of which have qualifiers.

+---------+--------+-------+---------+-----------+------------------+
| **      | *      | **O   | **Pro   | **Repre   | **XML Element    |
| ISO/IEC | *Quali | bject | perty** | sentation | Name**           |
| 11179** | fier** | Cl    |         | Type**    |                  |
|         |        | ass** | *       |           |                  |
| **Data  | **     |       | *Term** |           |                  |
| Element | (optio |       |         |           |                  |
| Name**  | nal)** |       |         |           |                  |
+---------+--------+-------+---------+-----------+------------------+
| A       | \[     | Aco   | Fr      | Measure   | A                |
| coustic | none\] | ustic | equency |           | cousticFrequency |
| Signal. |        | S     |         |           |                  |
| Fre     |        | ignal |         |           |                  |
| quency. |        |       |         |           |                  |
| Measure |        |       |         |           |                  |
+---------+--------+-------+---------+-----------+------------------+
| EFT\_   | EFT\_  | Pa    | Author  | Date      | EFTPaymentA      |
| P       |        | yment | ization |           | uthorizationDate |
| ayment. |        |       |         |           |                  |
| Authori |        |       |         |           |                  |
| zation. |        |       |         |           |                  |
| Date    |        |       |         |           |                  |
+---------+--------+-------+---------+-----------+------------------+
| P       | \[     | Pr    | NAICS   | Code      | ProductNAICSCode |
| roduct. | none\] | oduct |         |           |                  |
| NAICS.  |        |       |         |           |                  |
| Code    |        |       |         |           |                  |
+---------+--------+-------+---------+-----------+------------------+
| Organi  | \[     | Or    | DUNS    | I         | Or               |
| zation. | none\] | ganiz |         | dentifier | ganizationDUNSID |
| DUNS.   |        | ation |         |           |                  |
| Ide     |        |       |         |           |                  |
| ntifier |        |       |         |           |                  |
+---------+--------+-------+---------+-----------+------------------+

Note: Although the above table only shows qualifiers used in conjunction
with the Object Class, they may also precede Property Terms and/or
Representation Types. Also, the "dot space" notation is intentional to
aid spell checking.

"XML components **MAY** be named after ISO/IEC 11179 data element names:

XML [Elements](#XMLElement) **SHOULD** be named after ISO/IEC 11179 data
element definitions *when [business terms](#BusinessTerm) do not exist.*

XML [Attributes](#Attributes) **SHOULD** be named after ISO/IEC 11179
data elements.

[*XML Schema data types*](#SchemaType) **MUST** be named after ISO/IEC
11179 data elements."

Note the distinction that XSD (XML Schema) data types **MUST** be based
on ISO/IEC 11179 names, whereas XML elements **MAY** be based on more
familiar business terms.

The XML Schema data type based on the first example above would be
AcousticSignalFrequencyMeasure. The XML element name would be
\<AcousticFrequency\>, assuming this was the common business term.
Similarly, the other examples result in the XML element names
EFTPaymentAuthorizationDate, ProductNAICSCode, and OrganizationDUNSID.

Consider another example, one which involves child elements. The ISO/IEC
11179 name "Address. City. Text" results from the Object Class
"Address", the Property Term Qualifier "City", the Property Term Noun
"Name", and the Representation Type "Text". The XML Schema type would be
"AddressCityName" and the XML element name would be \<AddressCity\>.

The allowable Representation Types (known as Core Component Types in
UBL) are:

-   Amount

-   Binary Object (plus Graphic, Picture, Sound and Video)

-   Code

-   Date Time (plus Date and Time)

-   Identifier

-   Indicator

-   Measure

-   Numeric (plus Value, Rate and Percent)

-   Quantity

-   Text (plus Name)

Those shown in parentheses are known as Secondary Representation Types.

# **Appendix C: Key Acquisition Scenarios**  {#appendix-c-key-acquisition-scenarios .unnumbered}

  -------- --------------------------------------------------------------
  1        Open Market -Not Simplified Acquisition

  2        Two Step Sealed Bid

  3        Sole Source (Open Market --Not Simplified)

  4        Unsolicited Proposal

  5        Sealed Bid

  6        Open Market Simplified \$100,000 - 5M Commercial Item

  7        Open Market Simplified \$25,001-100,000

  8        Open Market Simplified \$10,001-25,000

  9        Open Market Simplified \$2,501-10,000

  10       Small Business Innovation Research (SBIR)

  11       Delivery / Task Orders Against Indefinite Delivery Vehicle
           (IDIQ Contract)

  12       Orders Against FSS Schedule

  13       Orders Against Multiple Award Schedule

  14       Economy Act

  15       Micro Purchase (Stand Alone Single Purchase)

  16       Purchase Cards / Convenience Checks / Third Party Drafts
  -------- --------------------------------------------------------------

# **Appendix D: IAE Acronyms** {#appendix-d-iae-acronyms .unnumbered}

  ---------------- ------------------------------------------------------
  BPN              Business Partner Network

  CADO             Contract Award Documents Online

  CCR              Central Contractor Registration

  CPARS            Contractor Performance Assessment Reporting System
                   (DoD)

  CPS              Contractor Performance System (NIH)

  D&B              Dun and Bradstreet

  EEOC             Equal Employment Opportunity Commission

  EPLS             Excluded Parties Listing System

  eSRS             Electronic Subcontracting Reporting System

  FBO              Federal Business Opportunities (FedBizOpps)

  FedReg           Federal Registration Application

  FedTeDS          Federal Technical Data Solution

  FMS TOP          Financial Management Service Treasury Offset Program

  FPDS-NG          Federal Procurement Data System Next Generation

  Grantee Reg      Grantee Registration

  ICD              Interagency Contracts Directory

  IGT              Intra-governmental Transactions

  IPAC             Intra-governmental Payment and Collection System
                   (Treasury)

  NABS             Native American Business System

  ORCA             Online Representations and Certifications Application

  PPDB             Past Performance Data Base (NASA)

  PPIMS            Past Performance Information Management System (Army)

  PPIRS            Past Performance Information Retrieval System

  SBA PRO-Net      SBA Procurement Marketing Network

  VETS-100         Veterans' Employment and Training Service (DOL)

  WDOL             Wage Determinations On-Line
  ---------------- ------------------------------------------------------

# **Appendix E: Glossary of Terms** {#appendix-e-glossary-of-terms .unnumbered}

  -----------------------------------------------------------------------
  **Term**         **Meaning**
  ---------------- ------------------------------------------------------
  ABIE             **Aggregate Business Information Entity (ABIE)** - 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.

  Acquisition      A representation of the most complex type of
  Backbone         acquisition process. The acquisition Backbone Scenario
  Scenario         is based on Open Market Not Simplified purchases and
                   includes the majority of information exchanges found
                   in all acquisition scenarios.

  Acquisition      The IAE Acquisition Information Reporting (AIR)
  Information      business area will be the focal point for all
  Reporting (AIR)  acquisition reporting across IAE shared and partner
                   systems.

  Acquisition      16 key acquisition scenarios have been documented.
  Process          Major activities for each scenario were identified
  Scenarios        along with any information exchanges with external
                   applications used to support the activity.

                   

  Acquisition      A variation of the IDEF ICOM Modeling approach
  Scenarios        documenting the specific activities for a particular
                   type of acquisition process. For each activity, the
                   supporting information exchanges, information sources,
                   and roles and controls are documented.

  Agency Back      Procurement and finance applications maintained by
  --Office         individual agencies or bureaus to handle day-to-day
  Applications     operations.

  ASBIE            **Association Business Information Entity** - A
                   Business Information Entity that represents a complex
                   business characteristic of a specific Object Class in
                   a specific Business Context. It has a unique Business
                   Semantic definition. An Association Business
                   Information Entity represents an Association Business
                   Information Entity Property and is associated to an
                   Aggregate Business Information Entity, which describes
                   its structure. An Association Business Information
                   Entity is derived from an Association Core Component.

  Authentication   The process of identifying an individual, usually
                   based on a username and password. Authentication
                   merely ensures that the individual is who he or she
                   claims to be, but says nothing about the access rights
                   of the individual

  Authorization    The process of giving individuals access to system
                   objects based on their identity. For example, system
                   administrators have authorized access to data that
                   regular users do not.
  -----------------------------------------------------------------------

+---------------+------------------------------------------------------+
| BIE           | **Business Information Entity (BIE) --** A piece of  |
|               | business data or a group of pieces of business data  |
|               | with a unique Business Semantic definition. A        |
|               | Business Information Entity can be a Basic Business  |
|               | Information Entity (BBIE), an Association Business   |
|               | Information Entity (ASBIE), or an Aggregate Business |
|               | Information Entity (ABIE). There are three different |
|               | categories of Business Information Entities:         |
|               |                                                      |
|               | 1.  Basic Business Information Entity                |
|               |                                                      |
|               | 2.  Association Business Information Entity, and     |
|               |                                                      |
|               | 3.  Aggregate Business Information Entity.           |
|               |                                                      |
|               | The most primitive of these is the **Basic Business  |
|               | Information Entity (BBIE).** A Basic Business        |
|               | Information Entity is a Basic Core Component used in |
|               | a specific Business Context.                         |
+---------------+------------------------------------------------------+
| Business      | An IAE Business Area \--the Business Partner Network |
| Partner       | is the business area for the trading partners for    |
| Network       | the government and, at its core, is the Central      |
|               | Contractor Registration (CCR) system.                |
+---------------+------------------------------------------------------+
| Business Term | Business terms are commonly recognized words that    |
|               | are more appropriately used as XML element names,    |
|               | rather than the often-esoteric ISO/IEC 11179         |
|               | conventions. Business terms improve the readability  |
|               | of schemas and instances, while the ISO/IEC 11179    |
|               | names provide more precise and structured semantics. |
+---------------+------------------------------------------------------+
| CCR           | Central Contractor Registration (CCR) system is a    |
|               | single data entry system for vendor information      |
|               | collection and validation that can be shared with    |
|               | agency contract writing systems.                     |
+---------------+------------------------------------------------------+
| CIOC XDG      | Chief Information Officers Council XML Developer's   |
|               | Guide                                                |
+---------------+------------------------------------------------------+
| COI           | Community of Interest                                |
+---------------+------------------------------------------------------+
| CORE.gov      | **Component Organization and Registration            |
|               | Environment** - the government source for business   |
|               | process and technical components. CORE.GOV is the    |
|               | place to search for and locate a specific component  |
|               | that meets your needs, or to find components you can |
|               | customize to meet your unique requirements. You can  |
|               | also recommend components for inclusion in CORE.GOV. |
+---------------+------------------------------------------------------+
| Constraints   | Restrictions placed on data values. For example,     |
|               | text strings can be constrained to minimum and       |
|               | maximum number of characters. Integers can be        |
|               | constrained to a range of values. Text strings can   |
|               | also be constrained to a fixed set of choices (as in |
|               | code lists, also known as enumerations).             |
+---------------+------------------------------------------------------+
| Core          | A set of universal components that are contextually  |
| components    | neutral and can be used across all domains to        |
|               | express semantics of common business concepts.       |
+---------------+------------------------------------------------------+
| DOD           | A Department of Defense Analysis of the Procurement  |
| End-to-End    | processes resulting in the development of Process    |
| Procurement   | Model and Systems Maps published on March 31, 1999   |
| Analysis      |                                                      |
+---------------+------------------------------------------------------+
| DTD           | Document Type Definition. DTD technology predates    |
|               | XML Schema. DTDs are models of XML documents, but    |
|               | they cannot specify data types.                      |
|               |                                                      |
|               | Federal XML guidance indicates that DTDs should      |
|               | *not* be used for new efforts that are               |
|               | data-oriented; use XML Schema instead.               |
+---------------+------------------------------------------------------+

  -------------------- ------------------------------------------------------
  EbXML                ebXML (Electronic Business using eXtensible Markup
                       Language), sponsored by UN/CEFACT and OASIS, is a
                       modular suite of specifications that enables
                       enterprises of any size and in any geographical
                       location to conduct business over the Internet. ebXML
                       provides a standard method to exchange business
                       messages, conduct trading relationships, communicate
                       data in common terms and define and register business
                       processes. See <http://ebxml.org/>

  eMarketplace         An IAE Business Area; eMarketplace will provide market
                       research and on-line purchasing capabilities for
                       buyers and sellers.

  FEAPMO               Federal Enterprise Architecture Program Management
                       Office, which releases the various Reference Models
                       (RMs), the source of governance for much of these
                       guidelines; see PRM, BRM, SRM, DRM, and TRM. See
                       [http://feapmo.gov](http://feapmo.gov/)

  Federal Registry     A single logical entry point for accessing reusable
                       components potentially located in different physical
                       locations, such as in individual agency databases or
                       repositories.

  IDEF                 IDEF was (derived from the Structured Analysis and
                       Design Technique) is a method designed to model the
                       decisions, actions, and activities of an organization
                       or system. IDEF modeling identifies the Inputs,
                       Controls, Outputs, and Mechanisms (ICOMs) of a system.

  Information Exchange As defined for IAE: The exchange of information
                       between a person or system and other systems.
                       Information exchanges support specific activities of
                       the acquisition process.

  Intra-governmental   An IAE Business Area whose goal is to transform
  Transactions (IGT)   intra-governmental ordering and billing, reduce
                       payment and collection problems, and improve revenue
                       and expense elimination process for preparing
                       consolidated financial statements.

  ISO/IEC 11179        Information Technology -- Specification and
                       Standardization of Data Elements is a 6-part ISO
                       standard providing a framework and methodologies for
                       developing, documenting, and registering standard data
                       elements. The [ISO
                       11179](http://metadata-stds.org/11179/) standard is a
                       multipart standard that includes the following parts:
                       Parts: 1. Framework, 2. Classification, 3. Registry
                       Metamodel and Basic Attributes, 4. Formulation of Data
                       Definitions, 5. Naming and identification principles,
                       and 6. Registration. \[More formally, this is called
                       ISO/IEC 11179, for International Organization for
                       Standardization/International Electrotechnical
                       Commission.\]

  ISO 7273             ISO standard data elements included intended to
                       facilitate interchange of data in international trade.
                       These standard data elements can be used with any
                       method for data interchange on paper documents as well
                       as with other means of data communication.

  JFMIP                Joint Financial Management Improvement Program was a
                       joint and cooperative undertaking of the U.S.
                       Department of the Treasury, the General Accounting
                       Office, the Office of Management and Budget, and the
                       Office of Personnel Management working in cooperation
                       with each other and other agencies to improve
                       financial management practices in government. Its work
                       has transferred to the CFO Council. See
                       <http://www.jfmip.gov/jfmip/> .
  -------------------- ------------------------------------------------------

+---------------+------------------------------------------------------+
| Namespace     | In XML, a namespace is a conceptual space to which   |
|               | element and attribute names may be assigned. Using   |
|               | namespaces prevents name collision (ambiguity) when  |
|               | the same element name appears in multiple XML        |
|               | vocabularies in the same document. A namespace is    |
|               | associated with a URI (Uniform Resource Identifier)  |
|               | which is either a URL (Uniform Resource Locator)     |
|               | such as http://www.w3.org/2001/XMLSchema or a URN    |
|               | (Universal Resource Name) like urn:us:gov:gsa:iae.   |
+---------------+------------------------------------------------------+
| OASIS         | Organization for the Advancement of Structured       |
|               | Information Standards.                               |
|               |                                                      |
|               | OASIS is a not-for-profit, global consortium that    |
|               | drives the development, convergence and adoption of  |
|               | e-business standards.                                |
+---------------+------------------------------------------------------+
| Object Class  | A component of the name of a Core Component or       |
| Term          | Business Information Entity which represents the     |
|               | Object Class to which it belongs.                    |
+---------------+------------------------------------------------------+
| Partner       | Applications which provide data to and interoperate  |
| Service       | with the IAE but are not managed by the IAE Program  |
|               | Management Office.                                   |
+---------------+------------------------------------------------------+
| Payload (XML) | Protocols and frameworks such as SOAP,               |
|               | [BizTalk](http://www.biztalk.org/), and              |
|               | [ebXML](http://www.ebxml.org/) use XML to mark up    |
|               | message header information necessary for binding,    |
|               | reliable messaging, and security. The term           |
|               | '*payload'* refers to the XML being transmitted that |
|               | contains the actual business information             |
|               | communicated.                                        |
+---------------+------------------------------------------------------+
| Portal        | The Web portal services layer is responsible for the |
| Services      | delivery of all applications, services, and data to  |
| Layer         | the user communities accessing the portal. This      |
|               | layer also provides Web portal services (for         |
|               | example, security, aggregation, single sign-on, and  |
|               | delegated administration services), communication    |
|               | services, policy management services, and user       |
|               | management services.                                 |
+---------------+------------------------------------------------------+
| Property Term | A semantically meaningful name for the               |
|               | characteristic of the *Object Class* that is         |
|               | represented by the *Core Component Property*. It     |
|               | shall serve as basis for the *Dictionary Entry Name* |
|               | of the *Basic* and *Association Core Components*     |
|               | that represents this *Core Component* *Property*.    |
+---------------+------------------------------------------------------+
| Qualifier     | A word or group of words that help define and        |
| Term          | differentiate an item (e.g. a *Business Information  |
|               | Entity* or *a Data Type)* from its associated items  |
|               | (e.g. from a *Core Component*, a *Core Component     |
|               | Type,* another *Business Information Entity* or      |
|               | another *Data Type*).                                |
+---------------+------------------------------------------------------+
| R             | The type of valid values for a Basic Core Component  |
| epresentation | or Business Information Entity. This is similar to a |
| Term          | data type but may convey business context (e.g.,     |
|               | Amount).                                             |
+---------------+------------------------------------------------------+
| Shared        | Applications that are managed and coordinated        |
| Systems       | through the Integrated Acquisition Environment.      |
|               | []{.mark}                                            |
+---------------+------------------------------------------------------+
| SME           | Subject Matter Expert \[term sometimes used for      |
|               | Small- and Medium-sized Enterprise\]                 |
+---------------+------------------------------------------------------+
| Standard      | As defined in OMB Circular No. A-119:                |
|               |                                                      |
|               | \(1\) Common and repeated use of rules, conditions,  |
|               | guidelines or characteristics for products or        |
|               | related processes and production methods, and        |
|               | related management systems practices.                |
|               |                                                      |
|               | \(2\) The definition of terms; classification of     |
|               | components; delineation of procedures; specification |
|               | of dimensions, materials, performance, designs, or   |
|               | operations; measurement of quality and quantity in   |
|               | describing materials, processes, products, systems,  |
|               | services, or practices; test methods and sampling    |
|               | procedures; or descriptions of fit and measur3ements |
|               | of size or strength                                  |
+---------------+------------------------------------------------------+
| Standard      | An exchange of information with one or more systems  |
| Transactions  | following agreed upon business rules and using       |
|               | standard data elements                               |
+---------------+------------------------------------------------------+
| Standard      | The IAE Standard Vocabulary will provide agencies    |
| Vocabulary    | and vendors that develop and support procurement     |
|               | applications a standard vocabulary for acquisition   |
|               | related data elements. The standard vocabulary will  |
|               | facilitate consistent and efficient exchange of data |
|               | between systems within IAE and external to IAE. The  |
|               | IAE Standard Vocabulary is the aggregate of all      |
|               | interoperable data elements that are passed          |
|               | throughout the environment via Standard              |
|               | eTransactions.                                       |
+---------------+------------------------------------------------------+
| UBL           | Universal Business Language is intended to become an |
|               | international standard for electronic commerce       |
|               | freely available to everyone without licensing or    |
|               | other fees. The OASIS UBL TC (Technical Committee)   |
|               | is developing 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.                                             |
+---------------+------------------------------------------------------+
| UN/CEFACT     | United Nations Center for Trade Facilitation and     |
|               | Electronic Business - An organization of government  |
|               | and industry representation from around the world    |
|               | working to simplify world trade.                     |
+---------------+------------------------------------------------------+
| TBG 17        | A workgroup of the Trade and Business Process Group  |
|               | of UN/CEFACT. The purpose of the project is to take  |
|               | responsibility for ensuring the consistency and      |
|               | harmonisation of Business Process models and Core    |
|               | Components across business domains and sectors by    |
|               | developing a concise and well-defined library of     |
|               | business terms and business data semantic            |
|               | definitions for the structuring of data exchanges in |
|               | a syntax neutral manner.                             |
+---------------+------------------------------------------------------+
| Vendor        | Non Federal applications; usually of companies doing |
| Systems       | business with the Federal Government.                |
+---------------+------------------------------------------------------+
| W3C           | The World Wide Web Consortium is a vendor            |
|               | consortium, not an accredited standards body,        |
|               | however, its products have such a strong influence   |
|               | over commercial software implementations that its    |
|               | work must take precedence over even accredited       |
|               | standards bodies for matters related to the WWW.     |
+---------------+------------------------------------------------------+
| Web service   | A Web service is a software system designed to       |
|               | support interoperable machine-to-machine interaction |
|               | over a network.  It has an interface described in a  |
|               | machine-processable format  (specifically WSDL).     |
|               | Other systems interact with the Web service in a     |
|               | manner prescribed by its description using           |
|               | SOAP-messages, typically conveyed with HTTP          |
|               | (Hypertext Transfer Protocol) using an XML           |
|               | serialization in conjunction with other XML-related  |
|               | standards. In simpler terms, a Web service is a      |
|               | programmatic interface that enables application to   |
|               | application communication.                           |
+---------------+------------------------------------------------------+
| XML           | Extensible Markup Language, a general syntax used to |
|               | create domain-specific vocabularies. XML is focused  |
|               | on structure rather than presentation. Examples of   |
|               | XML vocabularies are ebXML, UBL, and XML Schema.     |
+---------------+------------------------------------------------------+

  ---------------- ------------------------------------------------------
  XSD / XML Schema XML Schema. An XML Schema is a data model that defines
                   in detail the structure and data types involved in a
                   XML message (or document). The XML message can be
                   validated against the XML Schema. XML Schemas express
                   shared vocabularies and allow machines to carry out
                   rules made by people. They provide a means for
                   defining the structure, content and semantics of XML
                   documents

  XSLT             Extensible Stylesheet Language Transformations, a way
                   to convert XML to HTML, text, or different XML. For
                   example, XSLT can be used to map IAE Standard
                   Vocabulary to an organization's shared system's XML
                   vocabulary or to EDI.
  ---------------- ------------------------------------------------------

# **Appendix F: References** {#appendix-f-references .unnumbered}

+-----------------------+----------------------------------------------+
| FEA Data Reference    | Data Reference Model, Volume 1, Version 1.0  |
| Model                 | from the Federal Enterprise Architecture,    |
|                       | released September 2004. Available from,     |
|                       |                                              |
|                       | <http                                        |
|                       | ://www.whitehouse.gov/omb/egov/a-5-drm.html> |
+-----------------------+----------------------------------------------+
| ISO/IEC 11179 -- Part | <http://                                     |
| 5                     | isotc.iso.ch/livelink/livelink/fetch/2000/24 |
|                       | 89/Ittf_Home/PubliclyAvailableStandards.htm> |
| Information           |                                              |
| technology \--        |                                              |
| Specification and     |                                              |
| standardization of    |                                              |
| data elements \--     |                                              |
| Part 5: Naming and    |                                              |
| identification        |                                              |
| principles for data   |                                              |
| elements              |                                              |
+-----------------------+----------------------------------------------+
| Universal Business    | <http://www.oasis-op                         |
| Language (UBL),       | en.org/committees/tc_home.php?wg_abbrev=ubl> |
| Version 1.0           |                                              |
+-----------------------+----------------------------------------------+
| UN/CEFACT Core        | <http://www.                                 |
| Components Technical  | unece.org/cefact/ebxml/CCTS_V2-01_Final.pdf> |
| Specification,        |                                              |
|                       |                                              |
| Part 8 of the ebXML   |                                              |
| Framework;            |                                              |
|                       |                                              |
| 15 November 2003,     |                                              |
| Version 2.01          |                                              |
+-----------------------+----------------------------------------------+
| TBG-17: UN/CEFACT     | <http://www.d                                |
| Trade and Business    | isa.org/cefact-groups/tbg/wg/tbg17_main.cfm> |
| Process Group,        |                                              |
| Version 2.01          |                                              |
+-----------------------+----------------------------------------------+
| IAE Summary XML       | Visit                                        |
| Guidance,             | [ht                                          |
| 2-February-2004,      | tp://acquisition.gov](http://egov.gsa.gov/), |
| Version 1.1           | click About IAE link, and then "IAE Summary  |
|                       | XML Guidance V. 1.1, \[2/4/04\]".            |
+-----------------------+----------------------------------------------+
| Universal Business    | <http://www.oasis-op                         |
| Language (UBL) Naming | en.org/committees/tc_home.php?wg_abbrev=ubl> |
| and Design Rules,     | \[archive copy :                             |
| 15-November-2004,     | <htt                                         |
| Version 1.0           | p://xml.coverpages.org/UBL-NDRv10-Rev1c.pdf> |
|                       | \]                                           |
+-----------------------+----------------------------------------------+
| UN/CEFACT XML Naming  | <http://www.dis                              |
| and Design Rules.     | a.org/cefact-groups/atg/downloads/index.cfm> |
| Draft 1.1.            |                                              |
| 14-January-2005.      | \[archive copy :                             |
|                       | <http://xml.coverpa                          |
|                       | ges.org/ATG2-NamingAndDesignRules200501.pdf> |
|                       | \]                                           |
+-----------------------+----------------------------------------------+
| Department of the     | <http://www.doncio.navy.mil/>                |
| Navy XML Naming and   |                                              |
| Design Rules, Final   | \[archive copy:                              |
| Version 2.0, January  | <http://xml.c                                |
| 2005                  | overpages.org/DON-XML-NDR20050127-33942.pdf> |
|                       | \]                                           |
+-----------------------+----------------------------------------------+

[^1]: An XML Name Token is a string that begins with a letter and
    contains only certain characters. In particular, spaces and
    underscores are not permitted in a Name Token.