Participants
Kendra Martin, American Petroleum Institute, Chair
John Hervey, National Association of Convenience Stores
William Kammerer, Geffeg mbH
David Paraiso, Integrated Technologies
Peter Pruyne, Syscom Strategies
Mike Rawlins, Rawlins E-Commerce Consulting
Lisa Seaburg, Commerce One
Leon Shiman, Shiman Associates
Lisa Shreve, Syscom Strategies
Alan Kotok, DISA
Summary
At this meeting, participants agreed on the following deliverables and work plan:
Requirements definition, chaired by Mike Rawlins, to define functions of the DISA registry, with a report submitted to the DRIve Committee by the end of October
Evaluation of ebXML registry specifications against the DRIve requirements, with a report submitted to the DRIve Committee and copy to the OASIS ebXML registry technical committee
Proposal of DRIve registry operations, based on the requirements paper, chaired by Leon Shiman
DRIve registry pilot, chaired by David Paraiso, and making use of the offers of software by vendors and schemas by DISA vertical industry affiliates
Meeting report
Progress to date
Alan Kotok briefed the group on the status of the DRIve project and activities involving DRIve since the last meeting on the subject in June. The purpose of DRIve is to develop a prototype registry of e-business data objects based on the Electronic Business XML (ebXML) registry specifications. The ebXML specifications provide basic technical requirements for registries, as part of the overall ebXML technical architecture.
Since the June meeting, two DISA industry affiliates, Interactive Financial Exchange (IFX) and Open Travel Alliance (OTA), offered their completed schemas to DRIve for testing. Two DISA member vendors, XML Global and Sun Microsystems, also offered their ebXML-compliant registry software for use in DRIve.
Registry and repository requirements
Participants discussed the purposes of the project and the requirements for a DISA or X12 registry of standards objects. Peter Pruyne raised the question of the ability of an ebXML-compliant registry to support important collaborative functions needed by X12:
Examine work in progress
Distribute work in progress
Address parts of objects, such as data dictionaries, not only entire objects
These functions become even more important given the need for X12 to work faster and the increasing difficulty (and reluctance) for X12 members to travel to in-person meetings.
The ebXML registry allows for limited indicators of work in progress, but is generally designed for making completed schemas and related objects available for use by trading partners. While making finished work is also a need for X12, making work in progress available for review is a vital part of the standards development process. As a result, there needs to be a seamless connection between registration of work in progress and the finished product.
Leon Shiman said the Alexandria software his company produced for the Utilities Industry Group provided the collaborative and work-tracking functions Pruyne discussed, and he had earlier offered it for use in DRIve. Kotok said that ebXML-compliance was a mandatory requirement for DRIve, and thus Alexandria would first need to become compliant with ebXML for consideration.
The group discussed the ability of ebXML registries to store core component metadata. Participant noted that the Joint Core Components group in X12 has produced a document about registering core components.
Steps needed for registry development
Participants discussed the steps DRIve needed to take to get a registry started. The ebXML specifications provide a basic technical roadmap for building a registry. However, the specifications do not provide operational guidance, for example procedures for deciding on the acceptability of objects for registries. Also, ebXML wrote its specifications to be content-neutral, requiring registries to provide their own schemes for classifying objects.
The group also noted the need for a firm set of requirements against which the DRIve committee could evaluate the ebXML specifications and then the software offered by the vendors. The requirements step would lead to an evaluation of the requirements against the ebXML registry specifications. The evaluation would indicate where the specifications support the ebXML requirements and where they may be lacking. Where the ebXML specifications fall short of the requirements, the evaluation could indicate operational procedures that DRIve needs to fill the gaps. This evaluation step could provide useful guidance to the ebXML technical committee in OASIS continuing the work on registries.
Participants agreed that the collaborative and work-in-progress functions fit more into the responsibilities of X12’s Process Improvement Group (PIG), but the DRIve registry would need to work with any solutions adopted by PIG. However, the DRIve registry may need to support objects made available for public review, as well as finished work, a function that DISA’s vertical industry groups could use as well as X12.
Once the committee listed the requirements and gaps between requirements and specifications, it could then determine the operational steps and procedures needed by DRIve to perform its functions. With the operations identified, DRIve can then build applications for pilot testing, and make use of the offers from DISA’s vertical industry affiliates and vendors. With these offers, the pilot testing should not be too difficult to get started.
