[Cache from http://xml.gov/minutes/20020220.htm; please use this canonical URL/source if possible.]
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?
Mr. Bosak:
Some of that I'll cover in the presentation. Let's come back to it in a while.
What we want is: something to extend
benefits of EDI to the world in the form of XML. Persistence is important. SGML was designed with this in
mind. Let's use that to build up
labeled data that is useful down the line.
What we need is:
◆
Standard forms
◆
Reliable
messaging
◆
Optional but
powerful discovery of schemas and trading partner profiles. It would be nice if we could automate
trading partner agreements. If we have
the capability, it must be very powerful.
◆
Optional
trading partner agreements. Again, if
we did it, it would have to be powerful.
It would involve multiple taxonomies and search possibilities.
Note that all we
need to implement EDI using XML are the first two bullets.
What we would get is:
◆
Incremental
automation
◆
Extension of
EDI to all the world's businesses
◆
The capability
for existing EDI users to communicate with their smaller partners without
replacing their existing systems.
I'm not saying that
people should get rid of EDI. No one's
unhappy with it. It works fine. What I do hear is that by using EDI we've
restricted our suppliers to those who can use EDI. Can't we make it simpler for them and expand our scope, perhaps
have EDI and XML so they can use either?
What's the good
news? ebXML gives us almost everything
we need for XML EDI.
To make what we
want happen, we just need to add standard XML forms. We're not far away from accomplishing that. That standard way is what I'm here for: UBL.
What is it?
◆
A synthesis of
existing languages
◆
Primary
inputs: xCBL, ebXML, ebXML Core
Components, ebXML context methodology.
◆
Interoperable
◆
Based on a
core library plus an extension mechanism
◆
Unencumbered
by intellectual property claims. It's
important to make sure that what's done is in the public domain.
◆
Intended to
become a legal standard for international trade.
There are serious
challenges to UBL:
◆
Economic
challenges--There are many who won't benefit from UBL. There are already several
languages. UBL doesn't help some who
already use or have invested in other
languages. Industry consortia and
others don't want to change. They want
us to adopt theirs instead of vice versa, but since there are multiple languages,
I think we need to synthesize. For
example, some companies sell software to overcome language incompatibilities,
so their market niche would disappear.
I think the UBL advantages will prevail in the long run, but in the
short run it's hard.
◆
Resource and
political challenges
◆
Technical
challenges--Every company has different way of doing business. The traditional
EDI solution is to identify the union set, standardize, and come up with
implementation guides that say that's what we'll use. Not interoperable, but it works.
All agree that it works, but there's a better way. That's what we're trying to do. We spent a year and a half figuring it
out. The analysis is in the business
context.
Standard documents
are different in different contexts.
ebXML has identified eight key context drivers. There are more, but
these are the most important. The
business process is assumed, and is a parameter in ebXML.
How do we approach
document standardization? We're
building on the core component work. We
need to:
◆
Identify the
largest data structures, and standardize those chunks
◆
Devise a
mechanism for extending the entities to reflect the requirements
◆
Generate
context-specific versions of documents
◆
Point to the
right document types for specific contexts.
Mr. Houser: Is there a way of tracking this on ISO
11179?
Mr. Bosak:
This assumes a lot of functionality, but it doesn't have to come from
one place. Since there are so many
dimensions, the possibilities for types of business forms are large. How do we approach it? Two ways:
You don't do this
often, just once per trading partner relationship. A registry must be there, but it doesn't necessarily require
constant interaction. The conservative approach would be that for the firsts or
second generation we may have to populate forms and set up taxonomies to let
you use them.
Mr. Chandra
Tamirisa: What happens with the others that you don't
use?
Mr. Bosak:
They're out there. Others are
using them. The nice thing is that
they're similar since they were generated from a common library. Your software is already hardwired for
it.
We're starting to
call this UBL EDI. We refer to it as
Basic UBL EDI, Intermediate UBL EDI, and Advanced UBL EDI. Once you have the Basic UBL EDI you can
upgrade to Intermediate or advanced, but it's optional. Somewhere in the future the processes
themselves will decide what to do.
What are the
advantages of UBL EDI? It:
◆
Starts with
the low hanging fruit
◆
Gets small
businesses on board
◆
Fits legal and
trade concepts.
It's nothing new.
Unidentified member: You need signatures to be legally binding.
Mr. Bosak: Yes--UBL says, "Here's our scope." Things like security are assumed (as part of
the ordinary landscape). What today to
you is a set of parameters later becomes a set of data on which we build a
process. It's more powerful than an
approach that has things and policy bound together.
Mr. Tamirisa:
This is the outer layer of any programming technique, right?
Mr. Bosak:
This is what's on the wire. It's
a question about XML in general. Is XML
just on the wire, or how far back into the process does it go? It's interesting to go back to the database,
but it has interesting questions.
Mr.
McKeever: Is the IRS more similar to EDI or XML?
Mr. Bosak: I
don't know. If I were the IRS, I'd make
"e" versions of paper forms.
Mr. Ambur:
Kiplinger's and Intuit use XML in their tax prep.
Mr. Bosak:
Here's my final point though. It
would be so nice to have a Crystal Ball for the Web. I was in SGML advanced electronic publishing when the Web came
about. The things that we and the
universities and the military were doing was more advanced than what you can do
on the Web now.
The Web functionality now is a huge step backward. HTML was there. All the experts said, "No, don't use it!", but after a while they
gave up. The lesson is that if you put
the standard syntax out there it doesn't have to be perfect. If users understand, the smart people will
write complex systems to patch that.
What happened? We came up with a simple tag language and
HTTP. What's happening here is that UBL
could be HTML for business. We have the
semantics and a transport layer.
Something interesting could happen that goes beyond today.
Mr. Ambur: I
call that "dynamic reality" as opposed to theory and models.
Mr. Bosak:
Yes.
What are the deliverables? They are:
◆
Component
Library
·
EbXML/ EDIFACT
is essential for this. We took xCBL as
the starting point
·
It covers the
largest set of document formats
·
It's a
component-based approach
·
It's widely
deployed
·
It's
unencumbered IP (originally developed under a government grant).
What we deliver
won't resemble xCBL. A lot of our work
is from SAP and even they want it to change.
It won't be backward compatible with xCBL. The component library will be aligned with ebXML core components
and is being built using the latest Core Components Technical Specification
(http://www.unece.org/cefact/ebxml/ebXML_CCTS_Part1_V1-8.pdf).
◆
Standard
business documents. In a hear and a
half UBL will consist of a set of XML schemas for common business documents and
a common basis for ad hoc customization in advance of the UBL context
methodology.
◆
Context
methodologies. SAP and Commerce 1
experience with xCBL helps. The
extensibility is too powerful, so things end up not being as accountable as
we'd like. We need to put in place a
more restrictive, structured methodology.
We're not starting
from scratch. We're starting from the
work of ebXML. The people involved are
the same as those who were involved with ebXML.
Unidentified
member: Do extensions mean changes to the schemas?
Mr. Bosak:
Yes--for example, if it's in the auto industry, the address block
requires GPS[Global Positioning System] data.
Others don't.
Mr. Tamirisa: How
does that apply to namespaces?
Mr. Bosak: It
does not.
Mr. Royal: How
do you deal with enumerated lists?
Namespaces might help.
Mr. Bosak:
Namespace was a powerful idea.
Historically, the XML WG was required to deliver it on an uncomfortable
timeline. I'm not sure how some pieces
will work out. I'd say use them only
when necessary.
Unidentified
member: Are you talking about specifically nailing
down XSD schemas?
Mr. Bosak:
Yes. You can use a variety of
schemas to represent structure. DTDs
aren't powerful enough. One question
is, "What should be our canonical one?"
They decided that XSD will be the UBL canonical form. However, there is a real possibility that
everything will be equally representable using Relax NG. Everything ought to be able to be
represented in Relax NG.
XSD was based on
requirements--not an information model--so some coherency isn't conceptually
there. Relax NG is based on a
mathematical model of how things work.
You can take any two schemas and define the intersection between the
schemas. It could be the difference
later on for UBL. For example, two
suppliers with a long relationship.
Another comes along and says, "Our set up is different. What do we do to make them
interoperate? If you could find out how
mathematically, it would help.
Remember that XSD
is just formalizing what you could do in prose. Prose is more powerful, but we're trying to make it machine
processable and adhere to the accepted standard.
Why did UBL choose
OASIS? OASIS is non-profit, and exists
for the purpose of shepherding interoperability standards for XML. It has features I like ,unlike some other
efforts. One is that anyone can join
OASIS. An individual membership is $250
year. Anyone can participate in any committee.
The process is democratic. We
use Roberts' Rules of Order. All mail
lists are publicly visible.
All OASIS Technical
Committees provide a separate mailing list for the public at large. Anyone
interested can sign up for the meeting list.
OASIS has gone from
its roots (consortium of XML and SGML vendors) to being the leading XML
implementation standards body and are heavily involved in ebXML. They have good
connections with the international XML community. They're involved with UN/CEFACT and EDIFACT. They have a member or management group
coordinating interactions with all other standards bodies. These are the organizations pointed to by
the General Agreement on Tariffs and trade.
This group will point you to where you will look for things like "what
is a purchasing order?"
The OASIS UBL
Technical Committee has had two face-to-face meetings and each subcommittee has
an agressive teleconference schedule.
Unidentified
member: What's Microsoft's response?
Mr. Bosak:
They came to the first meeting, then nothing. We want involvement, but it hasn't happened. I interviewed with a magazine in which I
poked at Microsoft, and so far nothing has happened. As far as I can tell, UBL won't hurt Microsoft. With the ebXML infrastructure pieces and UBL,
we're ready. I'm talking about their
functionality, not the pieces themselves.
I think UBL would work with Biztalk.
If anyone has Microsoft connections, send them to me.
Mr. Neimann Sr.: The
next version of Biztalk will have about 200 adapters.
Mr. Bosak:
Maybe they have it covered and it doesn't need UBL, but eventually, will
they see sense in maintaining adapters?
Mr. Bosak then
briefly displayed the UBL website.
Mr. Bosak: The
UBL Technical Committee subcommittees consist of:
◆
Technical
subcommittees
◆
Content
subcommittees
◆
Administration
Any OASIS member
can become a voting member of a subcommittee.
We'll define further subcommittees when the need arises. The UBL Technical Committee is a Roberts
Rules organization, so you have to be in the room to vote. We recognize that travel is a problem, but
we need you to be there.
The rules of the
UBL Technical Committee allow you to be a member of any subcommittee, so you
can participate without traveling. It's nice if you come to the quarterly
meeting, but there's no quorum problem if you're not there as long as you
participate in subcommittees.
Just to tell you a
little about some of the committees--
We have a Library
Content Subcommittee that is determining what tags we use. Tim McGrath from Australia chaired the
quality review team of ebXML and is chairing this group. A number of members
are from ebXML and UN/CEFACT. The first straw man draft of a purchase order is
due to come out mid-March.
The UBL Naming and
Design Rules Subcommittee--Eve Maler from Sun is the chair. She is editor of a number of W3C XML
specifications and author of the authoritative book on DTD design. A number of other people, all XML experts,
make up the team. Other efforts will probably follow what this group does. These are some of the best minds, looking at
the questions that everyone will have to resolve for using XML for
business. Their solutions can be
leveraged by other standards efforts.
The UBL Liaison
Subcommittee has different membership.
I'm the chair. The
representatives on the subcommittee are formally designated by the industries
that we want involved. (UBL lets
industry consortia pool their resources to develop interoperable business
documents.) This committee handles the
logistics of reviews of documents that industry develops and submits for
examination.
Mr. Bosak displayed
a slide outlining the alternatives for participating in UBL.
The bottom line is,
we're grounding this in solid design rules, based on ebXML core
components. It goes beyond EDI to
enable cross-industry B2B interoperability.
It's an open process that is vendor neutral, and it's intended to be a
long-term solution for exchange of business data.
Mr. Houser: Is
Theresa Sorrenti interested or involved?
Mr. Bosak:
Yes, and we work closely on this and UN/CEFACT. Many of members of UBL are working with
UN/CEFACT. Much of UBL is being applied
because it's a match.
Mr. Royal:
It's not a duplication.
Mr. Kevin
Williams: How does focusing on the message rather than
the transport work? Will UBL endorse a
specific transport?
Mr. Bosak: We
don't bind ourselves to an infrastructure because of proprietary and
non-proprietary resources. The ground
is too soft. There are business
interests involved, so it hasn't happened.
Sun was the biggest contributor to ebXML, at large cost. I'd like to see it pay off, in that here we
have a standard that does a job.
There's no telling where the future goes. We must be careful not to depend upon an infrastructure.
Mr. Williams:
Right now there isn't just one standard.
Mr. Bosak: The
good thing about focusing on payload is that we can decouple from the transport
and the business process framework. We
defer questions on how we model the business process. Ours is more short term.
We want some agency to define a dictionary of business processes so we
can point to values to plug into our context record. All the efforts I know of are too big.
Ms. Theresa Yee: Are
you familiar with X12 efforts?
Mr. Bosak:
Yes--and I'm kind of distressed. We've been putting UBL together publicly
for a year, with tricky political ground.
It looks as if X12 is duplicating it.
Ms. Yee: I
thought they were working together with you.
Mr. Bosak: I'd
like them to. By doing it in OASIS they
can do it with both groups. X12 and
EDIFACT were supposed to work together on core components. No one owned the effort organizationally,
which caused procedural problems. In
OASIS, Technical Committees can define their own internal workings, so we can
easily set up UBL to function as if it can work with both. It would be the best of both worlds. We'd meet with both groups, leverage
expertise, etc. So far EDIFACT is
working out. They are hosting some
meetings. We have a commitment from
them. That's not so on the X12
side. I hope they'll see it as a
benefit.
Ms. Yee: X12
said there are two approaches, and they're introducing the middle ground.
Mr. Bosak:
That sounds good to me.
Ms. Yee: We
thought X12 was working with top-down approaches.
Mr. Bosak:
There's an informal liaison, but we want a real partnership. Only a few hundred people are qualified to
work on this. The trick is to develop
momentum to get the proper people involved and pool resources. So far it hasn't happened, but I think it
will.
Mr. Tamirisa:
With a persistent document-centric approach, you'll have schemas that
represent the underlying information, but the data has to be persistent in
storage somewhere, right?
Mr. Bosak: The
schema doesn't contain data--the instance does.
It's on the wire. How far into
the back end you want to integrate XML is a design question.
Mr. Tamirisa:
Wouldn't you say it takes design data and transforms it?
Mr. Williams: Not
necessarily. It's environment specific. It's dependent upon the need.
Ms. Lorber:
There are business processes involved.
UBL doesn't rely on where or how it's stored.
Mr. Ambur: Do
the legacy systems meet the requirements for records management?
Answer from
floor: Many don't.
Ms. Lorber:
Many managers don't understand where the technology is moving. What do you capture, and how? You're not dealing with the signature authority,
but no one in the federal government wants to test it in the courts. There are obstacles that society needs to
deal with.
Mr. Ambur:
There's the case study example.
The reason the Department of the Interior is disconnected from the
Internet isn't because of an untrusted network. The hacking occurs within the firewalls. You need to secure the individual record. XML does it. You can secure the record and make information about it available
to the database. Designers don't
understand the requirements.
Mr. Bosak:
Neither do the vendors.
Ms. Lorber:
It's true beyond web services.
Mr. Eng: EPA
has its own domain-specific expertise.
What can we do in our own organization to get ready for the future to
feed into the whole process using the UBL framework? How can we take advantage of the benefits? We're implementing some XML. How can we stage it to be able to use what
develops?
Mr. Bosak: I
don't have the organizational expertise to know that, but you need to identify
the stakeholders and elements. I suggest you contact consultants who specialize
in this part of the problem. Most of
them have been doing it for a while.
One of the problems is the implicit faith that if you semantically
identify what people are doing in different places you can construct
transformations. I don't really know if
that's the cure. If you can actually do
that, then why can't you eliminate one of those? In an organization with legacy systems, this is a big problem and
I don't know the solution.
Mr. Royal: One
of the things from the library content group--as first start we took the core
component catalog and compared it to xCBL.
It didn't contain everything we needed.
The second thing we did was analyze why these elements are here. How do we express the library name using the
catalog? You start using the ISO 11179
name. It's the same challenge as if you
took legacy systems and said, "How do we break it down?" Your tag name can be anything. What's valuable is the process we're going through.
Mr. Bosak:
Even if you're outside UBL, it might be useful to look at what UBL is
doing.
Mr. Royal:
We've found several big things.
Ms. Turnbull:
There are barriers to participation.
Do small businesses know enough to clamor for this as a strategic
priority?
Mr. Bosak:
They clamor for whatever is marketed the best. Sometimes they don't know what they want until they see it. It's true with the Web. We would have designed it more powerfully.
Ms. Turnbull: We
could leverage this with the Small Business Administration to bring long-term
benefits to small business.
Mr. Bosak: We
have some involvement from government agencies, and we need a lot more.
Ms. Turnbull:
USAID as well.
Mr. Bosak: The
most exciting impact of this to me is the impact on small businesses.
Mr. Niemann Sr.:
We've been talking about registering all the information in the data
forms. Are they going to be able to do
that? Will UBL address
government-specific need?
Mr. Royal:
Yes, from the document perspective.
Once we examine more documents, we'll be able to move faster.
Mr. Niemann Sr.: I
liked that you said you can't do the semantic part with a machine. We've
invested heavily in ISO 11179 , and I just realized that it's not the registry
that `s valuable, but the expertise that the people have developed over the
years .
Mr. Bosak:
Yes.
Mr. Niemann Sr.: The
people can't actually use the registry, but rather the mechanical
processes. We're trying to do simple
harmonization, but it's still very much a human process.
Mr. Bosak: AI
people say eventually it won't be, but that won't happen any time soon.
Mr. Niemann Sr.:
Whether you build an ISO 11179 registry or not, it gets people familiar
with the semantic meaning of data elements across a data dictionary.
Mr. Eng: It
takes nine years for some of these efforts.
Some of the people who made the systems are retiring. We need to capture their knowledge.
Mr. Bosak:
This kind of project is a good way to do that.
Mr. Tamirisa: It
seems like a team effort, because we can't have a technical guy understanding everything. People who understand each
aspect should put it on paper.
Mr. Bosak:
It's definitely a committee thing.
Mr. Ambur: OK,
it looks as if we're out of time. My thanks to Jon for sharing this.
A briefing and
demonstration of registries and repositories with inherently government data
elements will be the primary presentation at next month's meeting. Thank you everybody.
End meeting.
|
Last Name |
First Name |
Organization |
|
Ambur |
Owen |
Interior-FWS |
|
Becker |
David |
CSC |
|
Billups |
Prince |
DISA |
|
Blewett |
Jay |
DOE |
|
Burge |
Morais |
DTS |
|
Cabaniss |
Jelks |
Formstyle |
|
Christian |
Eliot |
USGS |
|
Dodd |
John |
CSC |
|
Eng |
David |
EPA |
|
Houser |
Walt |
VA |
|
Hunt |
Jim |
GSA |
|
Kaiman |
Charles |
ATS |
|
Lewis |
Diane |
DOJ |
|
Luczak |
Ed |
CSC |
|
Maxey |
Katherine |
MNG/SRA |
|
McKeever |
David |
i4i |
|
Milligan |
John |
Millican & Associates |
|
Niemann |
Brand |
EPA |
|
Niemann, Jr. |
Brand |
Tax Analysts |
|
Polutta |
Mathew |
i3 Solutions |
|
Poot |
Lex |
DTS |
|
Rand |
Robert |
SEC |
|
Royal |
Marion |
GSA |
|
Saiya |
Patricia |
FormatData |
|
Saiya |
Jim |
FormatData |
|
Tamirisa |
Chandra |
Federal Reserve Board |
|
Turnbull |
Susan |
GSA |
|
Yee |
Theresa |
LMI |
|
Yurow |
Jerome |
DOE |