Federal CIO Council XML Working Group
Meeting Minutes, May 16, 2001
General Services Administration, Room 5141B

Please send all comments on/corrections to these minutes to Laura Green.

Working group co-chair Owen Ambur convened the meeting at 9:05 a.m. at the General Services Administration. Attendees introduced themselves. Attendees utilizing the teleconferencing capabilities were asked to access the presentations at the XML.gov website. The chairs asked for any comments on/corrections to the April 18 meeting minutes. None were forwarded and the minutes were approved.

Announcements

1. Mr. Ambur announced that On June 6 FIRM is sponsoring a forum at the USDA auditorium. Kevin Landy of Sen. Lieberman's staff will discuss S. 803, the E-Government Act. Mr. Ambur will relate some of the provisions of the bill to the potential of XML and a representative of OASIS will drill more deeply into the relevant XML-related standards activities, including eXtensible Access Control Markup Language (XACML).
2. Mr. Ambur announced that on June 4 and 5 at the Hyatt Crystal City, the Association of Records Managers and administrators (ARMA) will sponsor a conference on strategic information management. Based upon Mr. Ambur's meeting with them concerning the potential of XML relative to records management, they would like to more actively engage Federal CIOs.
3. Mr. Ambur announced that at the request of the Senate Government Affairs Committee, GAO is conducting a study of the Executive Branch's implementation of XML. The investigators have already met with the XML WG co-chairs and will be interviewing others as well. Those contacted are encouraged to be as creative and forthcoming as possible. The WG co-chairs anticipate that the report will be largely positive but that GAO will have some constructive criticism that should be taken into account.
4. Mr. Ambur is scheduled to meet with the Partnership for Intergovernmental Innovation (Pi2) this week (May 16) and the National Association of State CIOs (NASCIO) next week (May 22) to discuss how State and local government agencies might be more effectively engaged in the activities of the WG.
5. Mr. Royal urged WG members to register their XML initiatives on XML.gov.

Mark Crawford of the Logistics Management Institute (LMI) briefed the WG on ebXML's latest work and next steps. This presentation is available on the XML WG website in both PowerPoint and HTML formats.

A joint initiative of the United Nations (UN/CEFACT) and OASIS, ebXML is a set of specifications that together enable a modular electronic business framework. ebXML enables a global electronic marketplace where enterprises of any size and in any geographical location can meet and conduct business with each other through the exchange of XML based messages. Participants in the initiative include a "who's who" of XML and EDI. The initial product of the effort is a technical framework that will enable XML to be utilized in a consistent manner for the exchange of all electronic business data.

Mr. Crawford then showed the WG a slide outlining the organizational architecture of the initiative. Two representatives from each of the sponsoring organizations sit on the executive committee. The steering committee consists of the members of the executive committee and the project team leads. The organization slide shows most of the project teams.

There are three levels of components of the ebXML initiative. Requirements are at the top level and are supported by techniques and modeling methodologies. These were all used by various project teams. Process and Information Specifications exist at the middle level. The lower level includes the technical framework, implementation specifications, information packaging, and business service interfaces. All of these components are supported by the registry/repository.

ebXML has deliverables in four areas:

1. Technical specifications, which Mr. Crawford encouraged all WG members to review,
2. Technical reports, which are not to be considered standards, but are merely informative in nature,
3. Reference materials, such as the ebXML glossary, and
4. White papers, which are created by the various project teams in response to issues that either could not be addressed during the project period or that arose as the project teams worked.

Mr. Crawford then displayed a list of currently approved ebXML technical specifications. The ebXML Technical Architecture Specification provides, amongst other things, an overview of the entire ebXML framework and ebXML XML naming conventions. The Business Process Specification provides schema for coordinating and conducting business process discovery and documentation. The Registry/Repository Specification provides information for people to go out and develop ebXML compliant registries and repositories. The Requirements Specification provides supplementary information that developed over the last 12 months to provide a jumping off point for follow-up work and a roadmap for people outside of the ebXML initiative. The Trading Partner Specification lays out the process for collaboration of protocol profiles and agreement amongst trading partners. The Transport, Routing, and Packaging Specification lays out how to package and exchange content with ebXML.

Walt Houser (VA) commented that he believed the packaging for ebXML was being done in SOAP.

Mr. Crawford replied the SOAP is part of the packing initiative and that there is a W3C effort underway to take the SOAP initiative from Microsoft and IBM and make it a part of the W3C. SOAP is a piece of the ebXML trading partner specification.

Ward Braaten (NSF) asked if the ebXML initiative had addressed UDDI.

Mr. Crawford replied that UDDI is addressed in a white paper on how to best use UDDI to find ebXML registries. However, since UDDI has just reached phase 1 of a three-phase development process, it is not yet mature enough to be included in any of the ebXML specifications.

Mr. Crawford then reviewed the Technical Reports that were approved. The Business Process Project Team developed a meta model for how to develop business processes, how to refine those processes into a standard modeling method. While the traditional approach to modeling emphasizes modeling internal processes as a precursor to internal development, this report presents a new approach that looks across the organization. Additionally, the project team released a report on security. The first piece of this report discusses security and emphasizes a focus on the policy level rather than an individual application level. The second piece of the report provides a risk assessment of each specification.

The Core Component Project Team developed a definition of a "core component," a methodology for how a core component is discovered and documented, and a methodology for defining how a core component should be used and how context should be applied to it.

Several White Papers were released. One was from the Business Process team proposing changes to be made in the Technical Architecture Specifications. Another white paper proposed the use of UDDI to discover ebXML registries/repositories. The final white paper offered recommendations for improving ebXML security based on the report issued by the Business Process Project Team.

Mr. Crawford then showed the WG a slide describing the ebXML technical framework. This diagram is available in the ebXML requirements document, which also contains an expanded explanation in the technical framework section.

Mr. Crawford then showed the WG a slide outlining the ebXML Business Collaboration Process. This process is a key feature in ebXML and is, in fact, the centerpiece of what ebXML is focusing on. All aspects of the process are interrelated.

Mr. Crawford then showed the WG a slide outlining the ebXML Business Analysis Process.

The Core Components Project Team defined a core component as the lowest common denominator (datum) of an information element. A core component is a data building block that can be used regardless of the syntax used. A set of related core components comprise an aggregate, and a set of related aggregates comprise a document part.

A core component is not intended to be functionally specific (e.g. the core component "time" in and of itself is neutral). It is the context in which the component is used that gives the component meaning (e.g. "shipping time"). Context can be used with aggregates to piece together the various document parts that are used to build a particular business document.

Dan Schneider (DOJ) asked if the slide diagramming the relationship of core components is part of the technical specification document.

Mr. Crawford replied that all of the diagrams come from ebXML documents and each slide contains the citation for each source document.

Mr. Schneider inquired as to the availability of the ebXML documents.

Mr. Crawford replied that the documents are all public domain, and that all ebXML technical specifications are freely available to all interested parties.

Mr. Schneider asked if OASIS is following a similar model.

Mr. Crawford replied that it is.

Mr. Houser asked if the terms aggregate and component are analogous to class and component.

Mr. Crawford responded that that was probably a good analogy. ebXML wanted to go about its work from two different approaches: bottom up from the core component level and top down from the business process level. The reasoning behind having two approaches was that the top down approach would not provide a clear understanding of the underlying data components or the individual pieces of the various business processes.

Charles Daringer (LABAT) observed that this seems like it is a formal vernacular that people can use to document and communicate in a technological fashion where there is a common denominator.

Mr. Crawford added that the development of core components was an attempt to minimize the artistic approach to modeling and standardize the process.

Mr. Houser stated that he would assume that "context" refers to something like an 810 or 840 transaction.

Mr. Crawford replied that the context would be the way in which individual pieces are used within an 810. In the EDI environment, a purchase order can be used in multiple contexts. One should think of the Implementation Convention (IC) as the context driver of the transaction.

Bill Morgan (GSA) asked if the context would be an instance and if each aggregate could have multiple contexts.

Mr. Crawford replied that an aggregate could exist without context.

Glenda Hayes (MITRE) offered an example. A component could be longitude, an aggregate would be location, and the context would be target.

Mr. Crawford then showed the WG a slide illustrating the ebXML registry and repository. There are two ways to interface with the registry and repository. The first is through a web browser, the second is through an interface tied directly to the user's desktop.

Mr. Morgan asked where UDDI would fit into this picture.

Lisa Carnahan (NIST) responded while ebXML would like to use UDDI as a means of finding ebXML registries and repositories, UDDI was not far enough along in development at the time the technical specifications were approved to be included in those documents.

Mr. Crawford then showed the WG a slide illustrating the ebXML message service handler components.

Mr. Royal asked if ebXML would add an additional layer on top of SOAP.

Mr. Crawford replied that it would.

Mr. Royal remarked that RosettaNet was impressed with the ebXML messaging service and will either fully adopt it or ensure that its nest version of the RNIF will be compatible with it.

Mr. Crawford added that there is a lot of thought within RosettaNet on convergence. RosettaNet was a key player within the work on ebXML. There has been a bi-directional sharing of information between RosettaNet and ebXML.

Andy Moir (RosettaNet) told the WG that RosettaNet is not interested in working on the transport layer. RosettaNet is more interested in the content process.

Mr. Crawford then showed the WG several slides diagramming the trading partner profile creation process. The trading partner profile documents used in EDI were not user friendly and did not support discovery, which is very important. ebXML uses TPAML (Trading Partner Agreement Markup Language) to create these documents. IBM created TPAML and, in yet another example of bi-directional sharing, gave the property rights for the language to ebXML.

Trading partner profiles are used to create Collaboration Protocol Agreements (CPAs).

Mr. Houser asked if anyone has implemented this yet.

Mr. Crawford replied that the specification addressing trading partner relations was just approved on Friday, May 11, 2001 and thus has been implemented only through a proof of concept exercise.

Mr. Houser asked if any interoperability testing was ongoing.

Mr. Crawford responded that, to the best of his knowledge, there is no testing underway. The issue of testing is one the steering committee is still interested in. Additionally, NIST recently put forth a proposal to begin some testing work, but testing will probably be done under OASIS and in partnership with project teams in OASIS.

Mr. Houser asked if OASIS requires implementation prior to issuing a specification.

Mr. Crawford replied that he did not recall anything in the OASIS bylaws requiring that.

Mr. Daringer asked if there is a third party voucher for digital signatures.

Mr. Crawford replied the ebXML was not about building, but about developing blueprints. The Data Interchange Standards Association (DISA) is holding discussions with XML Global to build a registry and repository.

Mr. Daringer commented that there must be no controlling authority.

Mr. Crawford responded that that issue is up to the person who creates the registry.

Mr. Braaten asked if IBM has developed a prototype or infrastructure.

Mr. Crawford replied that he is not aware of any. ebXML has finished the work on TPAML that IBM had begun.

Mr. Morgan asked if the Trading Partner Profile poses a risk in terms of security.

Mr. Crawford replied that it does, and urged WG members to look at the ebXML security documents for a discussion of key issues.

Mr. Morgan asked if anyone has foreseen any potential problems with ebXML adoption in foreign nations since ebXML has been developed from a primarily English perspective.

Mr. Crawford acknowledged that some tailoring will have to be made. In keeping with the UN's work, all of the ebXML documents are in English. There has been no work on ebXML's part to make translations available.

Mr. Royal pointed out that XML is based on Unicode.

Mr. Crawford added that such issues will be addressed by the Trading Partner Project Team during its follow-on work or by the people applying their context to the specification.

Mr. Crawford then showed the WG a graphic describing the security features of ebXML. There is an emphasis on moving away from an individual application level approach to security to one that based on policy and addresses all aspects of security. The Business Process Project Team's security report provides a good treatise on this approach to security and a risk assessment of ebXML.

ebXML was chartered to be an 18-month initiative. Those 18 months are now over. This does not mean that the initiative will completely dissolve, as someone needs to maintain and continually update the technical specifications in a collaborative fashion.

A joint Memorandum of Understanding (MOU) was signed on Friday, May 11, 2001. The MOU lays out Phase II of ebXML. ebXML will become a virtual organization with its two sponsor organizations taking charge of the project teams. UN/CEFACT will stewardship of the Core Components and Business Process teams. OASIS will receive stewardship of the Transport, Routing, and Packaging, Registry and Repository, Trading Partner, and Security teams. This division makes sense, for UN/CEFACT is a more business-oriented organization, while OASIS consists primarily of vendors and is more technically-oriented.

The ebXML Management Team will coordinate project team work, but will not direct or supervise the teams' activities.

Current participation in any of the project teams will be grandfathered into the new teams.

Mr. Crawford then briefed the WG on related efforts with respect to ebXML. One of these will be a Joint Core Components initiative. Because core components documents were not published as technical specifications, there is a requirement to finalize them and write technical specifications. This will provide an opportunity to finally harmonize national and international business standards.

The next ebXML meeting will be held in St. Louis from 3-8 June, 2001. Exactly how UN/CEFACT will take control of the core components work has yet to be decided, and this will be a major issue at the next meeting.

Mr. Crawford then addressed the actual use of XML in ebXML. There was a very deliberate effort on the part of the ebXML leadership to avoid developing standardized XML content partly because the W3C schema recommendations had not yet been issued. There is no mention of standardizing XML content in the MOU for Phase II. This is a black hole waiting to be addressed.

Currently, there are a number of XML initiatives underway throughout industry. The vast majority of these initiatives are vertical in nature. Most of these vocabularies will be dead in the next couple of years for several reasons, the foremost being that they are short sighted in nature and do not acknowledge that any business deals in more than just its own core business. This puts a heavy load on IT staff. The right approach to these initiatives in a b2b environment is to create a horizontal standard. The CEFACT Steering Group is currently considering a proposal to create a standardized XML vocabulary. This would be an international standard for business transactions that would significantly minimize the impact on IT staffs trying to support multiple proprietary standards.

Mr. Royal asked how long such an effort would take.

Mr. Crawford replied that the plan is to use an existing XML vocabulary as a baseline. The group would deconstruct this vocabulary, and develop design rules and naming conventions for a new one.

Mr. Royal expressed doubt that all of the vertical initiatives will be gone in two years.

Mr. Crawford replied that while not all would be gone, a large percentage would. Companies have to understand that the b2b aspect of XML is only one of many aspects. A horizontal standard would provide for an enterprise-wide approach.

Dr. Hayes asked for the level of granularity at which the registry operates.

Ms. Carnahan replied that the registry specification is such that a person can register anything. However, there is no mechanism specified to pull various elements together.

Dr. Hayes asked if she was correct in assuming that if she desired to register a geo-spatial location, there would be no mechanism for her to tell where that component is being used.

Ms. Carnahan replied that there is such a mechanism.

Mr. Crawford added that the registry cannot currently do something that the ebXML folk want it to be able to do: to be able to use core components to build a transaction on the fly.

Dr. Hayes observed that there is not too great a difference between the DISA and ebXML registries.

Mr. Crawford urged her to foster a relationship between ebXML and DISA/DLIS. There is a difference, however, and that is that individual organizations that enter into ebXML get to decide how they are going to control namespaces per their own internal policy.

Dr. Hayes opined that even if core components are syntax neutral, something has to represent them. She asked how the core components are represented.

Mr. Crawford replied that ebXML finalize on the components available in the registry.

Mr. Daringer felt that it would be a good idea to utilize the aggregate syntax in documenting current systems just to bring along the idea of moving towards ebXML.

Mr. Crawford pointed out that the core components in part serve as a stepping stone from identifying basic data to modeling business processes.

Mr. Ambur asked what actions the members of the WG should recommend to their CIOs with respect to ebXML and what value the WG should try to add to the initiative.

Mr. Crawford responded that from an architecture standpoint, members should be looking at each of the technical specifications within ebXML. ebXML will be supported by leading software vendors, so agencies should seriously consider adopting it.

Mr. Ambur asked if, at the next EIEITC meeting, he should tell the technical architecture specialists that they should be looking at ebXML.

Mr. Crawford replied that he should, because, from a technical standpoint, ebXML provides an off-the-shelf solution that works for all interfaces. From a business process standpoint, ebXML provides a way to standardize business content. Additionally, by buying into this process, agencies will be in line with many policy requirements.

Mr. Daringer pointed out that even if one is in the middle of an implementation, on could at least adopt the ebXML naming conventions and use the ebXML processes to at least extend the bridge from one's own implementation to ebXML.

Mr. Crawford added that the ebXML specifications were designed to be of the "plug and play" variety. A user does not have to subscribe to all parts of the ebXML specifications. However, it is strongly recommended that all organizations buy in to at least part.

The WG then broke for 10 minutes.

Andy Moir (RosettaNet) then briefed the WG on RosettaNet's mission, vision, and accomplishments. This presentation is available on the XML.gov website in PowerPoint format, HTML format, and PowerPoint without the slide template.

Mr. Moir is a Partner Relations Manager for RosettaNet. Partner Relations Managers work with member companies to facilitate implementation of the standards developed by RosettaNet. Part of the RosettaNet initiative is setting milestones for implementation.

Mr. Moir repeated Mr. Crawford's earlier comment that there is a good synergy between ebXML and RosettaNet.

RosettaNet came about from a recognition that major industry trends demanded action. These trends are outlined in one of Mr. Moir's slides. Companies can no longer view themselves as solely involved with one activity such as shipping, for they are now doing a little bit of everything.

Mr. Schneider asked for a clarification between "linear" and "dynamic" supply chains.

Mr. Moir replied that in a linear supply chain, a company does one thing, and that is all it does. For example, FedEx used to concentrate solely on shipping.

One of the major industry trends that RosettaNet seeks to address is the lack of explicit agreement on data exchange processes in the XML world. The XML world is a bit like the Wild West in this regard.

Mr. Moir then took the opportunity to point out that RosettaNet is not an XML initiative. It is a business process initiative that uses XML as the vehicle to exchange data.

Mr. Moir then showed the group a chart displaying trends in eBusiness worldwide. It is important to note that money is moving out of b2b initiatives and into net market initiatives.

RosettaNet's vision is to be the leader in global eBusiness standards. Its mission is to drive collaborative development and rapid deployment of internet-based business standards, creating a common language and open eBusiness processes that provide measurable benefits and are vital to the evolution of the high technology trading network.

RosettaNet is trying to highlight the difference between message-centric (e.g. EDI) and process centric (e.g. RosettaNet) information exchange standards.

RosettaNet was formed in June of 1998. Its initial focus was on computer companies (such as IBM and Intel) and an attempt to bring them in synch with one another—to foster an agreement that they would all use the same business processes.

Mr. Schneider asked why Nokia and Sony were singled out on the RosettaNet History slide.

Mr. Moir replied that Nokia's joining RosettaNet kicked off the RosettaNet effort in Europe. Additionally, it was a movement towards the formation of a telecommunications boards within the RosettaNet collective. Sony's joining RosettaNet was a big kick for Japan, where many companies were waiting to see what Sony would do before agreeing to join RosettaNet. The formation of the Semiconductor Manufacturing Board created RosettaNet's third board. Currently, RosettaNet is has member companies from Japan, Taiwan, Korea, and most of Europe. It is in discussions with China at this moment.

Mr. Morgan asked if there were any member companies from south of the equator.

Mr. Moir replied that RosettaNet is currently holding discussions with South American companies.

RosettaNet calls its member companies "Supply Chain Partners." RosettaNet works with other standards organizations when it develops standards. It believes in being in a share mode—it shares what it creates and uses what other groups have created. Additionally, RosettaNet has key associations with European and Asian organizations and solution providers .

Mr. Moir then showed the WG slides illustrating the RosettaNet governing process and the member companies of each of the three supply chain boards (Information Technology, Electronic Components, and Semiconductor Manufacturing).

Mr. Schneider asked if these lists of member companies were all inclusive.

Mr. Moir replied that these were lists of board members. Some RosettaNet member companies may be on more than one board, and some may be on no boards.

Nauman Malik (DFAS) commented that he did not see Advance Micro Devices listed as a member.

Mr. Moir responded that AMD may be a RosettaNet member but not a member of any of the boards.

Mr. Ambur asked if Gateway had expressed any interest in being a RosettaNet member.

Mr. Moir replied that it has not and that he is not sure why. At RosettaNet's inception, the board members wanted 80% of the IT market. For a while, Dell was not a member. When the board members realized this, each one of them wrote Dell a letter asking why it had not joined. RosettaNet is a very top-down organization. There are very senior officials from member organizations involved.

RosettaNet is considering creating Automotive and Telecommunications Supply Chain Boards.

Dr. Hayes asked if GM has expressed any interest.

Mr. Moir replied that a RosettaNet senior manager has been in to talk several times with the big motor companies. Right now, RosettaNet is working primarily with these companies' major suppliers.

Dr. Hayes commented that she understood that GM is driving its suppliers to conform to GM proprietary schema and was using XML to allow non-EDI enabled suppliers to come onboard.

Mr. Moir says he is unaware of any big pushes in that direction.

Mr. Royal inquired as to whether or not RosettaNet has considered moving into the aerospace industry.

Mr. Moir replied that he is unaware of any interest in working with the aerospace industry. Some discussions are being held on entering the general merchandise industry. But, if RosettaNet were to participate in general merchandise, it must be specific that it is participating on behalf of the computer industry. RosettaNet does not want to be all things to all people.

Mr. Morgan noted that RosettaNet supports vertical initiatives and asked if it supports any horizontal ones.

Mr. Moir responded that the only horizontal initiative RosettaNet has gotten into is with the computer and electronic components industries.

Mr. Moir then showed the WG a slide illustrating RosettaNet's business process architecture and emphasized that RosettaNet is just the middlespace between trading partners. RosettaNet will not make a company change how it does business, it just sets the business rules for engagement.

Mr. Moir then showed the WG an illustration of e-Business exchange with RosettaNet to provide a visual representation of RosettaNet's scope (in green). RosettaNet currently uses DTDs within a UML document, but will begin to move to using schemas. The framework piece of this exchange is where RosettaNet envisions ebXML will fit.

RosettaNet's business process architecture consists of Partner Interface Processes (PIPs), RosettaNet Dictionaries, and RosettaNet Implementation Framework (RNIF) Core (messaging services).

A PIP depicts the activities, decisions, and interactions that fulfill a business transaction. It specifies the structure and format of business document payloads. PIPs are organized by clusters and segments.

Dr. Hayes observed that there seems to be an overlap with trading partner agreements.

Mr. Moir replied that part of what RosettaNet is trying to do is de-emphasize the trading partner agreement. RosettaNet's goal is to say, "This is the process for purchase orders." If you are a RosettaNet member, your handshakes will all be the same, the security will be the same, and this sameness cuts down on the size of any trading partner agreement.

Dr. Hayes clarified that she meant trading partner agreement in terms of ebXML.

Ms. Carnahan stated that one could take an ebXML CPP profile and specify with PIPs you will use within those profiles and the agreement will be the intersection of these PIPs. ebXML does not require that trading partner agreement business processes be ebXML processes.

Mr. Morgan asked if RosettaNet has any competitors or envisions ever having any.

Mr. Moir replied that most people refer to ebXML as a competitor, which is a false statement because in fact ebXML and RosettaNet complement one another. RosettaNet is merely trying to solve one industry's problems.

Mr. Royal pointed out that RosettaNet is very focused on what it is doing for the computer industry. The electronic components and semiconductor manufacturing companies must be included, for they are necessary components of a computer. PIPs take advantage of technical dictionaries from these companies. Other XML initiatives are very generic and broad, while RosettaNet is very focused. The closest the government has been able to come is exchanging information amongst its member agencies. GSA is trying to use some of the PIPs to be able to exchange information with other agencies and vendors.

Mr. Moir added that RosettaNet is only concerned with the high tech industry.

Mr. Morgan asked how RosettaNet facilitates its work, in terms of monopoly and innovation.

Mr. Royal pointed out that RosettaNet provides an open standard.

Mr. Moir responded that the initiative is very realistic. The reality is that all companies need to look at what suite of solutions they need. If a company services the high tech industry, then it needs RosettaNet. RosettaNet is very niche and it realizes that.

The RosettaNet Business Dictionary defines DTDs and naming schemas. The Technical Dictionary specifies common product properties.

The RNIF Core Implementation Framework was created because there was nothing else like it in existence at that time. Now that ebXML has one, this framework may go away.

Mr. Moir then showed the WG a slide illustrating the RosettaNet process model. It is categorized by "clusters." Each cluster is a cluster of business activities. Within a PIP, one can move multiple messages.

Mr. Moir also showed the WG a slide illustrating the standards management process, which describes how RosettaNet's standards are created.

Mr. Royal pointed out that when RosettaNet was first started, it planned to identify everything that needed to be done and start working on it. Its attitude has change to working only problems that are brought to its attention.

Mr. Moir added that the partners are still trying to figure out how they feel about that change. Currently, RosettaNet is operating on priorities.

With regards to the standards management process, Mr. Moir pointed out the public feedback and validation pieces. This is the point at which the PIPs go out into the public space. RosettaNet incorporates the feedback it receives. RosettaNet will release PIPs that are not validated. Once a group of companies has implemented the PIPs, RosettaNet can released them as validated—that is, release them as PIPs that everyone knows can be implemented.

Mr. Moir then showed the WG a list of the PIPs produced in FY 2000 and a list of FY 2001 priorities. He also shoed a list of board-approved FY 2001 milestones. RosettaNet's iHub model is becoming more popular and two supply chain boards will be working on it.

Dr. Hayes asked if the work being done on Product Data Standards will bring in PDML.

Mr. Moir replied that the Product Data Standard (PDS) project is a little nebulous at this moment, as it has no milestone date yet.

If any WG members have follow-up questions, please contact Mr. Moir at andy.moir@rosettanet.org.

Mr. Royal announced that there will be a UDDI presentation at GSA on May 17. If any WG members wish to participate via teleconference, the number will be 888-780-9652; use teleconference moderator "Royal" and password "UDDI."

Mr. Ambur asked the participants to send him any talking points they may wish to propose for Lee Holcomb's meeting with the State CIOs.

Next Meeting: June 20.