American
Institute of Architects
1735
New York Avenue NW
Washington
DC 20006
Please send all
comments or corrections to these minutes to (Mark Crawford)
On Wednesday,
February 20, 2002 the Federal CIO Council XML Working Group (WG) held their
monthly meeting at the American Institute of Architects. Mr. Owen Ambur chaired the meeting. The purpose of the meeting was to:
◆ Review January, 2002 meeting minutes
◆ Continue the WG’s XML cross-pollenization efforts by delivering applicable government and industry presentations to the membership.
These minutes are
designed to capture the WG discussion and high-level points of the guest
presentations. The presentations and attendance list are available at the
xml.gov website.
The agenda for the
meeting follows:
9:00 Co-Chairs and Participants
Announcements and approval of
Minutes
9:15 XML Policies at the
Environmental Protection Agency
10:15 Break
10:30 Universal Business
Language (UBL)
Jon Bosak, Sun Microsystems & OASIS
12:00 Adjourn
Mr. Ambur opened
the meeting by introducing himself, briefly explaining the day’s focus, and
asking all participants to introduce themselves. He then turned the meeting
over to Mr. Steve Vineski of the EPA for an account of EPA’s XML policies.
I’ve tried to
categorize the people who will use or be directly affected by XML for my own
purposes. It seems that there are several groups of people involved:
◆
Innocents—People
who are sold on XML before they know what they have. They like the web-enabled aspect of it, but don’t know what it’s
about.
◆
Proselytizers—People
who don’t understand that it’s “just a syntax.”
◆
Evangelists—Born
optimists who say “Don’t worry about the standards. Technology will solve the
problems.
◆
Martyrs—People who need frameworks and controls in
place. They feel the need to coordinate with standards bodies, reconcile and
harmonize data deficiencies, and allow meaningful exchange.
How many of each do we have in this meeting?
A lot of this is for the “martyrs”.
Mr. Vineski then
displayed an outline of EPA’s current XML initiatives, which consist of:
◆ EPA’s partnerships
◆ XML TAG
◆ Issues and concerns.
I just want to let
you know that my job is devoted more to the policy side than to the technical
side.
EPA ‘s work is
highly delegated to states. There’s a large partnership relationship. In
exchange for grant and seed money, states must feed data. The states have
formed an exchange network.
You can look at the
reporting mechanism like this: there is the Central Data Exchange (CDX) and the
Exchange Network. The Exchange Network is the state node portion of the network
that feeds to CDX. CDX is:
◆
EPA’s portal
(Web forms, EDI, flat files, XML)
◆
Central
registration of users
◆
Tiered
security and access control, based on user needs, business arrangement, etc.
Mr. Ambur:
Steve, central registration sounds like Quicksilver. Is there a
regulatory longshop?
Mr. Vineski:
The “e-authentication” shop is talking about authenticating users, but
it’s not looking at non-repudiation and integrity of confidentiality.
Mr. Ambur: The
project is one-stop for business in government.
Mr. Vineski: EDI
is going away as XML takes over.
Mr. Vineski
displayed a graphic of CDX Functions and Options.
Mr. Vineski: So
far CDX isn’t a repository—it just passes data to the legacy systems.
Eventually, legacy data will be able to be queried through CDX.
Network Exchange
(states’ preferred way of reporting data) consists of 57 states and
territories, as well as tribes. Each is semi-autonomous. Many delegate their
programs, and many are developing their own portals. We found that their
methods are frequently ahead of ours.
Unidentified
member: Are there states that are ahead?
Mr. Vineski:
Some are about even.
Unidentified
member: Which regions?
Mr. Vineski:
Wisconsin, Virginia, New Jersey, Pennsylvania, Washington state.
Mr. Brand
Niemann Sr.: There is a “Network Readiness Report,” where
ECOS [Environmental Council of States] found that 14 or 15 states were more
ready for this kind of exchange.
Mr. Vineski:
This year we’re granting $25 million that states can use to help build
network capability
Mr. David
McKeever: What about Ohio?
Mr. Vineski:
He’s on wastewater discharge, and Ohio is already set up. I don’t know about others.
Mr. Mckeever:
They already seem to be set with lots of policies and procedures.
Mr. Niemann Sr.:
They came to a training session in Chicago. They can’t participate in March because of budget cuts.
Mr. Vineski then
displayed a graphic of the relationships between states and the EPA network.
Mr. Vineski:
Right now, states actively report.
In the future the states might put it onto a server and have EPA perform
a query. From the states’ perspectives,
they get to monitor the quality of their
own data. There are some statutory issues we need to
work with when talking about pulling data.
CROMERR [Cross-Media Electronic Reporting Rule] is designed to look at
getting past the hurdles. This model
doesn’t show the registry function, but there will be one.
The TAG is a
chartered policy workgroup that enjoys broad participation. At inception, we thought our discussions
would be largely centered around XML tags.
We quickly realized it was much more than that. We created the charter, and we have formal
program office representatives, and some LMI contractor support.
Mr. Walt Houser: Are
the products available? (e.g., the
charter and any policy that’s been developed?)
Mr. Vineski: We
don’t have a website but they’re available.
We’ll try to put them on xml.gov.
The TAG’s primary
activities are:
◆
Policy and
Guidelines Development
◆
Standards
Coordination
◆
Registry and
Repository
◆
Education and
Outreach
◆
Support the Exchange
Network
Under Policy and
Guidelines, we’re concentrating on:
◆ Tag Naming Conventions
◆ Policy Manual
·
18 topics EPA
needs to cover.
·
We’ve dealt
with the first four because they’re the easiest. We have drafts and hope to
vote on them soon.
·
Numbers 5-18
we’re just beginning to examine.
◆ XML Design Guidelines—we’re stressing:
·
Consistent
schema across federal and state entities
·
Consistent
design
·
Support
components
For 2002 we
plan to address:
◆
Complete
policy manual
·
Namespace
·
Metadata
·
Digital
signatures and encryption
◆
Additional
checklists
◆
Formalize TAG
recommendations.
Unidentified
member: How does the policy manual compare to LMI’s
draft for us?
Mr. Vineski:
It’s similar, but EPA’s might be more detailed. States bought into what
we suggested. Our big problem is the requirement for object representation
type.
Mr. John Dodd: Is
there a professional organization involved that will champion this within the
environmental community?
Mr. Vineski: The
closest thing is this network I’m talking about. There’s a group with me and Brand and some state guys that
discuss it (Technical Resources Group).
A higher-level information management group chartered network steering board
for day-to day responsibility. They also chartered the Technical Resources Group.
Ms. Linda
Lorber: Is there an EPA metadata working group?
Mr. Vineski: The
Environmental Standards Data Council developed six groups of standards. They expect more. David
[Eng] is working on some others. Their
website has all the agreed-upon standards and data definitions for our legacy
systems. They don’t necessarily
correspond to the standards.
Unidentified
member: David is trying to identify a tag set and
give it to EDR.
Mr. Vineski:
Standards Coordination—David is running a standards group for
coordination. It’s based on a Superfund
program to develop a format for the exchange of lab data. There’s not much debate about how you
structure it because of the lab test structure. It’s a three-tiered approach:
data, measurement, and standardization.
Mr. McKeever:
Some vendors are not programming their software according to the
standards.
Mr. Houser: A
colleague of mine standardized by saying “We all agree to someone else’s.” They decided to make it their standard as
well.
Mr. Vineski: We
take the same approach. The data set
has been expanded and there’s a group that examines the sets. They’ll be looking at other standards to
harmonize. The goal is not just to
develop a standard but to mirror it with DTD and schema.
Plans for Standards
Coordination 2002:
◆ Continue development of Environmental Data
Standards and schema
◆ Harmonize collections
◆ Process and guidance on tying data standards
process to XML development
◆ Begin core component development.
So far, we’ve been
so concerned with individual tracks that we haven’t backed up and looked at the
big picture.
Mr. Niemann Sr.: The
way people start up their efforts is this:
◆ Rounded up dictionaries for elements
◆ Examine them for redundancy
◆ Identify how many already conform
◆ Identify how many you need to standardize
for
◆ Identify a core set of elements across all
the dictionaries.
There’s a lot of
pre-XML work before you’re ready for the tag
Mr. Ambur: How
many elements are in EDR?
Mr. Vineski:
168.
Mr. Niemann Sr.: Six
standards involve 129 data element definitions. There are six more in process with about 150 more to come. All told about 150,000 are registered in
EDR.
Mr. Vineski: For
many of them there’s been a mapping element
Mr. Eliot
Christian: The point of calling it a registry is that
you’re just registering.
Whether you harmonize is a different issue. You can reuse legacy semantics. The EDI transactions for the environment
won’t be renegotiated. They’re out there. There’s a syntax for how to represent
them. You can go from ASN-1 to XML
mechanically. The legacy syntax doesn’t
matter. It’s the semantics that you
have to register.
Mr. Vineski:
Registries and repositories—
◆ LMI developed the report “Requirements for
an XML Registry” about a year ago.
◆ We’re partnering with NIST in development of
a pilot registry.
Mr. David Eng:
We’re not the expert on other systems, so we need to build the
relationship with the federal community.
How many elements are we looking at?
Just for solid waste, we’re up to 750 and counting. We want to standardize the semantics and
metadata. We need to share it for when
we change namespaces and schema. It
needs to be a well-defined set.
Mr. Ambur:
Lisa Carnahan will brief us next month and hopefully give us a demonstration.
Mr. Vineski:
Plans for the registry and Repository effort for 2002—
◆ Additional features
·
Namespaces
·
Components
·
Link to EPA’s
data standards registry
◆ Administrative guidance
◆ Security requirements
◆ Permanent site and resources
Unidentified
member: How many regions has Brand been to?
Mr. Niemann Sr.:
About five.
Mr. Vineski:
Brand’s been going out and training people on:
◆
Introduction
to XML
◆
DTD/schema
development
◆
XLST
◆
Web services.
Our Education and
Outreach plans for 2002—
◆
Introduction to
XML
◆
EPA/Network
policy framework
◆
Expanded
curriculum of technical training
There just aren’t
technical people who know XML. The work
is overcoming our ability to oversee it because we don’t understand the
issues. We need to train our TAG people
so the managers within the agency will have the technical background to oversee
their operations.
Mr. Vineski:
Schema development, core tools.
We’re not worried about the SOAP and SAX parsers, etc.
Mr. Niemann Sr.: The
states say “We need to know XML well enough to apply for grants. We hope the states will partner. The best nodes will come from them
partnering with one another. I’ve seen
one proposal that wasn’t reflective of Brand’s training.
We need to provide
support for the exchange network. Right now, we’re the technical arm. We’ve been doing schema, they’ve been
turning to Brand. We’re going to
Washington State to talk about mapping.
There’s a need for hands-on technical training. We want to be careful
that we don’t become the entire support network.
Plans for
supporting the Exchange Network in 2002:
◆
Technical
assistance to states
◆
Guidance and
checklists
This isn’t just
EPA's agenda, but the states also are asking for help.
Issues and
concerns—
◆
Underlying
agency architecture—We have 16 legacy systems.
They talk about standardization, but they have fiefdoms and don’t know
how far they’ve gone.
◆
Competing
agendas
◆
Large
constituency—States, Programs, 10 Regions, GML, Federal CIO Council XML Working
Group, Records management standards bodies
◆
Resources
·
We need more
technical people
· It’s extramural—XML is new—EDI and ADA standards have been around. They have budgets. If we want funds it comes from others who have money (in an environment where funding has been decreasing). Finding money has been tough.
End presentation.
Mr. Ambur: The
Department of the Interior is disconnected from the Internet. Emails have bounced. I’m working from home, but somehow we’ll get
Steve’s presentation online.
Ms. Susan
Turnbull: Other domains seem to be following a
parallel track. Is EPA ahead of the
pack?
Mr. Vineski: I
don’t know. I know the Navy and other
DoD communities are up on it.
Ms. Turnbull:
There’s the Health Information Reporting Act. I didn’t know if it was on
a fast track.
Mr. Ambur: We
need to think about what this group should be doing. LMI has the Draft Developer’s Guide that Mark distributed. It has some recommendations. We haven’t formally forwarded it to the
Architecture and Infrastructure committee.
When the time is right to make the recommendations for OMB to adopt,
we’ll need to look at it.
Mr. Vineski: We
seem to have a back and forth arrangement as people develop things.
Mr. Ambur:
Yes, but I’m pleased to see
what’s going on in the face of uncertainty and lacking budgets. Are there any other questions or comments?
At this point,
members who had entered after the beginning of the presentation introduced
themselves. Names appear in the
attendance sheet.
Mr. Ambur:
ITIPS stands for “Information Technology Investment Portfolio System,”
developed by HUD. The CIO council has
endorsed it. The Department of Veterans
Affairs uses it extensively. There is
significant overhead involved, but I think the Department of the Interior has
been testing it. There seems to be
agreement that it should use XML, but hasn’t proceeded to great extent.
Mr. Houser: The
goal is to integrate the products that are generated under the effort into our
architectural portal.
Mr. Ambur:
Here’s Marion to introduce our next speaker.
Mr. Marion
Royal: We’re at the 18-month point, and we’ve had a
who’s who of XML at our meetings. Owen
gets great speakers, but I get credit for this. I met Jon Bosak months ago when
he started UBL. I went as an observer
to a UBL meeting and was made a vice chair of a committee. Here’s Jon.
Mr. Jon Bosak:
Hello. I’m Jon Bosak. I work for Sun Microsystems and I’m the
chair of the OASIS UBL Technical Committee.
For anyone who would like to review it, this presentation is on the UBL
website.
What is the promise? Everything will just happen—it’ll be plug
and play, no more EDI, no expensive custom programming, it’ll be ubiquitous,
cheap, and platform independent. People who preach it usually think you’ll
only be using one platform. It’s not
that simple.
Why? XML isn’t a language,
it’s a meta-language framework for defining languages. The tags have no specific meaning, but the
syntax is there. Data representation is what needs to be standardized. It’s very hard technically and organizationally to standardize. It’s time consuming. Tools and methodologies can help, but most
help is version control, etc.. But,
when you decide what a field means and what it’s called it’s a long
process. It’s filtering upwards. Now managers are becoming aware of the
intricacies.
Some of the things we want to do involve different kinds of Web services. Some of the types:
◆
B2C
(Enterprise Application Integration) is one picture of Web services. It’s where XML is used to send parameters
back and forth. There are a couple of
requirements here:
·
It must
support run-time trading partner discovery
·
It must
support run-time service interface definition.
This is very difficult. We’re
getting standards to deal with this.
◆
B2B (Business
to Business). Let say you have a
legally binding document. Only from far removed is that comparable to B2C. It:
·
Must be
reliable
·
Must support
EDI
·
Must allow a
human to step in
·
Automated
discovery and trading partner formation are optional. They’re nice to have, but not essential. Most trade is with a small number of
partners—not based on discovery, but trust. It’s usually based on judgment.
Making the
transition—Web services supporting B2B must support an upward migration path or
they won’t fly. Our goals should be to:
◆
Move
enterprises online
◆
Automate
existing relationships.
We need to let
people do things at their own pace.
Swap out or automate when it makes sense. Because business consists of document exchange, the easy way to
do this is to look at the document exchange. That’s what EDI does.
Mr. Eng: The
data dictionary, business process, what is the major component of getting it
from the legacy side?