|
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.
Deliverables and timetable
The group agreed on the following steps for development of DRIve:
-
Requirements: determine the functions and capabilities needed by a registry
of DISA standards objects. Mike Rawlins agreed to chair the requirements
team, with participation by Lisa Shreve and Peter Pruyne.
-
Evaluation: match the DRIve requirements against the ebXML registry specifications,
noting the differences between the requirements and specifications. DRIve
would share this report with the OASIS ebXML registry technical committee.
-
Operations: determine business processes and procedures for DRIve to become
a functioning registry. Those processes should include access by thin clients,
such as Web browsers. Leon Shiman agreed to chair the operations team.
-
Pilot tests: using the offers from vendors and DISA affiliates, build a
functioning registry. The pilot tests may indicate even more holes that
the registry operations need to fill. David Paraiso agreed to chair the
pilot test team.
Alan Kotok will provide support from DISA to all teams.
The requirements team will aim for the end of October for submission
of its document. The committee will determine the delivery dates for the
remaining steps based on the requirements. However, the group agreed to
aim for the pilot tests to be operational in January 2002, in time for
the next X12/XML Summit meeting.
[ Top ] | 
