[Cache from http://xml.gov/minutes/20020220.htm; please use this canonical URL/source if possible.]

Federal CIO Council

XML Working Group

Wednesday, February 20, 2002 Meeting Minutes


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




    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



        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



        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




    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. McKeever: What are the challenges?


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




        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.



Section 1: Web Services for Business


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.



Section 2: A Program for Change


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.



Section 3: UBL


What is it?


    A synthesis of existing languages


    Primary inputs: xCBL, ebXML, ebXML Core Components, ebXML context methodology.





    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:


  1. Do it at run time. UBL says that `s possible, but we assume that run time is ambitious right now and so we'll:


  1. Do it at design time. Those different forms will all live in the registry. Our problem is to determine which order form we'll use and the registry will have it.


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.



Section 4: UBL Deliverables


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.



Section 5: The UBL Technical Committee


Mr. Bosak: The UBL Technical Committee subcommittees consist of:


    Technical subcommittees


    Content subcommittees




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




















































Millican & Associates




Niemann, Jr.


Tax Analysts



i3 Solutions


















Federal Reserve Board