IAE Standard TransactionsVersion 2.0

hystericalcoolMobile - Wireless

Dec 10, 2013 (3 years and 7 months ago)

143 views










IAE

Standard

Transactions

Version

2.0



September 29, 2005

































Table of Contents




Table of C
o
ntents
...........................................................................
.

i

List

of

Figure
s
.....................
.........................................................
.

ii

1
.

Executive Summary
.................................................................
.

1

1.1 Stakeholders & Benefits
...........................................................
.

3

2
.

The

Integra
ted

Acquisition

Environmen
t

......................................
.

5

2.1

eMarketplac
e

.......................................................................
.

5

2.2 Business Partner Network (BPN)
................................................
.

6

2.3

A
cquisition

Information

Reporting

(AIR
)

......................................
.

6

2.4

Standard

Transaction
s

............................................................
.

7

3
.

Standard Transactio
n
s Details

...................................................
.
.

8

3.1 What are Standard Transactions?

...............................................
.

8

3.2 The IAE Standard Transactions Process

........................................
.

8

3.3 Developing IAE Standard Vocabulary

....................................
.....
.

9

3.4

Standard

Transactions

Voca
bu
lary,

Version

1.0

and

Version

1.
1

..........
.
11

3.5 Data Element Renaming Process for Standard Transactions 2.0

...........
.
12

3.6 Alphanumeric, String or Text?
..................................................
.
1
4

3.7

Boolean

Value
s

....................................................................
.
15

3.8

Length

vs.

MaxLengt
h

...........................................................
.
15

3.9 Dates and Time

.....................................................
..............
.
15

3.10

Currency

Amount
s
..............................................................
.
16

3.11 Identifiers vs. C
o
des

............................................................
.
16

3.12 When Other Elements are Necessary
...................
......................
.
17

3.13 Acronyms and Abbreviations

.................................................
.
18

3.14

Code

Lists

Gap

Analysis

and

Recommendation
s
...........................
.
18

3.15

XML

Guidance

for

IAE:

Naming

and

Design

Rule
s
.............
...........
.
19

3.16

Maintaining

and

Expan
d
ing

Standard

Transaction
s

.......................
.
20

Appendix A: Data Element Standardization Process

.............................
.
21

Appendix

B:

Creating

ISO/IEC

11179

Name
s

...................................
...
.
25

Appendix C: Key Acquisition Scenarios
............................................
.
28

Appendix

D:

IAE

Acronym
s

..........................................................
.
29

Appendix E: Glossary of Terms

............................................
..........
.
30

Appendix F: References
................................................................
.
36
















IAE

S
t
andar
d

Transactio
n
s

V2.
0

-

i

-


List

of

F
i
gures




Figure 1
-

The IAE Conceptual Architecture

..................................
........
.

2

Figur
e

2



Standard

Transaction
s

Process

.............................................
.

9

Figure

3

-

Inputs

into

buildin
g the Standardized Vocabulary

.....................
.
10


























































IAE

S
t
andar
d

Transactio
n
s

V2.
0

-

i
i

-


1
.

Executive

Summary



The Integrated Acquis
i
t
ion Environme
n
t (IAE) is one of 24 e
-
Government
initiatives in the President’s Management Agenda. The IAE value proposition
recognizes

acquisition

has

common

function
s
,

which

can

be

consolidated through

a

multi
-
agency,

shared

service
s e
n
vironment. Figure 1 shows the conceptual
architecture for IAE. The v
i
sion

is

to

create

a

secure

business
environment

that

facilitates

and

su
pport
s

cost
-
effective

acquisition

of

goods

and
services

in

support

of

mission

performance.





















































IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

1
-







Figure 1
-

The IAE Conceptual Architecture
























IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

2
-




The target audie
nce f
o
r this document is the Federal Acquisition
Community that includes Federal A
g
ency Acquisition, Information
Management, and Finance organizations as well as private companies providing
acquisition

and

financial

commercial
-
off
-
th
e
-
s
helf or custom softw
a
r
e to federal
agencies.


The object
i
ves of this document are to:


1.

Introduce and describe IAE Standard Transactions and its role in
enabling

the

interope
r
ability

of

systems

across

the

IAE
environment;


2.

Explain

th
e
role

of

Standards

i
n es
tablishing

in
teroper
a
bility

in

a
shared systems environment;


3.

Describe t
h
e process used to dev
elop

and

maintain

IAE

Standard

Transactions;


4.

Refine def
i
nitions, data eleme
nt

names

and

constraints

of

the
Standard

Vocabulary

based

on

analy
sis of the existing interfa
ces for
four of the shared IAE systems tha
t

were included in the Standard
Transactions

v1.1



Ce
ntral

Contractor

Registration

(CCR),

Federal
Procurement

Data

Sy
s
tem



Ne
xt Generation (FPDS
-
NG), and
Federal Registration
(
FedReg). Although as per OMB’s deci
sion,
Intragovernmental

Transaction

Exchan
ge

(IGTE)

is

no

longer

being
used by the Federal Agencies, we decided to include the data
elements.

In

addition,

include

de
finitions, data element names and
constraints of the Standard Vocab
ulary

based

on

analysis

of

the
existing

interfaces

for

the

remaining shared IAE systems


Online
Representations

and

Ce
rtifications

Application

(ORCA),

Electronic
Subcontracting Reporting System (eSRS), E
x
cluded Parties Listing
System (EPLS), Federal Technical Data System (FedTe
DS), Wage
Determination

On
-
Line

(WDOL),

Pu
rchase

Card

Information

(P
-

CARD) planned to be included in Federal Procurement Data
System


Next Generation (FPDS
-
NG) and Federal Business
Opportunities (FBO).


1.1 Stakeholders & Benefits


The success of IAE St
andard Transac
t
ions

a
nd

their

ab
i
lity

to

sup
p
ort
improved

acquisition

processes

is

d
e
pendant

on

o
ngo
i
ng

inv
o
lvement

and

support

from

the

acquisition

co
mm
unity.

Table

1

outlines

the

maj
o
r
stakehold
e
rs

and

benefits

of

IAE

Standard

Transaction
s
for

the

acqu
isition
community.





IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

3
-




Table 1
:
M
a
jor stakeholders and benef
its of the IAE Standard Transaction



Stake
h
ol
d
e
r


Benefits

Fede
r
al

Increas
e
d in
t
eroperabilit
y

among

sys
t
e
ms

in

I
A
E

that

support

en
d
-
to
-

Ac
q
ui
s
i
t
ion

end

processes

Community

G
rea
t
er

fle
x
i
b
ili
t
y

to

incor
p
ora
t
e new/c
h
ange
d

r
e
q
u
i
r
emen
t
s or
capab
i
li
t
ies

Fede
r
al

One

common

appr
o
a
c
h

a
n
d

vocabular
y

fo
r

interacti
n
g

with

IAE

s
h
ared

Fina
n
c
e

systems

Community

Less

t
i
m
e

and

cost

to

implement

new/changed

fi
nan
c
ial

integration
requirements

Fede
r
al

Re
d
uc
t
ion

in

cos
t
/
t
ime
to
develop

and

main
ta
in

sys
t
ems

Information

Technolog
y

Robust,

se
c
u
r
e,

ma
n
a
g
e
d

integratio
n

e
n
vironment

Community

Increas
e

staf
f

experienc
e

a
n
d

expertise

w
i
th

modern

d
a
ta
s
t
an
d
ard
iz
a
tio
n an
d

in
t
eg
r
a
t
ion
t
echn
o
lo
gies


A
l
ignment

w
i
th

Federa
l
Enterpr
i
s
e Ar
c
h
i
t
ec
t
ure

(F
E
A)
D
a
ta

R
e
fe
r
ence

Mode
l

(
D
R
M
)

Vendo
r
s

One

common

appr
o
a
c
h

a
n
d

vocabular
y

fo
r

interacti
n
g

with

IAE

s
h
ared
systems


Less

t
i
m
e

an
d

cost

to

resp
o
nd

to

new/c
h
ange
d

Fe
d
e
ral

Government
req
uirements


Less

t
i
m
e

an
d

cost

to

intro
d
uce

new/c
h
anged

c
a
pa
b
i
lities


Incre
a
sed

common
ali
ty

between

how

they

i
nter
a
ct

with

the

Feder
a
l
Government

and

th
e
i
r

ot
h
er

customer
s

(Stat
e

&

Lo
c
al,

In
d
u
str
y
,
In
t
erna
t
ion
a
l)

COT
S

Only

need

t
o

support

one

common

a
ppro
a
c
h

a
nd

voc
a
bul
a
ry

in

their

Provide
r
s

product
s

fo
r

integration

w
ith

IAE

s
h
are
d

systems


Incre
a
sed

c
a
p
a
b
i
l
i
t
y

f
o
r

soph
is
t
i
c
a
ted

i
n
tegr
a
t
i
on

w
i
t
h

IAE

sh
ar
ed
systems

an
d

end
-
to
-
end

p
r
ocesses


Increas
e
d c
o
mmonali
t
y

b
e
tw
een so
l
u
t
i
o
n
s dev
e
lope
d

for

Fede
r
a
l
Gov
ernment

and

othe
r

customers

(Stat
e

&

Lo
c
a
l,

Industry,
In
t
erna
t
ion
a
l)













IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

4
-


2
.

The

I
n
t
egra
t
e
d

Acq
u
isition

Environment

The

Presi
d
ent’s

Management

Agenda

on

E
-
Government

established

the
IAE

initi
a
tive

in

2001

to

d
evelop

a

secur
e

business environment th
a
t facilitates
and supports cost
-
eff
e
ctive acquisition
of

goods

and

services

in

support

of
mission

performance

throughout

the

gov
e
rnment. The Office of Acquisition
Services, with the General Services Administration a
s the Managing Partner,
leads the IAE development. Over 300

representatives from 65 agencies have
participat
e
d

in

IAE

w
orking

groups

t
o help define and implement the IAE
vision.


Federal

agencies

have

been

actively

using

electronic

commerce

and
working to
ward increasing efficiencie
s

within

the

gov
e
rnment’s

acquisition
process

in

response

to

legislatio
n
and

policy

changes.

However,

lack

of
coordination

among

agencies

has

led

to

duplication

of

e
ffort,

stove
-
piped
information

systems,

lack

of

data/mess
aging

s
tandards,

lack

of

scale,

and
insufficient leverage.


The

premise

of

a

government
-
wide

Integrated

Acquisi
t
ion

En
v
ir
o
nment

is
that it be more succ
e
ssful and cost
-
eff
e
c
tive

than

stand
-
alone

agency

processes.


The

IAE

will

leverage

the

Inte
r
net

and

the

t
e
chnol
ogy

infrastructure
currently

existing

in

government

agencies

and

will

also

leverage

existing

and
emerging

government

capabilities.

I
A
E

will

be

built

on

the

framework

of

a
shared

services

model

where

no

single organization has "ownership", rather the
servi
ces

are

a

constellation

of

c
a
pabilitie
s built on standards and accessible over
the

Inte
r
net.

The

IAE

will

serve

as

the

focal

point

for

v
arious

services

and

will
provide

the

capabilities

that

can

b
e
leveraged

by

the

acquisition

c
ommunity
stakehold
e
rs

to

co
nduct

b
usiness

across

the

government.



The

major

elements

of

IAE

inc
l
ude four bro
a
d Business Areas:




eMarketplace



Business
P
artner Network (BPN)



Acquisition Information Reporting (AIR)



Standard

Transactions



Each of these is discussed below.


2.1

eMarketplace


eMarketpl
ac
e will provide market research capabilities for buyers and
sellers.

Initially,

it

est
a
blished

a

government

database

of

existing

interagency
contracts, to facilitate discovery and e
n
able smarter business decisions. This
Interage
n
c
y

Contract

Directory

(ICD)

wil
l
be

incorpor
a
ted

in

the

FPDS
-
NG

and





IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

5
-

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

g
o
vernment

sources (contracts and other agencies
awardees)
i
n

one place.


The longer
-
term vision is to evolve t
owards

integration

of

e
-
catalogs

in

an
effort to eliminate duplicate requi
rements on our vendors and fa
cilitate
integration with back office finance and acquisition sys
t
ems.


2.2

Business

Partner

Network

(BPN)


The Business Partner Network is the business area for
t
h
e trading partners
for

the

go
ve
rnment



a

one
-
stop
-
sho
p

for

registering

and

accessing

vendo
r
information. The BPN includes:




Central

Contractor

Registration

(
CCR)

system

that

provides

a

single
data

entry

system

for

vendor

in
f
ormation

c
ollection

and

validation.
CCR

maintains

the

co
re
vendor

i
d
entification

key

(using

DUNS)

and
Electronic Funds
Transfer informa
t
ion that is used by all systems
across

the

government.

As

such,

CCR

data

is

shared

both

with

ag
e
ncy
contract

writing

systems,

and

wit
h all government systems that use
vendor

in
f
ormation

(e.g.

Agency

financial

systems);




Integration

with

other

shared

vendor
-
information

syst
em
s

in

the
Government to provide a single sou
r
ce for all information on a
ve
ndor
to improve competitive sourcing and enable better bus
i
ness decisions.
Examples include: Online Representations and Certifications
Applicat
ion

(ORCA)

for

vendors,

the

database

for

the

required
standard representations and certifications required in every
solicitation;

Federal

Registration

(
F
edReg);
a
n
d the Excluded Parties
Listing

Sy
s
tem

(EPLS);

and




Validat
i
on

of

data

with

third

p
arties wh
erever possible such as
Taxpayer Identificati
o
n Number w
i
th

IRS;

DUNS

number

validation
with

Dun

and

Bradstreet;

8(a),

H
U
BZone

and

Small

Disadvantag
e
d
Business s
t
atus validation with S
B
A.


2.3 Acquisition Info
r
mation Reporting (AIR)


The IAE Acquisition
Information R
e
porting (AIR) bus
i
ness area is the
focal

point

for

all

acquisition

rep
o
rtin
g across IAE shared and partner systems.
A

government
-
wide

procureme
n
t

reporting

and

business

intellig
e
nce

capability
is
critical to understanding purchas
i
ng activity
across the government. This
allows

the

government

to

devel
o
p

sourcing

strategies

including

o
pportuniti
e
s

to pool

spen
d
,

negotiate

government
-
wi
d
e

contracts,

and

identify

purchasing trends:






IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

6
-



The Federal Procuremen
t Data Sys
t
em


Next Generation (FPDS
-
NG)
provides

the

initial

fo
u
ndati
o
n

for

AIR.

FPDS
-
NG

is

the

central

point
for

consolidated

collection

of

st
a
tistical

and

management

information
related

to

government

acquisitions.

It

provides

timely

management
data

a
nd

tailored

reporting

capa
b
il
ity of real
-
time information in an
automated environment. It also eliminates the need for dozens of
feeder sys
t
ems; and




AIR

will

expand

on

FPDS
-
NG

by

adding

reporting

cap
a
bilities

for
information in other IAE systems, as fea
sib
l
e. Examples include
Purchase

card

information

from

the

banks

and

interag
e
ncy

contra
c
ts
directory information.





2.4 Standard Transactions


IAE

is

critically

dependant

on

interoperability

of

the

shared,

agency,

and
vendor systems in the acquisition

e
n
vironment.

Standard

Transactions
establishes standard data elements, bus
iness definitions
,

ownershi
p
, behaviors,
and

roles

and

respon
s
ibilities

for

Gove
rnment acquisition data. The “common
language”

provided

by

Standardized

Transactions

is

a

key

enable
r

for

achieving
this needed interoperability. Stan
d
ard Transactions address both what
information

has

to

be

exchanged

amon
g systems (standard data exchanges), and
what

the

information

means

(standard

da
ta element names and s
e
mantics) so
that all systems c
an u
n
derstand each
other.

Without

Standard

Transactions,
every system would need to know how
to speak every other system’s unique
language



and

would

incur

the

relate
d overwhelming complexity, time, and
cost

of

incorporating

new/chang
ed

systems

or

capabi
lities.




























IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

7
-

3
.

Standard Transactions Details


3.1 What are Standard Transactions?


The Standard Transactions define the “common language” used to
support

interoperability:




Between parts of I
AE shared systems;




Between IAE shared systems a
n
d agency back office
a
pplications

(financial,

acquisition
,
program);

and




Between IAE shared systems a
n
d vendor systems.


Standard

Transaction
s
are

composed

o
f
Standardized

Vocabulary

that

defines
the ME
ANING (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

nu
mb
er,

etc)

a
n
d

higher

l
e
vel

cons
tructs

(e.g.,

a

contact

per
s
on

with

th
e
ir
physical
and electronic addresses) needed f
o
r the Information Exc
h
anges.


3.2 The IAE Standard Transacti
o
ns Process


Figure

2

reflects

the

process

for

d
e
veloping

IAE

Standard

Transactions.
The development of the S
tandard Vocab
ulary may be new to many readers


therefore it is discussed below.


A

cross

agency

team

of

procurement,

financ
e
,

policy,

and

information
specialists was establ
i
shed to develop the IAE Standard Transactions. The cross
agency

team

quickly

disco
vered

that

d
espite the governance of the Federal
Acquisition

Regulations,

there

is

ofte
n
signi
f
icant

vari
ab
ility

in

th
e
acquisition
process be
t
ween and sometimes even wit
h
in agencies as a result of agency
implementations.


Using existing work already acco
mplished by the Department of Defense
and

the

Jo
i
nt

Fin
a
nci
a
l

Management

Impro
v
ement

Program

(JFMIP),

the

team
identified 16 key acquisition scenarios applicable to all federal agencies. Each
scenario

documented

the

specific

act
i
vities, information exchang
es, and
information sources
i
n
volved.

















IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

8
-

Figur
e

2



Standard

Transaction
s

Process




IN
I
TIAL

INPU
T
S

DoD

JFMI
P



End
-
to
-
End

A
cq
u
i
s
it
i
on

Stud
y


Pr
o
cu
r
e
m
ent


S
u
bj
e
ct

Mat
t
er

An
a
lysis

Expe
r
ts




ACQ
U
ISI
T
I
O
N PR
O
CESS M
O
DEL

A
g
ency

16

K
e
y

Acquisition

S
c
ena
r
ios

Review

&

M
ajo
r

P
r
oces
s
ses

Valida
t
i
o
n


Sp
e
ci
f
i
c

Activities

&
In
f
o
rm
atio
n

Excha
n
ges


SHARED

DATA

MODEL


I
n
f
o
r
m
a
t
i
on

Dat
a

El
e
m
e
nts


E
x
chan
g
es

F
r
o
m

I
AE

sha
r
ed
sys
t
ems


STAN
D
ARD
T
RANSACTIO
N
S

V
1

Fe
d
e
r
a
l/
Ind
us
tr
y

St
a
nd
a
r
ds
/
G
u
i
da
nc
e

A
g
ency

I
n
f
o
r
m
a
tion

Ex
c
han
g
es

Review

&

Data

Valida
t
i
o
n

I
n
f
or
m
a
ti
on

Busine
s
s

Ele
m
en
t
s


Sou
r
ces

Rules


Foc
u
s
o
n
F
ou
r

Sha
r
e
d

Syst
e
ms



A
g
ency

S
T
ANDARD

TRANSAC
T
I
O
NS

V
1
.1

Review

&

Valida
t
i
o
n

R
e
fine
m
e
n
t

of

V1



S
T
ANDARD

TRANSAC
T
I
O
NS

V
2
.0

Foc
u
s o
n

All Sh
a
re
d

Sys
t
ems




These sce
n
arios were distributed to agencies for review in a November 26,

2002 Memorandum for the Procurement Executive Council. Agency responses
were revie
wed, analyzed and used to develop the “Acquisition Backbone
Scenario”

a

representation

of

the

most

co
m
p
lex acquisition scenario that includes
the

majority

of

information

exchanges

disco
vered in all 16 acquisition scenarios.


A

listing

o
f
the

16

scenarios

i
s

included

i
n

Appendix

C
. These sce
n
arios
are available at
http:/
/
acquisition
.
gov/
.


3.3

Developing

IAE

Standard

Vocabulary


The IAE Standard Vocabulary is the
a
ggregation

of

all

the

data

el
em
ents
supporting

the

Infor
m
ation

Ex
ch
anges

n
eeded for interoper
ability of systems

supporting IAE shared processes. Figur
e

3

shows the major inputs that were
used in defining the Standard Vocabulary.










IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

9
-

Figure

3

-

Inputs

into

buildin
g the Standardized Vocabulary









A
cq
u
isiti
o
n

Subject

M
a
tter

Da
ta

fro
m
IAE

E
x
perts

Share
d

IAE

Standar
d

Voca
b
ula
r
y

S
y
stems

Sta
n
da
r
d
N
a
m
e

Data

Standa
r
di
z
at
i
on

Sta
n
da
r
d
D
e
f
i
n
i
t
i
on

E
x
perts

Acqu
i
s
i
tion

Sta
n
da
r
d
F
o
r
m
a
t &

St
r
uctu
r
e

Inf
o
r
m
ation

XM
L Sche
m
a

E
x
changes

X
M
L

E
x
perts




Variou
s

Core

Federal
X
M
L

FEA

Dat
a

IS
O
/IEC

Component
s

UN
/
CEFAC
T

Uni
v
er
s
al

De
v
elopmen
t

Re
f
eren
ce

1117
9

Techn
i
cal

TBG

1
7

Busin
e
ss

Guide
s

Mode
l

(Part

5
)

Spec
i
f
i
cati
o
n

Language


Go
v
ernment Standards


Int
e
rn
a
tion
a
l

St
a
nd
a
rds




The

process

used

for

defining

the

I
AE

Standard

Vocabulary

is

based

on
the
general approach defined in the FEA DRM (see

A
p
pendix

A

for details of the
process.) As such, it involves a sophisticated

data

modeling

effort

using

Unified
Modeling

Language

(UM
L),

ISO/IEC

11179

data

element

naming,

Universal
Business Language (UBL), and UN/CEFACT Core Components Technical
Specification

princip
a
ls.

This

is

followed

by

XML

Sch
e
ma

development

to

de
fine
the precise structure
o
f Information Exchange payloads. By le
veraging this
approach, IAE:




Builds on the experience and exper
tise

of

the

data

standardization
community;

and




Maximizes

interoper
a
bility

with

oth
er Agency, Federal lines
-
of
-
business,
and

external

(industry,

State

&

Local,

international)

vocabularies
.




The

companion

spreadsheet

entitled

“Standard

Transactions

v2.0

Vocabulary” details the standard data

elements identified for IAE. These
elements

are

based

on

the

information

nee
d
ed

for

existing

interoperability
with

the

I
A
E

shared

systems:

Ce
n
tra
l
C
ontract Registration (CCR), Federal
Procurement Data Sys
t
em


Next

Generation (FPDS
-
NG), Government
Purchase Card (P
-
CARD Info), Federal Registration (Fe
d
Reg), Online
Representations

and

Ce
rtifications

Application

(ORCA),

Federal

Technical
Data

System

(Fed
TeDS),

Federal

Business

Opportuniti
e
s

(FBO),

Excluded




IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

1
0

-

Parties Listing System (EPLS), Electronic Subcontracting Reporting
System (eSRS), Interagency Contracts Directory (ICD) and Wage
Determination

On
-
Line

(WDOL).
Although

Intra
-
Governmental
Transaction

Exchange

(IGTE)

in

no

longer

is

being

used

by

the

Federal
Agencies, we decided to i
n
clude the data elements.


3.4 Standard Transactions Vocabulary, Version 1.0 and Versio
n

1.1


Version

1.0

of

the

Standard

Transactio
n
s
vocabulary

was

defined

in

a

Microsoft

Word

table

included

in

the

doc
u
ment

entitle
d

IAE Standard eTransactions Re
v
iew

Instructions and Forms
, Version 1.
0

(Sept. 30, 2003). The
d
ata element modeling
process w
a
s describe
d

in the related docum
e
nt called

IA
E Standard eTransactions

Version

1.0

Documentation

(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

e
lement

naming



Universal

Business

Language

(UBL)

vers
i
on

0.7,

an

em
erging

standard
from OAS
I
S



UN/CEFACT

Core

Component
s
Technical

Specification

(CCTS)

version

1.9 principles.


Standard

Transaction
s
1.0

contained

257

elements

drawn

from

f
i
ve

IAE

shared
s
ystems: CCR, FPDS
-
NG, FedReg, IGTE, and PPIRS. For each element, we
defined several columns (characteristics
)

based

on

responses

to

data

calls:



Number

(the

identifier

describe
d

below)



XML

Element

Name

(based

on

UBL

conventions)



Basic Information Enti
ty Name (based on ISO/IEC 11179 and CCTS)



An

agreed

upon

definition



Format



Max

Length



Data

constraints,

when

known


Elements were grouped according to severa
l

very broad categories (below). An
identifier

of

the

form

“CCCddd”

was

a
ssigned

to

each

el
ement,

where

“CCC”
was

the

th
r
ee
-
character

abbreviation

fo
r
the

c
ategory

and

“ddd”

was

the

three
-

digit

number

of

the

element

within

that
category.

The

broad

categories

were

as
follows:



ADR = A
d
dress



CON

=

Contact



CTR = Co
n
t
ract



FIN

=

Fin
a
ncial



O
RG

=

Organizati
o
n



PAY

=

Payment





IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

1
1

-



SOC = Socioeconomic



SYS = System



For

example,

an

illustrative

row

of

th
e

Standard Transactions 1.0 v
o
cabulary
appears below:


No
.


XML

B
a
s
i
c I
n
f
or
m
a
t
io
n
E
nt
i
t
y

Defin
ition


Format

Max

C
o
n
s
t
rai
n
t
s

Ele
m
ent

Na
m
e

Len
g
th

Na
m
e

A
DR011

C
o
u
n
t
ry


P
ro
duc
t

Origi
n
_

A
d
d
re
ss
.


T
h
e

n
a
m
e

t
h
a
t
ide
nt
ifies

t
h
e

t
erritorial

division


A
lp
h
a
n
u
m
eric


50

m
inLe
n
g
th
=0,

C
o
u
n
t
r
y.
Te
x
t

(a

c
h
ief

u
n
i
t
of

local

ad
m
i
n
is
t
ra
t
io
n
)

o
f
a

m
ax
L
e
n
g
th
=5
0

co
unt
ry
,
as

part

o
f
a
n
ad
d
re
s
s

of

t
h
e

pro
du
ct
origi
n
.


For

Standard

Transactions

Version

1.1
,
Version

1.0

vocabulary

was

refined

and
published

as

a

table

in

the

doc
u
ment

entit
l
e
d

IAE Standard Trans
actions 1.1

Vocabular
y
,
Version

1.
1

(June 9,
2
005). The
d
a
ta element modeling process w
a
s
described
i
n

the related document called
IAE

Standard

Transactions

Version

1.1

(June 9, 20
0
5).




3.5 Data Element Renaming Proc
e
ss for Standard Transactions 2.0


I
n Standards Transactions 2.0, our focus w
a
s

to

further

refine

the

element

names
that

were

published

in

version

1.1

and

if

necessary,

introduce

additional elements

f
o
r

the

remaining

IAE

share
d systems. Wherever possible, we have chosen
element names that ma
tch eleme
n
ts

from

UBL

1.0

(from

O
ASIS).

In

cases

where elements related to object classes
not

defined

in

UBL,

we

have

drawn

from
the core components in TBG
-
17 vers
ion 2.01 (from UN/CEFACT) whenever
possible. The elements and core c
o
mponents that comprise t
hese two
international standards are located at:



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



http://w
w
w.disa.org/cefact
-
gr
o
u
ps/tbg/wg/tbg17_main.cfm



[At

the

time

of

this

writing,

the

v
alid

link

to

TBG
-
17,

CC

Release

1

version

2.01

spreadsheet was:
http://www.disa.org/cefact
-

groups/tbg/docs/tbg17/TBG%20CC%20Library%20Version%201_081004.xl
s

.]
Elements were grouped according to severa
l

very broad categories (below). An
identifier

of

the

form

“CCCddd
-
x”

was

ass
i
gned to eac
h

element, w
here “CCC”
was

the

th
r
ee
-
character

abbreviation

fo
r
the

c
ategory

and

“ddd”

was

the

three
-

digit

number

of

the

element

within

that

category and “x” represents a unique
Parent XML Element Name (Business Conte
x
t) for a particular data element. The
broad categ
ories were as follows:



ADR = A
d
dress



CON

=

Contact




IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

1
2

-



CTR = Co
n
t
ract



FIN

=

Fin
a
ncial



ORG

=

Organizati
o
n



PAY

=

Payment



PRD = Pr
o
d
uct



PUR = Pu
r
chase Request



SOL

=

Solicitation



SYS = System



WAG

=

W
age

Determination


In Standard Transactions 2.0, data elements were stored in a Microsoft Excel
spreadsheet.

We

kept

the

“Parent

XML

Element

Name”

column

to

provide
hierarchical context. We also merge
d

the

“Max

Length”

and

“Constraints”
columns

into

one

co
l
u
mn

called

“Constrai
nts”. We introduced a “No. (Ver 2.0)”
column and preserved “No.” column from
t
h
e Standard Transactions 1.1 in “No.

(Ver

1.1)”

column

to

facilitate

mapping

fro
m
the

old

n
u
mbers

to

new.

For
example, the sample row above became:


No
. (Ve
r

2
.
0)

No
. (Ve
r

XML

P
are
nt X
M
L El
e
me
nt

B
a
si
c

D
e
f
i
n
i
t
io
n


F
or
m
at

C
o
n
s
t
rai
n
t
s

1
.
1)

Ele
m
ent

Na
m
e

Informatio

Na
m
e

n
E
nt
i
ty

Na
m
e

A
DR013
-
B


A
DR011

C
o
u
n
t
ry

P
ro
duct
Ori
gi
nA
dd
r
ess


P
ro
duc
t

T
h
e

n
a
m
e

t
h
at

A
lp
h
a
n
u
m
eric


m
inLe
n
g
th
=0,

Na
m
e

Origi
n
_

ide
nt
ifie
s
t
h
e

m
ax
L
e
n
g
th
=
5

A
d
d
r
ess
.

t
erri
t
orial

0

C
o
u
n
t
r
y
.

division

(a

Na
m
e

c
h
ief u
n
it

of
local
a
dm
i
n
i
st
ra
t
io
n)
o
f
a

coun
t
ry,

as
part

of

an
a
dd
r
ess
o
f
t
he
produc
t
origin.



There are several points to note from this example:



1.

The or
der of rows is now based on th
e

“No.

(Ver

2.0)”

column;

we

preserved
the “No. (Ver 1.1)” to represent version 1.1 numbering scheme and make
comparison easier. If a new data element was added, only “No. (Ver 2.0)” is
shown

and

“No.

(Ver

1.1)”

is

blank.

2.

The XML Element Name has changed, as has the Basic Information Entity
Name.

This

is

true

for

most

of

the

e
l
ements in the Standard Transactions
vocabulary.

3.

The Parent XML Element Name gives us c
o
ntext, so the XPath to this
particular element would be /
/ProductOriginAddress/CountryName,
denoting

that

the

parent

element

may

its
e
lf

have

a

parent,

grandparent,

etc.

in
the

XML

document

hierarchy.

(For

a quick introduction to XPath, see
http://w
w
w.w3schools.com/xpath/xpath_intro.as
p

.)




IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

1
3

-

4.

The

Constraints

column

reflects

the

maxLength,

no

o
t
her

constr
a
int
information

is

needed

in

this

cas
e
.


As we ex
a
mined each of the elements previously defined in Standard
Transactions 1.1, we reviewed several diffe
r
ent

information

sou
rces

to

determine
the

best

name

and

constraints:



We

reconsidered

the

1.1

Basic

Information

Entity

(BIE)

Name

based

on
our

current

understanding

of

CC
T
S

2.01

and

ISO/IEC

11179,

as

well

as
other

IAE

data

modelin
g

performed

since

2003.



In particular, we r
ec
o
nsidered 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 b
o
rrowed
that (assuming

it was relevant t
o

the definition of our element).



In

other

cases,

TBG
-
17

version

2.01

had

a

more

appropriate

match,

so

we
borrowed

that.

How
e
ver,

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

el
em
ent

as

given

in

the

r
e
sponse

to

ou
r

early

data

call

since

the
entry

might

reveal

details

that

w
oul
d cause

us

to

alter

our

eleme
n
t

name,
definition,

format

and/or

constraint
s. For example
, if an element was
previously

indicated

as
Boolean

(a
n “Indicator”

in

CCTS),

but

the

data
dictionary indicated it w
a
s

a

single

character

value

(e.g.,

‘Y’,

‘N’,

or

‘x”),
then

we

changed

the

f
ormat

accordingly

to

Alphanumeric

of

length

=

1.



For

common

Pro
perty

Terms,

we

have

selected

specific

maxLength
constraints. For example:

o

Telephone,

FAX

=

25

characters

o

Name = 75 characters (for eleme
n
ts for which a name is not
subdivided into 2 or 3 fields)

o

Given

=

25

characters
o

Middle = 25 characters
o

Fami
ly = 25 characters

o

CountryName = 50 characters


3.6 Alphanumeric, String or Text?


The

definition

of

the

term

“Alph
anumeric”

differs

de
p
ending

on

the
informati
o
n

technol
o
gy

application.

Rathe
r
than

simply

the

set

of

all

letters

and
digits, we have chose
n the broader definition as per WordNet:

“character

set

that

includes

letters

an
d
digits

and

punctuation

marks”

and

also
spaces.

Many

developers

may

think

of

thi
s as “String” (Java) or “Text” (CCTS).








IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

1
4

-

3.7 Bool
ean Values


IAE systems presently implement many different value pairs to represent
Boolean

values:

{0,

1},

{'N',

'Y'},

{
"
no",

"yes"}, {"true", "false"}, etc. S
i
nce our goal is
to

create

XML

Schema

to

support

standard

transaction
s
,

we

need

to

make

it

part

of

migration

path

for

s
ystems

to

use

the

value

set

that

is

built
-
in

to

the

XML
Schema

primitive

type,

xsd:boolean.

The

lega
l literal values are: {0, 1, false, true}.
The canonical values
a
re simply {false, tru
e
}.

Therefore,

please

do

not

use

yes/no
varian
ts. See
http://
w
ww.w3.org/TR/xmlschema
-
2/#boolean


3.8

Length

vs.

MaxLength


In

the

accompanying

Standard

Tra
n
saction
s
2.0

Vocabulary

spreadsheet,
we have used term “length” to indicate
that

the

data

v
a
lue

has

a

fixed

length,
whereas “maxLength” denotes t
he upper limit
of

an

element

of

variable

length.

If

“MinLength”

is

given,

it

generally

indi
cates that it is a mandatory element.


3.9 Dates and Time


A wide variety of date formats are used in IAE shared systems

(MMYYYY,

MMDDYY,

MMDDYYYY,

YYYYMM
DD,

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 e
v
en

included?

The

answers

v
a
ry

widely
across sys
t
ems. In the accompanying

Standard Transactions 2.0 Vocabulary
sp
readsheet, we have tried to capture the
existing

date

representati
o
ns

in

the
Constraints column f
o
r each eleme
n
t of Format (datatype) Date.


However, system ste
w
ards should ini
ti
a
te

analysis

to

de
termine

the
impact

of

shifting

to

a

more

unifor
m 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

c
are about time of day, use DateType. XML
instance examples of the two types follow:



<shipDat
e
>1999
-
05
-
21</shipDate>



<cbc:Ac
tualDeliveryDateTime>2003
-
02
-

14T13:30:00</cbc:ActualDeliveryDateTime>


In

the

first

example,

note

that

th
e
W3C

XML

Schema

xsd:date

format

is
YYYY
-
MM
-
DD
;

the

hyphens

are

required.

In

t
h
e second example, the line break
after

"02
-
"

is

strictly

for

printed

r
e
adability;

the

XML

must

not

contain

a

newline
here. Also notice that the xsd:dateTim
e

fo
r
mat

uses

t
h
e

letter

‘T’

as

the

time
separator; no other character is permitted, so the format is

YYYY
-
MM
-

DD
T
HH:MM:SS
.

(Actually,

th
e
re

are

additional

details

such

as

t
i
me

zone

and
how to omit optional parts
in

the

W3C

specification.)





IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

1
5

-

This date/time forma
t

is actually an
international

standard

that

pr
e
dates
UBL and XML Schema, ISO 8601:2000. The normative ISO 8601:2000 refere
n
ce is
http://w
w
w.iso.ch/iso/en/Cat
a
logueDetailPage.CatalogueDetail?CSNUMBER

=2678
0

. However, a very useful, free informative

reference

is

located

at
http://w
w
w.cl.cam.ac.uk/~mgk25/iso
-
time.html

.


For the UBL reference, see
http://docs.oasis
-
open.org/ubl/
cd
-
U
B
L
-

1.0/xsd/common/UBL
-
UnspecializedDatatypes
-
1.0.xs
d

. For details about the
W3C

implementation,

see

the

XML

Schema

Part

2

specification,
http://w
w
w.w3.org/TR/xmlsc
h
ema
-
2/#dat
e

and
http://www.w3.org/TR/xmlsc
h
ema
-
2/#dateTim
e

.


3.10 Currency Amounts


All monetary values in IAE systems should be expressed in a 20
-
character format

(maximum length), with a maximum of 17 d
i
gits

to

the

le
ft

of

the

decimal

point
and

2

dig
i
ts

to

the

right,

with

on
e

position

re
served

for

the

decimal

point.

The
highest value is

999,999,999,999,999.99 (without the commas). No commas,
spaces, dollar signs or other non
-
digit c
h
aracters should be perm
i
tted, with the
exception of the decimal point (and possib
ly

a

negative

sign).

In

m
ost

systems,
this

will

be

a

floating

point

number,

but

if

st
o
red

as

a

string,

these

character
restriction
s

must be enforced. I
n UBL 1.0, the Core Component Type
AmountT
y
pe

is

used

for

currency.

It

is

an

extension

of

the

XML

S
c
hema

built
-
in
type

xsd:d
e
cimal

and

includes

two

opti
o
nal

attributes. Although the

number of
digits

is

not

constrained

in

UBL,

XML

Sch
e
ma

allows

you

to

con
s
train

digits
using

the

“f
ractionDigits”

facet

(constraint).



For the UBL reference, see
http://docs.oasis
-
open.org/ubl/cd
-
U
B
L
-

1.0/xsd/common/UBL
-
CoreC
o
mponentTypes
-
1.0.xs
d

.

See

al
so

the

XML
Schema

Part

2

specificatio
n
http://www.w3.org/TR/xmlschem
a
-
2/#decima
l

.


3.11 Identifiers vs. Codes


The

distinction

between

Core

Compo
n
ent

Types

Identifier

and

Code

is
somewhat

subtle

in

UBL

1.0.

The

definition
s
fro
m
http://docs.oasis
-

open.or
g/ubl/cd
-
U
B
L
-
1.0/xsd/common
/
UBL
-
CoreComponentTypes
-
1.0.xsd

follow:


Cod
e
:

"A

character

string

(letters,

figures
, or

symbols)

t
h
at

for

brevity

and/or
language

independence

may

be

used

to

represent

or

replace

a

definitive

value

or
text

of

an

a
ttribute

togeth
er

wit
h
relevant

supplementary

information."


Identifier
: "A character string to identify a
nd

distinguish

uniquely,

one

instan
c
e
of an object in an ide
n
tification scheme from

all

other

objects

in

the

same

sch
e
me
together

with

relevant

supplementary

inform
ation."





IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

1
6

-


[The above link also includes 7
-
9 attri
b
utes

for

both

of

the

Core

Component

Types, such as codeListID and identificationSchemeA
g
encyName.]


In IAE shared systems
,

there are some elements previously called

Somet
h
in
g
Code
that

are

actually

Identifiers

and

others

calle
d
Somethin
g
I
D
that

are

really

Codes.
As we re
-
v
i
sited each data element from Standard Transactions 1.1, we re
-

evaluated

which

was

the

appropriate

designation.


The

key

determining

fa
ctor

was

whe
th
er

the

value

set

was

likely

to

change
frequently

or

infrequently.

For

example,

DUNS

and

S
S
N

are

updated

daily

(at
least). A DUNS number distinguishes or
identifies

a

specific

organization

fr
o
m
all

other

organization
s
,

just

as

an

SS
N
uniquely

distinguishe
s

one

individual
from all others. DUNS and SSN are therefore Identifiers.


In contrast, countries and states do not change often. Abbreviations or numer
i
c
shorthand for countries and abb
r
eviations f
o
r states are relatively stable; the set
of possible value
s can be enume
r
ated in a code list. Addition of new countries
and new states are infrequent events. Furthermore, the codes used to represent
them

do

not

change

v
e
ry

often.

Th
ese are therefore C
o
des. Less
o
bvious
examples include:



(a)

A

code

identifying

p
arty

receiving

tran
sm
ission;

codes

agreed

to

by

trading
partners.

Originally

called

Appli
c
ation

Rcvrs

Code

(T
X
N06).

We

have

given

this
the

BIE

of

Receiving_

Party.

Identifica
tion. Identifier because it uniquely
distinguishes

one

party

from

all

others.


(b)

When

considering

the

type

of

Indef
i
nite

Delivery

Vehicle

(IDV)

contract,
there is a finite set of possible values that can readily be enumera
t
ed. Theref
o
re,
the assigne
d

BIE is Contract. Indef
i
nite Delivery Contract_ Type. Code.


(c) The FIPS Pub. 95 code

for the agency o
f

the

contracting

or

funding

office

that
executed or is otherwise responsible for
the

transaction

was

assigned

the

BIE

of
Contracting_

Organization.

Ag
e
ncy_

Identification.

Identifier.


3.12

When

Other

Elements

are

Necessary


If

our

set

of

elements

does

not

provide

certain

elements

that

your

s
ystem
needs, we recommen
d

that you look f
irst

at

UBL

and

then

at

TBG
-
17

for
guidance. For example, UBL def
i
nes

Buildi
ng
Name

an
d
B
ui
ld
i
n
g
N
u
mb
er

as

optional
child

elements

within

the

Addres
s
xsd:comple
x
Typ
e
. Since IAE shared systems
d
o
not

presently

separate

this

infor
m
ation

in
to

discrete

elements,

we

have

specified
onl
y
StreetNam
e

an
d
A
d
ditio
n
alStreetNam
e
.

However,

you

can

us
e

B
u
il
d
ing
N
am
e

a
n
d
Buildi
n
g
Number

if you need them.




IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

1
7

-

3.13 Acronyms and Abbreviati
o
ns


Federal

acquisition

is

re
plete

wit
h acronyms and abbreviations. On the
one

hand,

e
xpanding

acronyms

to

form

element

names

removes

ambiguity.
However,

it

makes

for

unnaturally

long

el
em
ent

names

such

as
Comm
erc
i
alAndGovernmentEntityID and
NorthAmericanIndustryClassificationSys
t
em
Code

that

are

subject

to

ty
p
ing
errors

and

not

likely

to

be

the

target

o
f
a

text

search

since

procurement

people
with

th
i
nk

of

the

acronym.


While the guidance from UBL and various

Na
ming

and

Design

Rules

documents prohibits the use of
a
cronyms and abbreviations, IAE XML element
names
ma
y

incorporate

acronyms with th
e
following

mandatory

re
s
trictions:




The acronym

must

be an established a
n
d

widely

understood
acronym

in

the

Federal

pr
ocurement

community.

Exa
m
ples
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

U
BL

1.0.]




Data

definition
s
must

expand

th
e
acronym,

both

in

the

relevant
data

dictionary

and

in

the

XM
L Schema, each acronym must be
expanded

with

xsd:
d
ocumentation.




Business

Information

Entity

(BIE)

names

used

for

data

dictionary
entries (dictionary entry names)

ma
y

also use acronyms.




Based on the feedback received on Standar
d Transactions 1.1, we
chose to use, where appropriate, the acronyms and abbreviations to
keep the Business Information E
n
tity (BIE) names to a manageable
size.

Although,

abbreviations

are

not

permitted

(except

for

ID,
which is approved in UBL 1.0). W
e

cho
se to use abbreviations for
the above mentioned reason, e.g.


Alt (Alternate), Cert

(Certification).


3.14 Code Lists Gap Analysis and Recommendations


In

the

first

quarter

of

2005,

the

IAE

P
M
O

performed

an

analysis

of

over

a
dozen code lists used by va
rious IAE s
hared systems. Results wer
e

published in
April

2005

in

the

doc
u
ment

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 dis
t
ricts, countries, and sta
t
es. All IAE system stewa
r
d
s
should

consult

this

g
a
p

analysis

and

fo
llow its recommendations. Many of the
data elements listed in our Standard
Transactions

Vo
c
abulary

2.0

spreadsheet
have value

constraints based on these
code

lists.

In

order

to

achieve

true






IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

1
8

-

interoper
a
bility,

it

is

c
rucial

that

IA
E shared systems m
i
grate towards a single,
common

authoritative

sources

for

each

code

list.


Please note tha
t UBL and the various Naming and Design Rules
specifications (see next section) discuss an e
l
aborate and robust code list
mechanism,

based

on

a

common

XML

Sch
e
ma

that

can

be

implemented

by

any
authoritative

source

o
f
any

code

list.

F
or example, if ISO impl
emented this XML
Schema

and

produced

a

version

of

ISO

3166

(country

codes)

based

on

the
schema, interoperability with UBL
-
based a
p
plications would be
a
chieved. There
would

never

be

ambiguity

about

whether

a

particular

data

element

was
constrain
e
d

to

values

from

the

2
-
character

alpha,

3
-
character

alpha,

3
-
digit

I
S
O

3166

variants,

English

or

French

or

any

given

version.

While

the

I
A
E

PMO
certainly
e
ncourages movement toward t
his approach, virtually all of the code
lists

on

wh
ic
h

we

depend

have

n
o
t

yet
,
to

ou
r

knowledge,

adopted

this

XML
Schema. We will monitor the sit
u
ation ove
r time and make appropriate technical
updates as necessary and feasible.


3.15 XML Guidance for IAE: Naming and Design Rules


Since the IAE PMO released the document entitled

I
A
E

XML

Su
mmary

Guidance 1.
1

in

February

2004,

a

number

of

XML

Naming

and

Des
i
gn

Rules

(NDR) documents have surface
d

from OAS
I
S, UN/CEFACT, and the
Department of the Navy. Since the var
ious

NDRs

are

closely

aligned

with

the
UN/CEFACT
Core

Component
s

Technical

Specif
ication

(which is in turn based
on

ISO/IEC

11179),

the

IAE

PMO

strongly

encourages all shared systems a
n
d
procurem
en
t system vendors to study these documents and consider them

(along

with

the

CCTS)

as

the

primar
y

sources

of

XML

guidance

for

IAE.



See Robi
n Cover's de
t
a
iled page,

XML

Naming

and

De
s
ign

Rules

Specifications

Published

by

OASIS,

UN/CEFACT,

and

Navy

CI
O

which includes
archived copies of the NDRs from three different (but interrelated) sources:


¾


Universal
B
u
siness Language (UB
L
) Naming and De
sign Rules
.

Publication
Date: 15
-
November
-
2004. 104 pages. Approved by vote of the OASIS
membership as an OASIS Standard. Docum
e
nt identifier: 'cd
-
UBL
-
NDR
-

1.0.1'.

OASIS

source

location
:
http://www.oasis
-

open.org/
c
ommittees/tc_home.php?wg_abbrev=ubl

.



¾


UN/CEFACT XML Naming and Design Rules
.

Draft

1.1.

14
-
January
-
2005.

141

pages.

Document

identifier:

'NamingAndDesignRules_1.1.doc'.
UN/CEFACT sour
c
e location:
http://www.disa.org/cefact
-

groups/atg/downlo
a
ds/index.
c
fm

.








IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

1
9

-

¾


Department

of

the

Navy

XM
L

Naming

and

Design

Rule
s
.

Final

Version

2.0.
Office of the DON, Chief Information Officer. January 2005. 168 pages.
Navy

source

location
:

http://w
w
w.doncio.navy.mil/

.


Robin Cover's page summarizes, c
ompares,

and

contrasts

the

thr
e
e
different NDRs and is therefore itself a
valuable

resource

in

understanding

th
es
e
emerging sources of
i
n
ternational XML guidance.


3.16 Maintaining and Expanding Standard Transacti
o
ns


The shared systems a
r
e currently in
various

stage
s

from

concept

to
prototype,

redesign

and

production.

Th
e

current information exchanges and data
elements

are

expected

to

increase

in

n
umber and change over time. To facilitate
this

growth

the

IAE

Program

Management

Office

will

maintain

the

Standard
Transa
ctions v2.0 and will incorporate

remaining

IAE

shared

systems

e.g.
Performa
n
ce Reporting System. Updates w
ill

be

published

as

changes

in

the

IAE
shared

systems

are

identified

and

documented.


The

IAE

Standard

Transactions

need

to

evolve

with

IAE

interoper
ability
requirements and capabilities


b
o
th w
ithin

the

IAE

d
o
main

and

with

relat
e
d
areas such as finance, asset managemen
t

and

sales,

etc.

To

achieve

this

goal,
agency and industry acquisition c
o
mmunity members need to review their
interoperability needs
on an ongoing basis to identify any desired changes or
additions

to

the

Standard

Transactio
n Information Exc
h
anges or Vocabulary.
They should also review evolving F
e
deral Registries (e.g., the CORE.gov
maintaine
d
by

GSA

for

the

CIO

C
ouncil
)

to identify any

data elements, schema,
or

integration

services

that

could

be

leveraged

by

IAE.


Desired

additions

or

c
hanges

should

be

submitted

to

the

IAE

Program
Management

Office

by

sending

em
ail

t
o
integrated.acquisition@g
s
a.go
v
. You
may also request to participate

in future
discussions

about

IAE

data

elements.

As
part

of

this

process

IAE

will

also

arrang
e
for

posting

of

the

updated

Standard
Transactions to the appropriate Federal r
e
gistry(s) so
t
h
at they can be shared and
reused

as

widely

as

possible.

T
h
e

upda
ted

Standard

Transaction
s
will

be

shared
with

the

CIO,

CFO

as

well

as

the

CAO

communities.



















IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

2
0

-

Appendix A: Data Element

St
a
nd
a
rdi
z
ation

Pro
c
ess



This appendix describes the process that t
h
e Standard Transa
ctions workgroup uses to
develop standard data elements for IAE. A
l
though

shown

as

a

sequence

here,

several

“steps” can be done concurrently a
n
d some are an iterative process.



Step 1
:

Identify

a

community

of

interest

amo
n
g

the

m
a
jor

players

in

the

IAE

l
i
ne
of business (and related lines of business w
h
ere appropriate.)





Identify

S
u
bject

Matter

Experts

(SMEs)

who

are

willing

to

particip
a
te

in
working groups that meet on a regular bas
i
s.



Establish

an

electroni
c
collaborative

environment

to

support

dialo
g.


Step 2
:

Focus

initially

on

atomic

units

o
f

data

needed

for

interop
e
rability

(i.e.,
data that is exchanged among systems or

processes),

ra
t
her

than

trying

to

define
complete data models for all bus
i
ness processes and systems.





Start with a bottom
-
u
p

rather than top
-
dow
n

approach.



Identify

the

common

building

blocks

(e.g.,

Person,

Address,

etc.)

that

are
likely

to

b
e
reusable

across

stakeholders

for

a

given

system

as

wel
l

as
across the environment.


Step 3
:

Collect interface control docum
ents

and/or,

data

dictionaries,
government

regulated

element

lists,

and

oth
e
r

descripti
o
ns

of

the

elements
needed for interchange.





Initi
a
te

data

calls,

either

formally

or

informally.



While

it

is

highly

desirable

to

obtai
n 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:

o

Data elements names

o

Element

descriptions

o

Data

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

o

Whether the element is repeatable in a particular exchange
o

Whether the element is mandatory, optional, or conditional
o

Transactions in which the data element is used



Note:

It

is

important

that

shared

sy
stem stewards update the IAE PMO as
new

versions

of

data

dictionari
es
become

available.







IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

2
1

-

Step 4
:

Analyze collected element lists a
c
ross business partners to normalize
element

names

and

to

identify

group
ing
s of related elements as higher
-
level
structures

(e.g.,

object

classes).

This
involves

using

methodology

developed

by
ISO/IEC, UN/CEFACT and OASIS, in
a
dd
i
tion

to

the

better
-
known

Unified
Modeling

Language

(UML)

techniques
.
Highlights

of

these

methodolo
gies
follow;

refer

to

the

cit
e
d

documents

for

considerable

detail.





Electronic Business XML (ebXML) is a collaborative effort of two major
international

organizations
:
UN/CEFAC
T
(U
nited

Nations

Cente
r
for Trade

Facilitation

a
nd

Electronic

Business)

an
d
OASIS
(Organization

for
the
Advancement of Structured Inf
o
rmation Standards). UN/CEFACT is
responsible for the Core Components

Technical

Specification

and

Bu
siness
Process specifications. OASIS oversees the Registry and Repository,
Messaging
,
and

Colla
b
ora
tion

Pr
o
tocol

specifications.



The Core
Co
mponents Technical Specification defines a common s
e
t of
semantic

building

bl
oc
ks

that

represent

th
e
general

types

of

business

data
in

use

today.

The

Core

Components

metho
d
ology

pro
v
ides

a

way

to
identify, capture

and maximize the re
-
use
o
f business
i
n
formation to
support and enhance information
interoper
a
bility

across

multiple
business si
t
uations.



All

ebXML

Core

Com
p
onents

con
f
orm

to

ISO/IEC

11179

data

element
naming conventio
n
s (see Appendix B)



When a Core Co
mponent is used in a real business circumstance, it serves
as the basis for a Business Informa
t
ion Entity (BIE). For example,
Shipping
C
ontact

and

OrderContac
t
are

BIEs

derived

from

the

more
generic

Contact

Core

Component.



Related BIEs are grouped togethe
r to form an Aggregate Business
Information

Entity

(ABIE).

Examp
le: US_ Person. Details and US_
Address.

Details.



When

one

ABIE

references

anothe
r ABIE, you have an Association
Business

Information

Entity

(A
S
BIE).

For

example:

US_

Person.

US_
Residence.

US_

Address

and

US_

Person. US_ Official. US_ Address .



A major g
o
al of the data vocabulary definition process is to arrive at a set
of BIEs based on Core Components i
n

the context of the Line of Business
of

the

initi
a
tive.



Schemas

will

be

developed

b
ased

on

infor
m
ation

exch
a
nge

requirements
identified

via

business

process

m
o
deling. Information and process
modeling and the XML schema creation process shoul
d

be separa
t
e and
distinct steps.










IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

2
2

-

Step 5
:

Generate

or create XML Schema b
ased

on

UBL

methodology,

including
the

identif
i
cation

of

d
ata

constra
i
nt
s

such as enumerations, code lists, value
ranges,

character

patterns,

lengths,

etc.





Schema

development

will

take

place

a
s
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:

o

An XML
-
based busi
n
ess languag
e

o

Built

upon

existing

E
D
I

and

XML

b
usiness
-
t
o
-
business
v
o
cabularies

o

Applicable across all industry sectors and domains of electronic
trade

o

Designed to be modu
l
ar, reusab
l
e, and extensible

o

Non
-
proprietary

and

royalty
-
free

o

Intended to become an int
erna
t
ional standard for electronic
commer
c
e

o

Addresses

only

a

small

subset of

elements

needed

for

IAE



The UBL Library has been designed as a collection of object classes and
associations expresse
d

as a conceptual model. Specific document types are
then
assembled from
t
h
ese Business Information Entities (BIEs) by
organizing them into a specific h
i
erarchy. These hierarchical models are
then

trans
f
ormed

using

the

UBL

Naming

and

Design

rules

into

XML
Schema s
y
ntax.



Three levels of content components are de
fined in UBL:

1.

Atomic component
s

that

hold

individual

pieces

of

information

typically
represented

by

primitive

data

types

(e.g.,

"text,"

"Bool
ea
n,"

"date"
)
or
data types readily derived from these. Example: PostalCode of type

“text”.

2.

Aggregate compone
nt
s

t
h
at hold logically related groups of atomic
components and sub
-
aggregates.
Example:

Address

contain
i
ng
StreetAddress, Posta
l
Code, StateOrProvince, and Country.

3.

Document component
s

t
h
at assemble atomic and aggregate components
to

form

a

self
-
contain
ed

logical

unit.

The

business

process

context
provides the requirements for which documents are to be assemb
l
ed.
Example: transactional messag
e
s

within

a

business

process.



Aggregate

Business

Informatio
n Entities (ABIEs) bec
o
me the
xsd:complexTypes of the

XML Schema



Step 6
:

Contribute XML Schema to the COR
E.gov

to

increase

the

likelih
o
od

of
reuse:






IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

2
3

-



Contact

I
A
E

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

c
o
mmunity.



FUTURE
-

Step 7
:

Re
-
factor to harmonize with vocabularies from
i
n
ternational
groups such as the UN/CEFACT TBG
-
17 effort.





While the IAE is focused on efficie
n
cies and reuse within the federal
government,

it

should

leverage

int
e
rnational standards as much as
possible. The process outlined above employs the methodology developed
by several international groups.



The

BIEs,

Core

Components,

and

XML

Sch
e
ma

developed

by

the

IAE
should

be

contributed

to

the

i
nternational efforts upon whose
methodol
o
gy

they

w
e
re

developed.



Such

contributions

may

require

IAE

to

modify

is

schema

to

some

extent,
but

the

result

will

be

improved

dat
a

exchange

capabilities

at

the
international

level.


The main reference f
o
r this process is the “IAE Summary XML Guidance” which
contains

a

complete

reference

section.

Visi
t acquisition.gov, click About IAE link, and
then


IAE

Summar
y

X
M
L

Guidance

V.

1.1
,

[2
/
4
/
0
4]
”.



































IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

2
4

-


Appendix B: Creating ISO/IEC 11179 Names



The descr
i
p
tion that f
o
llows is a considerabl
e

simplification

of

a

more

involv
e
d

process.
As

such,

developers

are

directed

to

ISO

and

UBL

documentation

(s
e
e
R
e
fere
n
ce
s
) for
the

details.


“ISO/IEC

11179

part

5

[see

refere
nces] 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

multi
ple

words

in

a

part

respectively. In order to meet XML
requirements for component naming, the I
S
O

11179

name

must

be

converted

to

a

[XML]
Name T
o
ke
n
1
.

The

ISO

11179

part

5

standard

provides

a

way

to

precisely

create

a

data
element

definition

and

name.

Usi
ng

or

ref
e
rencing

this

name

in

a

schema

provides
analysts

w
i
th

a

better

understan
d
ing

of

XM
L
component

semantics,

while

using
business

t
e
rms

as

el
e
ment

names

improves

r
eadability
.
Requiring

types

to

c
o
nform

to ISO

11179

convention
s
will

facilitate

automate
d
analysis

of

schema

components

during
any
harmonization efforts. The upper and lower camel case conv
en
tions are adopted from
ebX
M
L.” [DON XML Developer’s Gu
i
d
e 1.1, Section 7.1.3.2]



An

ISO

11179
-

compliant

data

el
em
ent

name

consists

of

three

parts:


An


Object Clas
s


term,

which

describes

the

kind

o
f
th
in
g

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 ‘Ac
o
ustic Signal. Frequency. Measure’ has the
Object Cla
ss ‘Ac
o
u
stic Signal’. As anoth
er example, consider that the ISO/IEC 11179
name 'EFT_ Payment. Authorization. Date' has the Object Class 'Payment'.


A

Propert
y

Term


which

is

the

property

of

the

thing

to

which

you

refer,

which

may
consist of one or more wo
rds. For example, the ISO/IEC 11179 name ‘Acous
t
i
c 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

Ter
m


which

ident
ifies

allowable

values

for

an

element.

This

list

is
taken

from

an

enumerated

list

of

allow
able

representation

types

(see

below).

For
example, the ISO/IEC 11179 name ‘Acous
t
i
c Signal. Frequency. Measure’
h
a
s the
Representation Term ‘Measure’. Anoth
er exampl
e is the ISO/IEC 11179 name 'EFT_
Payment.

Authorization.

Date'

that

h
as the Representation Term 'Date'.


Each term may have an additional
qualifier

term (signified by a trailing underscore) to
provide

additional

in
f
ormation.

In

the

exampl
e above, the Obje
ct Class has the qualifier

'EFT_' (as in “Electronic Funds Transfer”).





1

An

XML

Name Tok
e
n is a

string
t
hat b
e
g
i
ns

with a letter

a
n
d
c
ontains

onl
y

certain
c
h
a
racters.

In

particu
l
ar,
s
paces
a
n
d

un
d
e
r
sco
r
es

a
re

n
o
t

p
e
r
m
i
tte
d
i
n a

N
a
m
e

To
k
en.




IAE S
t
a
nd
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

2
5

-

Other examples of ISO/IEC 11179 names include Product. NAICS. Code and

Organization.

DUNS.

Identifier,

n
e
ither

of

which

hav
e
qualifiers.




ISO/IE
C

Qualifie
r

Object

Propert
y

Representation

XML Element

Name

11179

(
optional)

Class

Ter
m

Type

Data Element

Name


Aco
u
st
i
c

[none]


Acoust
i
c

Frequen
c
y


Mea
s
ur
e

A
c
ou
st
i
c
Frequen
c
y

Signal.

Signal

Frequen
c
y.
Measure


E
F
T_

EFT_


Payment

Authorizatio

Date


EFTPaymentAuthoriz
ation

Pa
yment
.

n

Date

Authorizatio
n
.
Date


Prod
u
ct.

[none]


Product

NAICS

Code

ProductN
A
IC
S
Code

NAIC
S
. Code


Organization
.

[none]


Organizat
i

DUNS


Identi
f
ier

OrganizationDUNSID

DUNS
.

on

Identi
f
ier




Note: Although

the
ab
ove table only show
s
qualifiers used in conjunction with the
Object Class, they may also precede Property Terms a
n
d/or Representation T
y
pes.
Also, the “dot space” notation is
intentional

to

aid

spell

checking.



“XML

component
s
MA
Y

be named after IS
O/IEC 11179 data element names:

XML

Element
s
SHOUL
D

be

named

after

ISO/IEC

11179

data

element

definition
s

when
business terms do not e
x
ist.

XML Attributes
SHO
U
L
D

be named after ISO/IEC 11179 data elements.

XML

Schema

data

types
MUS
T

be named after ISO/IEC
11179 data elements.”



Note

the

d
i
stinction

that

XSD

(XML

Schema)

data

ty
p
e
s

MUS
T

be

based

on

ISO/IEC

11179

names,

whereas

XML

element
s
MA
Y

be based
o
n

more familiar business terms.
The XML Schema data type based on the first example above wou
l
d be
Acoust
icS
i
gnalFrequencyMeasure. The XML element name would be

<Acoustic
F
requency>, assuming this was
the

common

business

term.

Similarly,

the
other examples result in the XML element names EFTP
a
y
mentAuthorizationDate,
ProductNAICSCode,

and

OrganizationD
U
NSID.



Consider

another

example,

one

which

in
volves child elements. The ISO/IEC 11179
name “A
d
d
ress. City. Text” results from t
h
e Object Cl
a
ss “Address”, the Property Term
Qualifier “City”, the Property Term Nou
n

“Name”, and the Representation Type




IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

2
6

-

“Text”. The XML Schema type would be
“AddressCityName”

and

the

XML

element
name would be <AddressCity>.



The allowable Representation Types (know
n

as Core Component Types in UBL) are:



Amount



Binary

Ob
je
ct

(plus

Graphic,

P
icture,

Sound

and

Video)



Code



Date

Time

(plus

Date

and

Time)



Identifier



Indicator



Measure



Numeric (
p
lus Value, Rate and Percent)



Quantity



Text

(plus

Name)



Those

shown

in

par
e
ntheses

are

know
n as Secondary Representation Types.












































IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

2
7

-


Appendix C: Key A
c
quisition Scenarios



1

Open M
a
rke
t

-
Not

Sim
p
l
i
f
i
ed A
c
q
u
i
s
i
t
i
o
n

2

Two

Step

S
e
aled

B
i
d

3

Sol
e

S
o
urce


(O
pen Marke
t


Not Simpl
if
ied)

4

Unsolicite
d

P
roposal

5


Sealed

Bid

6

Open

Marke
t

Sim
p
lifie
d

$100,000

-

5
M

Co
mm
ercial It
e
m

7

Open

Marke
t

S
i
m
p
l
i
fi
e
d

$
2
5,00
1
-
1
0
0,000

8

Open

Marke
t

S
i
m
p
l
i
fi
e
d

$
1
0,00
1
-
2
5
,
0
00

9

Open

Marke
t

S
i
m
p
l
i
fi
e
d

$
2
,
5
01
-
1
0
,0
0
0

10

Smal
l

Business

Innova
t
i
o
n

Research

(SBIR)

11

Deli
v
e
r
y /
T
a
sk Or
d
ers

A
g
ai
n
s
t

Inde
f
i
nit
e
Delivery Vehicl
e

(IDIQ Contract)

12

Orders

A
g
ai
n
st F
S
S

Sched
u
le

13

Orders

A
g
ai
n
s
t

M
u
l
t
i
p
l
e

A
w
ard

Sche
d
u
l
e

14

Economy

Act

15


Micro

Purc
h
a
se
(
S
t
and

Al
o
ne

Single

Purchase)

16

Purc
h
a
se

Cards

/

Conve
n
ience

Check
s

/

Thir
d

Party

Drafts











































IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

2
8

-


Appendix

D:

IAE

Acronyms



BPN

Bu
s
ines
s

P
ar
t
ner Network

CAD
O

Contr
a
ct

A
w
ar
d

Documents

Online

CC
R


Centr
al
Contr
a
cto
r

R
egistration

CPAR
S

Contr
a
ctor

Perform
a
nce

A
s
sessment

Re
p
o
rting
S
yste
m

(DoD)

CPS


Contr
a
cto
r
Performan
c
e

S
y
stem

(N
I
H
)

D&B


Du
n

an
d
B
r
adstre
et

EEO
C

Equal

Empl
o
y
ment

Opportunity

Com
m
ission

EPLS

Exclu
d
ed
P
a
r
t
ies
L
isti
n
g System

eSR
S

Electroni
c

Subcontractin
g

Reportin
g

S
y
stem

FB
O

Fede
r
a
l

Busi
n
ess

Opportu
n
ities

(F
e
dBizOpps)

FedRe
g

Fede
r
a
l

R
e
gistration

Application

FedTeD
S

Fede
r
a
l

Tec
h
nical

D
a
t
a

Solution

FMS

TO
P

Fina
n
cial

M
anagemen
t

S
e
r
vice

Tr
e
a
sur
y

Offset

Pr
o
g
r
a
m

FPDS
-
N
G

Fede
r
a
l

Pro
c
urement

D
a
ta

S
y
stem

Nex
t

Generation

Grantee

Reg

Grantee

Re
g
i
stration

ICD


Interagenc
y

Contract
s
Directory

IG
T

Int
r
a
-
gover
n
menta
l

T
r
ans
a
ctions

IPAC

In
t
ra
-
go
v
er
n
m
en
t
al

P
a
y
m
en
t

and
C
o
ll
e
c
t
ion S
y
s
t
em

(Tre
a
su
r
y)

NA
B
S

Nativ
e

Ame
r
ican
B
u
s
iness

System

ORCA

Online

Repr
e
sen
t
a
t
ion
s

a
n
d Cer
t
i
f
i
c
a
t
i
o
ns App
l
ica
t
i
o
n

PPD
B

Pas
t

Pe
r
f
or
m
a
nce

D
a
ta

Bas
e
(NASA)

PPIMS


P
as
t

Pe
r
f
or
m
a
nc
e
I
n
forma
t
ion

Management

Syste
m

(Army)

PPIR
S

Pas
t

Pe
r
f
or
m
a
nce

I
n
formation

Ret
r
ieval

S
y
stem

SBA P
R
O
-
Ne
t

SBA Procuremen
t
M
a
rketin
g
Network

VET
S
-
10
0

Ve
t
era
n
s’ E
m
ploymen
t

a
n
d Tr
a
ini
n
g
S
e
rvice

(DOL)

WDOL

Wag
e

De
t
er
m
ina
t
io
n
s O
n
-
L
ine






























IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

2
9

-

Appendix

E:

Glossary

o
f
Terms



T
e
rm


Me
a
ning

ABI
E

Agg
r
e
g
a
t
e
B
u
si
n
ess In
f
o
r
m
at
i
on

En
t
i
t
y
(
A
B
IE
)

-

A

collec
t
io
n

o
f

r
e
la
t
ed
pieces
o
f
b
usiness

infor
m
a
t
ion that

toge
t
h
er convey

a

distinct
b
usi
n
e
ss
meani
n
g i
n

a

speci
f
ic

B
u
si
n
ess

Contex
t
.

E
x
presse
d

in

modeli
n
g
te
r
m
s, it

is
the

represen
t
a
tion

o
f
a
n
O
bject

Class
,

in

a spe
c
i
f
ic
B
u
s
i
ness

Co
n
t
e
xt
.

In

XML
Schema
,

a
n

ABIE

become
s

a

complex

type.

Ac
q
ui
s
i
t
ion

A repr
e
sen
t
a
t
ion o
f

th
e m
o
s
t

complex
t
y
pe of

a
c
q
u
isi
t
ion proce
s
s.
T
h
e

Backbon
e

Sc
e
n
ario

ac
q
u
i
si
t
io
n

B
ackbone

Sce
n
ari
o

i
s b
a
sed

on Open
M
a
r
ke
t

No
t

S
im
p
li
f
ied
p
urch
a
ses

a
n
d in
c
lud
e
s
t
h
e
m
ajo
r
i
t
y
o
f
in
for
m
a
t
io
n

e
x
chang
e
s f
o
un
d in
a
l
l

ac
q
u
i
si
t
i
o
n sce
n
ari
o
s.

Ac
q
ui
s
i
t
ion

The IAE
A
cq
ui
s
i
t
ion I
n
fo
r
m
a
t
ion

Repo
r
t
ing
(
AI
R
) b
u
sine
s
s

ar
e
a
w
i
ll be

Informatio
n

th
e foc
a
l p
o
i
n
t

for

a
l
l

ac
q
u
i
si
t
ion

rep
orting

a
c
ross

IA
E

share
d

and

p
a
rtner

Repor
t
in
g

(
A
IR)

systems.

Ac
q
ui
s
i
t
ion

P
rocess

1
6

ke
y

acq
u
is
i
t
ion s
c
ena
r
i
o
s hav
e

b
een
d
o
cumented.

Majo
r

acti
v
ities f
o
r

Scenarios

each scenari
o

were identifie
d
alon
g

wi
t
h

an
y

i
n
for
m
a
t
ion exc
h
ang
e
s wi
t
h
extern
a
l

a
pplic
a
t
i
ons

used

t
o

support

the

a
ct
i
v
i
ty.



Ac
q
ui
s
i
t
ion

A va
r
i
a
t
ion
o
f
th
e IDE
F

ICOM Mod
e
li
n
g appr
o
ach
d
o
cumen
t
ing
t
h
e

Scenarios

speci
f
ic

ac
t
iv
it
ies

for

a
p
ar
t
ic
u
la
r

t
ype of

ac
q
u
i
si
t
io
n

p
r
ocess
.

For

ea
c
h
a
ct
i
v
i
ty,

the

support
i
n
g

i
nform
a
t
i
on

ex
c
h
ang
e
s,

info
r
m
ation s
o
ur
c
es,

and
roles

an
d

co
n
trol
s

ar
e

documented.

Agency Ba
c
k


O
ffice

Procurement and fi
n
a
nce app
lication
s
m
a
intaine
d

by indivi
d
u
al ag
e
ncies

Appli
c
a
t
ions

or

bureaus

t
o

handle

day
-
to
-
day

operations.

ASBIE

Association

Busines
s

In
f
ormatio
n

E
n
tit
y

-

A
B
u
s
in
e
ss Inf
o
rma
t
i
o
n En
t
i
t
y
th
a
t

re
p
rese
n
t
s a co
m
p
lex

b
usin
e
ss c
h
a
r
ac
t
er
i
s
t
ic
o
f a

s
p
eci
f
ic O
b
je
c
t

C
la
s
s
in

a spe
c
i
f
ic
B
usi
n
es
s

Con
t
ex
t
. I
t

has

a

u
n
i
q
ue
B
u
s
ine
ss

Se
m
an
t
ic
defi
n
i
tion.

A
n

Asso
c
iatio
n

Business

Inf
o
rmation

En
t
i
ty

repr
e
s
ent
s

an
Asso
c
iatio
n

B
usi
n
e
s
s

Info
r
m
ation Entit
y

Pro
p
er
t
y

an
d

i
s

a
ssoc
i
a
t
ed

to

an
Aggr
e
ga
t
e

B
u
sine
s
s Inf
o
r
m
a
t
ion En
t
i
t
y
,

which

d
e
scribes

its

structu
r
e.

An
Asso
c
iatio
n

B
usi
n
e
s
s

Info
r
m
ation Enti
t
y

is

de
r
i
ve
d

f
r
om

a
n

Asso
c
iation
Core

Component.

Authenti
c
a
ti
o
n

The

process

o
f
identifyin
g

a
n

indi
v
i
dual,

usually

b
a
s
e
d

o
n

a

user
n
ame
a
nd

p
a
ssword.

Authent
i
cat
i
on

merel
y

e
nsur
e
s

that

t
h
e

in
d
i
vi
d
u
a
l

is

who
he

or

she

claims

to

be,

b
u
t

s
a
ys

noth
i
n
g

a
bout

th
e

a
ccess

r
i
ghts

o
f
t
he
indi
v
idual

Authorizati
o
n

The

process

o
f
giving

in
d
i
v
i
dua
l
s

acces
s

to

system

ob
j
ects

based

o
n

their
i
dent
i
ty.

Fo
r

ex
a
mp
l
e,

sys
t
em

a
d
m
i
n
i
str
a
tors

h
a
v
e

a
uthor
iz
ed

a
ccess

to
d
a
ta

th
a
t

regul
ar

users

d
o

not.

















IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

3
0

-


BI
E

Busines
s

In
f
or
m
a
t
io
n

E
n
t
it
y

(BI
E
)



A

piece

of

business

d
a
ta

o
r

a
group
of pie
c
es
o
f
b
usi
n
e
s
s

da
t
a with a

uniq
ue

B
u
sin
e
ss

S
e
mantic d
e
fi
n
i
tion. A
Business

Inf
o
rm
ation

En
t
i
ty

ca
n

b
e

a
Ba
si
c

B
u
s
i
nes
s
In
f
orm
a
t
i
on

Ent
i
ty

(BBIE
)
,

an
A
s
soc
i
a
t
ion
B
u
si
ness I
n
for
m
a
t
ion En
t
i
t
y

(
A
SBIE
)
, or

an
Aggr
e
g
at
e

Business

Inf
o
r
m
ation

Entit
y

(ABIE).

Ther
e

are

thre
e

d
i
fferent
catego
r
i
es

o
f
Business

Inf
o
rmation

En
t
i
ties:

1.

B
a
s
i
c

B
u
s
i
nes
s
In
f
orm
a
t
i
on

Ent
i
ty

2.

Asso
c
iatio
n

B
usi
n
e
s
s

Info
r
m
ation Entit
y
, a
n
d

3.

Aggr
e
ga
t
e

B
u
sine
s
s Inf
o
r
m
a
t
ion En
t
i
t
y
.

The

most

primitive

of

these

is

th
e

Ba
s
ic

Busines
s

In
f
o
rmatio
n

E
n
tity

(BBIE)
.

A

Ba
s
ic
B
usi
n
e
s
s

I
n
formatio
n

E
n
t
i
ty

i
s

a

Bas
ic

Core

Component
used

in

a

sp
e
c
i
f
ic
B
usi
n
e
s
s
Con
t
ex
t
.

Business

Par
t
ne
r

An IAE

B
u
si
n
ess

Ar
e
a
--
th
e

Bu
s
ine
s
s
P
a
r
t
ner Networ
k

i
s

the bu
s
in
e
ss

ar
e
a

Networ
k

f
or

the

tr
a
d
i
n
g

p
a
rtners

for

the

govern
m
e
n
t

and
,

at

i
ts

core,

i
s

th
e
C
e
n
t
ral

Contracto
r
Regist
r
a
tion (
C
CR) system.

Bu
s
i
nes
s

Te
r
m

Bu
s
ines
s

te
r
m
s a
r
e com
m
only r
e
cognized word
s

tha
t

ar
e

more
appropriatel
y

us
e
d

as

X
ML

element

n
a
m
e
s,

r
a
ther

than

the

o
f
ten
-
esoter
i
c
ISO/IEC

111
7
9

convent
i
ons.

Bus
i
ness

terms

i
mpro
v
e

the

re
a
d
a
b
i
l
i
ty

of
schemas

a
n
d

instanc
e
s,

w
h
il
e

the

ISO/
I
EC

11179

n
ames

provid
e

more
precis
e

an
d

s
t
ructure
d

se
m
antics.

CC
R

Centr
a
l

Contr
a
cto
r

R
egistration

(CCR
)

s
y
stem

is

a

si
ng
le

d
a
ta

entry
sys
t
em

for v
e
ndor i
n
form
at
ion co
l
lec
t
i
o
n

an
d

v
a
li
d
a
t
ion
th
a
t

c
an
b
e
shar
e
d

with

agency cont
r
a
c
t

writing

sys
t
ems.

CIOC

XD
G

Chief

I
n
for
m
ation

O
f
f
i
cers

Council

X
M
L

Developer

s

Guide

COI


Communit
y

o
f
Interest

CO
R
E.go
v

Compo
n
e
n
t

Orga
n
i
zatio
n

an
d

Re
g
istrati
o
n E
n
vi
r
o
n
m
ent
-

th
e
government

sourc
e

for

b
u
siness

proc
e
ss

and

tech
n
i
ca
l

components.
CO
R
E.GOV

is

the

pl
a
ce

t
o

se
ar
ch

f
or

a
n
d

l
oc
a
t
e

a
spec
i
f
i
c

component

th
a
t
meets

your

n
eeds,

or

t
o

fi
n
d

compo
n
ents

y
o
u

c
a
n

customize

to

m
e
et

your
un
i
qu
e

r
e
q
u
i
r
ements. You

can

a
l
so

rec
o
mmend

components

fo
r

inclusion
in

CORE.G
O
V
.

Constraint
s

Restrictions

p
l
aced

on

dat
a

v
alues.

Fo
r

e
x
ample
,
text

str
i
ngs

c
a
n

be
constr
ai
ned

t
o

mini
m
u
m

and

m
a
ximu
m

nu
mb
er
o
f
c
h
a
r
ac
te
rs
.

In
te
gers
can

be

co
n
s
t
r
ain
e
d

t
o

a

r
a
n
g
e

o
f
values
.

Text

strings

c
an

also

be
constrai
n
e
d
t
o
a fi
x
ed
se
t
o
f
choi
c
e
s (as i
n
code lists, also known as
enume
r
ations)
.

Core

component
s

A

set

o
f
uni
v
ersal

compo
n
ent
s
th
a
t

a
re
c
o
n
t
ex
t
ua
l
ly
n
e
u
t
r
a
l

and
c
a
n
b
e
use
d

acr
o
ss

all

do
m
a
ins

t
o

expre
ss

semantics of co
m
m
on busi
n
ess
concepts.

DOD

End
-
to
-
En
d

A

Department

of

D
e
fens
e

Analysis

o
f
t
h
e

Pro
c
ureme
n
t

processes

Procuremen
t

res
u
l
t
ing

in
t
h
e develop
m
en
t

of
P
roces
s

Mod
e
l

and

S
ys
t
ems
M
aps

Analy
s
is

pub
lis
hed

o
n

M
a
rch

3
1
,

1999

DT
D

Document

Type

Definitio
n
.

DTD

technology

predate
s

XML

Sche
m
a
. DTDs

a
r
e

mode
l
s

o
f
X
ML

documents,

b
u
t

they

c
a
nnot

spec
i
fy

d
a
t
a

types.
Fede
r
a
l

XM
L

guidanc
e

in
d
icates

t
h
at

DTDs

sh
o
u
l
d

no
t

be

use
d

for

new
efforts

tha
t

a
r
e

da
t
a
-
o
r
i
ent
e
d;

use

X
M
L

Schem
a

instead.









IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

3
1

-


EbXML

ebXML (
E
lec
t
ronic
B
u
s
ine
s
s
u
sin
g

eX
te
n
sibl
e

M
ar
k
up

Lan
g
u
a
ge
)
,
sponsored

by

UN/C
E
F
A
C
T

and

O
A
S
I
S
,

i
s

a

mod
u
lar

sui
t
e

of
s
p
eci
f
i
c
a
t
ion
s

th
a
t

ena
b
les

en
te
r
p
ris
e
s o
f

an
y

s
iz
e

a
n
d

in

any
g
e
og
r
aph
ic
a
l
l
oc
a
t
i
on

to

conduct

bus
i
ness

ove
r

the

I
n
ternet.

ebX
M
L

provid
e
s

a stan
d
a
rd

me
t
hod

to

exchange

bus
i
n
e
s
s

messages
,
c
o
nduct

tra
d
ing rel
a
t
i
onsh
i
ps,

commun
i
c
a
te

d
a
t
a i
n

co
m
mon

terms

a
n
d

def
i
n
e

a
nd
register bu
s
i
n
ess
proc
e
ss
e
s
.

See

http://ebxml.org/

eMa
r
ke
tp
l
a
ce

An IAE

B
u
si
n
ess

Ar
e
a;
eM
arke
tpl
ace
w
i
ll
p
ro
v
ide
m
a
rke
t

res
e
arch

and
on
-
line

purch
a
sing

c
a
p
a
b
i
litie
s

for

buyers

a
n
d

sellers.

F
E
A
P
MO

F
eder
a
l

Enterp
rise

A
r
ch
i
tect
ur
e

Pr
o
g
ram

Ma
n
ag
ement

O
ffi
ce
,
which
rel
e
as
e
s
the

v
a
ri
o
u
s

R
e
fer
e
nce

Mod
e
l
s

(RMs),

the

s
o
urce

of

gover
n
ance
for

muc
h

of

these

g
u
ideli
n
es
;

se
e

PRM
,

BR
M
,
SR
M
,
D
R
M,

a
n
d

TRM
.

See
http://feapmo.gov

Fede
r
al R
e
gi
st
ry

A
s
ingle l
o
gi
c
al entry poin
t

for

acc
e
s
si
ng

reusa
b
le co
m
p
onents potentially
loca
t
e
d

in

d
i
f
f
eren
t

phys
ica
l lo
c
a
t
io
n
s,

s
u
ch a
s

i
n

in
d
i
v
id
u
a
l

a
gency
data
b
as
e
s or

repositories.

IDE
F

IDEF

wa
s

(derive
d

from

t
h
e

Structured Analysis an
d

Desig
n

Tech
n
i
que)
is

a

method des
i
gne
d
t
o
m
ode
l
the decis
i
ons
, a
c
t
i
ons,
a
nd
a
ct
i
v
i
t
i
es o
f

a
n
org
a
n
i
z
a
t
i
o
n

or

system.

IDEF

mode
li
n
g

i
denti
fi
es

th
e

Inputs,

Contro
ls
,
Ou
tp
u
t
s,

and

Mecha
n
is
ms

(ICO
Ms)
o
f a
s
ys
t
e
m
.

Informatio
n

As

d
e
fi
n
e
d

f
o
r

IAE:

The

e
x
chang
e

o
f

information

be
t
ween

a

pers
o
n

or

Exchang
e

syste
m

and

o
ther

syste
ms
.

Inform
a
t
io
n

e
x
chang
e
s
s
u
p
p
or
t

speci
f
ic
ac
t
ivi
t
i
e
s
o
f
t
h
e a
c
q
u
i
s
i
t
i
o
n proces
s
.

In
t
ra
-
go
v
er
n
m
en
t
al

An

IA
E

Bus
i
nes
s

Are
a
whose

go
a
l

is

to

tr
a
ns
f
orm

i
ntra
-
governmen
t
a
l

Trans
a
ctions (IGT
)

orderi
n
g

and

bil
l
ing
,

re
d
u
c
e

payment

a
n
d co
l
lec
t
ion
p
roblems
,

and
im
prove

rev
e
nu
e

and

exp
e
nse

e
limi
n
ation

process

f
o
r

prepa
r
ing
conso
l
id
a
te
d

fi
n
a
nci
a
l

st
a
tements.

ISO/IEC

1117
9

Informatio
n

Technology



Speci
fi
c
a
t
io
n

an
d

S
t
a
n
da
r
d
i
z
a
t
io
n

of
D
a
t
a
Ele
m
en
t
s

is

a

6
-
p
art ISO

s
tan
dard

p
ro
v
i
d
ing

a

fra
m
e
w
ork

and
me
th
odologi
e
s fo
r

d
ev
e
lop
i
ng, do
c
umen
t
ing,

an
d

re
g
i
st
ering s
t
an
d
a
rd
data

elements.

Th
e

ISO

111
7
9

st
a
n
da
r
d

i
s
a

mu
l
t
i
p
art

s
t
an
d
ard
t
h
at
inc
l
ude
s

th
e
fo
llo
w
ing
p
ar
t
s:
P
ar
ts
: 1.

Fr
am
ework,

2.

C
l
a
ss
i
fi
c
a
t
io
n
,

3.
Re
g
is
t
ry

Me
t
a
mo
de
l

a
n
d
B
a
s
ic A
tt
ri
b
u
t
es,

4.

For
mu
la
t
ion o
f

Da
t
a
De
f
i
n
i
t
i
ons, 5
.
N
a
m
i
ng
a
n
d i
denti
fi
c
a
t
i
o
n
pr
i
nc
i
p
l
es,
a
nd
6.

R
e
gistr
a
t
i
on.

[Mor
e

for
m
a
l
ly,
t
h
is

i
s

c
a
l
l
ed ISO/IEC

1
1
17
9,

for In
t
e
rna
t
io
n
al
Orga
n
i
z
a
t
ion

for

S
t
an
d
ar
d
i
za
t
io
n
/
In
t
erna
t
ion
a
l

Elec
t
r
o
t
echnic
a
l
Commission.]

ISO
72
73

ISO s
t
a
n
da
r
d

da
ta

el
ements

i
nclud
ed

i
ntended

to

f
a
c
i
l
i
t
a
te

i
nterch
a
nge

of
da
ta

in

in
t
er
n
a
t
ion
a
l
t
r
ad
e
.

These s
t
a
nda
r
d

d
a
t
a
e
le
ment
s
c
a
n

be

us
e
d
w
i
th

a
ny

method

f
or

d
a
t
a
interch
a
ng
e

on

p
a
pe
r

documents

a
s

well

a
s with

other

m
eans

o
f

da
t
a
c
ommunica
t
i
o
n.

JFM
I
P

J
o
i
nt

F
i
n
a
ncia
l
M
a
n
age
m
e
nt

Im
p
r
ov
e
m
e
nt

Pr
o
g
r
a
m

w
as

a
j
o
i
n
t

a
nd
cooperativ
e

underta
k
ing

o
f

the

U.S
.

D
epartment

of

t
h
e

Treasu
r
y
,

t
h
e
General

Acc
o
unting

O
f
fice,

the

Off
i
ce of Ma
n
a
gement an
d
B
u
d
g
et, and
the

Office

o
f
Personnel

Managemen
t

w
o
rkin
g

in
c
oopera
t
ion

wi
th

e
ach
other

an
d

other

ag
encies

t
o

improv
e

fi
n
a
nci
a
l
m
an
a
g
e
me
nt

practices

in
government
.

Its

work

h
a
s

t
r
ansferr
e
d

t
o

the

CFO

Council.

S
e
e
http://www.jfmip.gov/jfmip/

.







IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

3
2

-


Nam
e
space

In XML,

a
n
a
mespace

i
s

a

conceptual

s
p
ace

to

w
h
ic
h

elemen
t

and attribute

n
a
m
es

may

b
e

ass
i
gne
d
.
U
s
in
g

names
p
aces prevent
s
na
m
e
col
l
isio
n

(
a
m
b
ig
u
i
t
y) w
he
n

th
e
s
ame
e
l
emen
t

name

appea
r
s

in
m
ul
t
ip
l
e XML
voca
b
ularies

in the

same documen
t
. A
n
ames
p
a
c
e i
s

asso
c
iat
e
d

with a
U
RI

(U
n
ifo
r
m

Res
o
urc
e

Identifier) whic
h is eithe
r

a

UR
L

(U
n
if
or
m
R
esource Loc
a
tor
)

suc
h
as htt
p
://www.w
3.
org/20
0
1/XMLSche
m
a
or

a
URN (Unive
r
sal

Res
o
urce

Nam
e
)

li
k
e
u
r
n:u
s
:gov:
g
sa:iae.

OASI
S

Orga
n
i
zation fo
r
the Advancemen
t
o
f

Structured

Inf
o
rmation

Sta
n
dar
d
s.
OASI
S

i
s

a

n
o
t
-
for
-
pr
o
fi
t,

g
l
obal

co
n
sortium

th
a
t

dr
i
ves

the

deve
l
o
p
ment,
convergence

and

adoptio
n

of
e
-
b
u
sin
e
s
s

stan
d
ar
d
s.

Object

Clas
s

Ter
m

A

component

of

the

n
a
m
e

o
f

a
Core

Component

or

Business

Inform
a
tion

Ent
i
ty

wh
i
c
h

represents

the

Object

C
l
ass

to

wh
i
ch

it

be
l
ongs.

P
a
rtner Ser
v
ic
e

App
li
c
a
t
i
ons wh
i
c
h
prov
i
d
e
d
a
t
a

to
a
nd
i
nteroper
a
te w
i
t
h
th
e
IAE bu
t ar
e
not

m
a
nage
d

by

the

IA
E

Progr
am

M
a
nagement

Office.

Payl
o
a
d (XML
)

Protocols an
d
frameworks such a
s
SOAP
,
B
iz
T
a
l
k
,

a
n
d
ebXML

us
e

XML
to

m
ark

u
p

m
es
s
age
h
e
a
de
r in
fo
r
m
a
t
io
n

neces
s
a
r
y f
or

b
indi
n
g,
r
eli
a
b
le
messagi
n
g,

and

se
c
u
rit
y
.

T
he

term


p
a
y
l
oad


r
e
fers

to

the

XML

b
e
i
n
g
tr
a
nsm
i
tted

t
h
a
t

conta
i
ns

t
he

a
ctua
l
busines
s

i
n
f
or
m
a
t
i
on

communic
a
ted.

Portal S
e
rvic
e
s
L
ayer

The

Web

por
t
al

ser
v
ice
s

la
y
e
r

is

r
e
sponsible

fo
r

the

d
e
livery

o
f
all
appli
c
a
t
io
n
s,

servic
e
s,

and

da
ta

to

th
e
us
er communi
t
i
es

acces
s
in
g

th
e
portal. T
h
i
s

la
yer

a
l
so prov
id
es

W
eb portal ser
v
ices

(f
o
r exam
p
le,
secu
r
i
t
y,

a
g
g
r
ega
t
io
n
,
s
in
g
l
e s
i
gn
-
o
n
,

a
n
d de
l
e
g
a
t
ed

adm
inis
t
r
a
t
ion
servic
e
s)
,

c
o
mmunica
t
io
n

servi
c
es
,

pol
i
cy ma
n
agem
e
n
t

se
rvic
e
s,

an
d u
s
er
m
a
nagement services.

Property

Ter
m

A

se
m
a
nt
i
c
a
lly

me
a
n
i
ng
f
ul

n
a
m
e

f
or

th
e

ch
a
r
a
cter
i
s
t
ic

o
f
th
e

Obje
c
t

Class
th
a
t

is

represented

by

th
e

Core

Comp
o
n
e
n
t

P
r
ope
r
t
y
. It

shall

serve

a
s
basis
for
th
e

Dicti
o
nary Entr
y
N
a
m
e

of

th
e

Bas
i
c

and

A
s
soci
ation

Core

Co
m
ponents
th
a
t

represents

th
is
Core

Com
p
onen
t

Pr
o
p
e
rt
y
.

Qu
a
l
i
fie
r

Te
r
m

A word
o
r g
r
ou
p

o
f

word
s

th
a
t

help

de
f
ine

and
d
i
f
fe
r
en
t
ia
t
e

an

i
t
e
m

(e
.
g.
a

B
usiness

In
f
o
rmation

Ent
i
ty

o
r

a

D
a
ta

T
ype
)
fro
m

its

a
s
sociated ite
m
s (
e
.g.
from

a
Core
C
o
mpo
n
en
t
,

a
C
ore

Co
m
p
one
n
t

Type
,
anoth
e
r
Busine
s
s
Information

Entit
y

or

anot
h
er

D
a
ta

T
y
pe
).


Representati
o
n

Ter
m

Th
e ty
p
e
o
f
v
a
l
id

v
a
l
u
e
s

f
or
a

B
a
s
ic

C
o
re Co
mponen
t o
r

Busin
e
ss
Informatio
n

Entit
y
.
Thi
s

is

simil
a
r to

a

data

ty
p
e

but may
c
on
v
ey
busi
n
ess
c
o
n
text (e
.
g
.,

A
m
ount).

Sha
r
ed

Syst
e
m
s

Applications

that

a
r
e
m
a
n
a
g
ed

and

co
o
rdi
n
ated

th
ro
ugh

the I
n
te
g
rated

Acqui
s
i
tio
n

Envi
r
onment.

SM
E

Subject

M
a
tter

Expert

[
term

somet
i
me
s

used

f
or

S
m
a
l
l
-

a
nd

Med
i
um
-

sized Enterp
r
is
e
]

Stan
d
ard

As d
e
fi
n
ed

i
n

OMB
C
ircular No.
A
-
1
19:

(
1
) Common

and
r
e
pea
t
ed

use
o
f
r
ul
es
,

c
o
ndi
t
ion
s
,
g
u
ide
l
ine
s

or
characteris
t
i
c
s

for

produc
t
s
or

related

p
r
ocesse
s

an
d

production

m
e
thods,
an
d
r
elated management system
s
p
r
ac
t
i
ces.

(
2
) The

de
f
in
it
ion of
te
r
m
s;

cl
a
ss
i
f
i
c
a
tio
n

of

components;

deli
n
eatio
n

of
procedur
e
s;

sp
eci
f
ica
t
io
n

o
f
d
imensio
n
s
,

ma
te
r
ia
ls
,

p
e
rforman
c
e,
d
e
sig
n
s,
or o
p
era
t
ions
;

m
ea
s
ure
m
e
n
t

of
qu
a
l
i
t
y

an
d
q
uan
t
i
t
y

in

desc
r
i
b
ing
materials,

pr
o
cesses
,
pro
d
ucts,

s
y
stems
,

s
e
rvices,

or

p
r
actices
;
test method
s
a
n
d

sa
mpl
i
n
g
p
r
oced
ur
e
s;
or

de
s
c
ri
pt
i
on
s
of

fit

a
nd measur3em
e
nts

o
f

size

o
r

strength





IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

3
3

-

Stan
d
ard

An exc
h
ange

of i
n
for
m
ati
o
n with one
or

more syste
m
s f
o
llo
w
ing

agreed

Transaction
s

u
pon

b
u
s
i
nes
s
ru
le
s

a
n
d

us
in
g stan
d
a
rd dat
a
elements

Stan
d
ard

T
he

IA
E

Sta
n
dar
d

Vo
c
a
bulary

w
i
ll

pro
v
ide

agencie
s

and

vendors

that

Voca
b
u
l
ary

develop
a
nd suppor
t
procurement
a
pplic
a
tions
a

s
t
and
a
r
d
voc
a
b
u
l
a
ry for
ac
q
u
i
si
t
io
n

r
e
la
t
e
d

da
t
a
e
l
e
m
en
t
s. The s
t
an
d
ard vo
c
a
b
u
l
ary
w
i
l
l f
a
c
i
li
t
a
t
e
consisten
t

a
n
d

effi
c
i
ent

ex
c
hang
e

o
f

da
t
a

between

s
y
stems

withi
n

I
AE

and
ex
t
erna
l

to

I
A
E. The I
A
E

S
t
an
d
ard

Vo
c
ab
ul
a
ry

is
th
e

agg
r
e
g
a
t
e of

a
l
l
interopera
b
l
e

da
t
a
e
l
ements

tha
t

are

p
a
ssed

through
o
ut

the

envir
o
nment
v
ia

S
t
an
d
ar
d

eTran
s
ac
t
ion
s
.

UBL

Univer
sa
l
B
u
sine
s
s
L
an
g
u
age

i
s

in
t
end
e
d

to

become

an

in
t
erna
t
io
n
al
stan
d
a
r
d

fo
r

electroni
c

c
o
mmerce

fr
e
ely

a
v
ailable

t
o

everyon
e

wi
t
hout
lice
n
sin
g

or

o
ther

fe
e
s
.

Th
e

OAS
I
S

U
B
L

TC

(Techni
c
a
l

Committee)

is
developi
n
g

a

stan
d
ard

lib
r
ary

of
X
ML
b
usi
n
ess

doc
u
ments (purc
h
ase
orders
,

inv
o
i
c
es, e
t
c
.
) b
y

m
o
di
f
yin
g

a
n

al
rea
d
y e
x
is
t
i
n
g
l
ibra
r
y
o
f
X
ML
schem
a
s

to

i
n
corpor
a
te

th
e

best

f
e
a
ture
s

of

other

e
x
isting

XML

b
u
siness
lib
r
a
ri
e
s
.

Th
e

TC

will

the
n

desig
n

a

me
c
hanism

fo
r

the

gene
r
a
tio
n

of
context
-
specific

busin
e
s
s

s
c
hem
a
s

through

the

a
ppl
i
c
a
t
i
on

of
tr
a
ns
f
orm
a
t
i
on

rules

to

th
e

common

UBL

source

l
i
br
a
r
y.

UN/CE
F
AC
T

United Na
t
i
o
n
s
Center for Trade F
a
c
i
l
i
tat
i
on

a
nd

Electron
i
c

Bus
i
ness

-

An
orga
n
i
zatio
n

of

government

an
d

indus
t
ry

representat
i
on

fr
o
m

ar
ound

the
world

worki
n
g

to

simplif
y

world

trade.

TBG

1
7

A

workgr
ou
p

of

the

Trad
e

and

B
u
s
i
nes
s

Pr
oce
s
s

Group

o
f
U
N
/CEF
A
CT.
The

purpos
e

of

the

projec
t

is

to

t
a
ke

r
e
s
p
onsibilit
y

fo
r

ensu
r
i
ng

the
consistency

and

harmo
n
isation

o
f
Busi
n
e
s
s

Process

m
odels

and

C
o
re
Components

acros
s
busin
e
ss

do
m
a
i
n
s

and

sectors

b
y

developi
n
g

a

concise

and

wel
l
-
d
e
fined

lib
r
ary
o
f
b
u
s
ines
s

t
erms

an
d bu
s
ine
s
s
d
a
t
a
semanti
c

definition
s

for

t
h
e

structur
in
g

of
d
a
t
a

exch
an
ges

in

a
s
yn
t
ax neutral
m
an
n
er.

Vendo
r

S
y
s
t
e
m
s

Non F
e
de
r
al

appli
c
a
t
io
n
s;

us
ua
ll
y

o
f

c
o
mpanie
s

doi
n
g bu
s
ine
s
s
w
ith

th
e

Fede
r
a
l

Gove
rnment.

W3
C

The

World

W
i
d
e

Web

Co
n
s
ortiu
m

is

a

vendor

consor
t
i
um,

not

an
accre
d
ited s
t
andar
d
s bod
y
,

however,

its

products
h
a
v
e suc
h

a stro
n
g
i
n
f
l
u
ence

over

commerci
al

so
f
tw
a
re

im
p
l
ement
a
t
i
on
s

th
a
t

i
ts

wor
k

must
take

prec
e
d
e
nce

over

eve
n

accr
e
dite
d

stan
d
a
r
ds

bodies

f
o
r

matters

related
to

the

WWW.

Web ser
v
ice

A Web

servi
c
e is a s
o
ftwa
r
e

s
y
stem

designed

to

sup
p
ort

i
nteroperab
l
e
machin
e
-
to
-
m
achin
e

in
t
e
r
ac
t
ion over

a

network.

It

h
as

an

i
nterf
a
c
e
described

i
n

a
m
a
chine
-
process
a
bl
e

f
o
r
m
a
t

(
spec
i
fi
c
a
l
ly

WSD
L
).

O
t
her
system
s

inte
r
a
ct

with

th
e

Web

ser
v
ic
e

in

a

m
a
nne
r

prescrib
e
d

b
y

its
descrip
t
io
n

u
sin
g

SO
A
P
-
m
es
s
age
s
,
t
ypi
c
a
l
ly conv
e
y
e
d

wi
th

HTTP

(Hy
p
er
t
ex
t

T
r
an
s
fer

Pro
t
ocol)

u
s
ing

an
X
ML s
e
r
i
a
l
i
z
a
tio
n in con
j
un
c
t
ion
with

other

X
M
L
-
r
e
lated

s
t
an
d
a
rds.

In

simpler

ter
ms
,

a

W
e
b

ser
v
ic
e

is

a
p
rogra
m
m
a
tic

in
t
er
f
ac
e

th
a
t

ena
b
le
s

a
p
p
li
c
a
t
ion
t
o

app
lica
tio
n
communica
t
ion.

XM
L

Extensible

Markup

Language,

a

gen
e
ral

synta
x

used

t
o

creat
e

do
m
a
i
n
-

speci
f
ic vo
c
a
bul
a
ri
e
s.
XM
L i
s

fo
c
us
e
d
o
n

s
t
ruc
t
u
r
e
r
ath
er
th
an
present
a
tion. Ex
a
mple
s
of XM
L
voc
a
b
u
larie
s

ar
e

ebXML
,

UBL,

a
n
d

XML
Schema.








IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

3
4

-


XSD

/

XML

Schem
a

XML

Sche
m
a
.

An

XML

Schem
a
i
s a
d
a
t
a

mode
l
th
at

de
fi
nes

i
n

deta
i
l

the
s
t
ruc
t
ur
e

an
d

da
t
a
t
ypes

i
n
volved i
n

a

X
ML me
s
s
a
ge

(o
r doc
umen
t)
. The
XML

mess
a
g
e

c
a
n

be

valid
a
te
d

a
g
ai
nst

the

XM
L

Schem
a
.

XML

Schem
a
s
express

sh
a
r
e
d

vocab
ul
ari
e
s a
n
d

a
l
low

machin
e
s
to

c
arr
y

ou
t

r
ul
e
s

made
by

people.

They

provid
e

a
me
a
n
s

fo
r

defining

the

structure,

conten
t

and
semanti
c
s

o
f

XML

docu
me
nts

XSLT

E
xtensibl
e

S
t
yles
h
eet
L
an
g
ua
g
e

Tr
a
ns
f
orm
a
t
i
ons
,

a
w
a
y

to

conver
t

XML
to

HTML,

te
x
t,

or

d
i
f
f
eren
t

XML.

F
o
r

e
x
ample,

XSLT

c
a
n

b
e

us
e
d

t
o

map
IAE S
t
and
a
r
d

Vo
c
a
b
u
l
a
r
y
t
o

an
o
r
g
an
i
z
at
ion

s s
h
ared

sys
t
e
m’
s
X
M
L
vocabul
a
r
y
o
r
to

EDI.























































IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

3
5

-


Appendix

F:

References



FEA
D
a
ta

R
e
f
erence M
o
del

Da
t
a R
e
fere
n
c
e Mod
e
l,

V
o
l
ume

1,

Ve
r
si
o
n 1
.
0

from
th
e

Fede
r
a
l
Enterpris
e

A
r
chitecture,

releas
e
d
September

2
0
0
4
.

A
v
a
i
l
a
b
le

fr
om,
http://w
ww.whitehouse.gov/omb/egov/a
-
5
-
drm.html



ISO/IEC

111
7
9



P
a
rt

5

http://isotc.iso.ch/liveli
n
k/live
li
n
k/
f
e
tch/
2
0
0
0
/
2
4
8
9
/Itt
f
_Home/P

Informa
t
io
n

t
echnolog
y

-
-

ubli
c
l
y
Av
a
i
la
bleS
t
an
d
a
r
ds
.
htm

Spec
i
fi
c
a
t
ion

and
s
t
a
nd
ar
diz
a
tion

o
f
d
a
ta

elements

--

P
a
r
t

5
:

Nam
ing

and
identifi
c
atio
n

princi
p
les f
o
r da
t
a
elements

Univer
sa
l
B
u
sine
s
s
L
an
g
u
age

http://www.oasis
-

(UB
L
),

Ve
r
si
o
n 1
.
0

open.org/c
o
mmittees/tc_home.php?wg_abbrev=u
b
l

UN/CE
F
ACT

Core

Component
s

http://www.unece.org/cef
a
c
t
/ebxml/CCTS
_
V2
-
01_Final.pdf

Technic
a
l

Sp
e
c
i
f
ica
t
io
n
,

Part

8
o
f
th
e
e
bX
ML F
r
a
m
e
w
ork;

1
5

November

2
0
0
3
,

V
e
rs
i
o
n

2
.01

TBG
-
17: UN
/
CEFAC
T
Trad
e

http://www.disa.org/cefact
-
groups/t
b
g/wg/tbg1
7
_m
a
in.c
f
m

a
nd

B
u
s
i
nes
s

Pr
oce
s
s

Group,
Ver
s
ion

2
.0
1

IAE Summa
r
y XML
G
ui
d
ance,

2
-

V
i
sit
http://ac
q
u
i
s
i
t
i
on.go
v
,

c
lic
k

About

IAE

link,

a
n
d

then


IAE

Febru
a
ry
-
200
4
,
V
ers
i
o
n
1.
1

Summary

X
M
L

Gu
i
d
a
nce

V
.

1.1,

[
2
/
4
/
0
4]
”.

Univer
sa
l
B
u
sine
s
s
L
an
g
u
age

http://www.oasis
-

(UB
L
)

Na
m
i
n
g a
n
d De
s
ign

open.org/c
o
mmittees/tc_home.php?wg_abbrev=u
b
l

[
arc
h
ive co
p
y :

R
u
l
es,
1
5
-
N
ovember
-
20
0
4
,

http://xml.coverpag
e
s.o
r
g/UB
L
-
N
D
Rv10
-
Rev1c.p
d
f

]

Ver
s
ion

1
.
0

UN/CE
F
ACT

XML

Naming

a
n
d

http://www.disa.org/cefact
-
groups
/
a
t
g
/downl
o
a
ds/index.
c
fm

Des
i
gn

Rules.

Dra
f
t

1.1
.

1
4
-

[arc
h
ive cop
y

:
http://xml.coverpages.
o
r
g/ATG2
-

Ja
nuary
-
2
0
0
5.

N
a
m
i
ngAndDes
i
gn
Ru
l
es2
0
05
0
1.pd
f

]

Dep
a
rtment

of

the

N
a
vy

XM
L

http://www.doncio.
n
avy.mil/

Na
m
ing

and

Design

Rules,

Fi
n
al

[arc
h
ive cop
y
:
http://xml.coverpages.
o
r
g/DON
-
X
ML
-

Ver
s
ion

2
.
0
,

J
an
u
ar
y

20
05

NDR2
0
05
0
12
7
-
3
3
94
2
.pdf

]























IAE S
t
and
a
r
d

Tran
s
ac
t
io
n
s

V
2
.0

-

3
6

-