[Cache from http://www.disa.org/drive/DRIveMtg1.html; please use this canonical URL/source if possible.]


D.R.I.v.e
DISA Registry Initiative

Home  /  Calendar  /  Resources  /  Newsroom 

About DRIve

Join DRIve

DRIve FAQs

Contact DRIve


Data Interchange Standards Association



DISA Registry Initiative (DRIve) Meeting 1
4 June 2001 St. Louis, Missouri

Participants

Kendra Martin, DRIve Chair, American Petroleum Institute/Petroleum Industry Data Exchange
Jonathan Allen, individual member
Steve Bass, Washington Publishing Company
Gary Clark, Bank One
R.T. Crowley, Internet Commerce Corp.
Chris Driscoll, American Trucking Associations
Pam Flaten, Target Corp.
Tony Fugol, Safelite Glass Corp.
Todd Gould, Loren Data Corp.
Ken Hutcheson, DuPont
Ken Konikowski, EB2B Commerce Inc.
Darlene Lamason, Concurrent Technologies/Commonwealth of Pennsylvania
Robbi McClane, XML Solutions/Vitria
Dave Meiser, State Farm Insurance
Bob Miller, individual member
Gina Miller, Enterprise Rent A Car
Frank Napoli, LMI
Eric Novak, F.X. Coughlin
Sandra Paul, SKP Associates
Peter Pruyne, SysCom Strategies
DeeDee Ptasek, Sterling Commerce
Mike Rawlins, Rawlins EC Consulting
Leon Shiman, Shiman Associates
David Webber, XML Global
Roger Wisely, Chair, DISA Board of Directors
Donna Wright, GE Global Exchange
Sam Zamek, EDI Gateway
Jeff Zientek, Alltel/Harris Bank

DISA staff:
Tim Cochran
Jerry Connors
Alan Kotok
Teri Lepovitz
Guy Mayer
Yvonne Meding
Gaile Spadin

Introductions

Participants in the meeting introduced themselves and described their interest in the project and experience with ebXML or similar work related to the proposed registry.

DRIve objectives and purpose

Kendra Martin opened the meeting welcoming the participants and giving the purpose of the meeting, to describe the proposed registry to ASC X12, and request volunteers at this meeting and elsewhere to carry out the work. Participants received a draft discussion paper outlining the objectives and scope of the project, as well as a list of proposed milestones and recommendations for the membership and organization.

Alan Kotok gave an overview of the project's objectives and scope. The project will establish a registry for data objects of e-business organizations serviced by DISA, with ASC X12 being the largest of those organizations. The registry will meet the specifications of the ebXML initiative. EbXML defined two specifications for registry, one for registry services and the other for the information model for the objects listed in the registry. However, other ebXML specifications and technical reports are closely related to the registries and will need to be followed as well. DISA will coordinate DRIve with relevant organizations and committees, from OASIS and UN/CEFACT carrying on the work of ebXML. The discussion paper described the scope of DRIve in two ways: the functions performed by the registry and the objects registered.

David Webber outlined the ebXML architecture, focusing on the role of registries. Bob Miller raised the issue of the financial model for the registry, noting that the systems used in the registry will need to be paid for one way or the other. Martin noted that the cost of the registry and its financing are issues on the table for discussion.

Mike Rawlins asked if a vendor had been selected for the work. Kotok said that DISA would like multiple vendors involved with the project and is encouraging vendors to take part in it. Bob Crowley asked if X12 leadership has made a commitment to DRIve. Martin said that X12 had talked about a registry for its standards for some six years, so the issue is not a new one for X12. She reiterated that the ideas discussed at this meeting were still proposals, with the major decisions on the effort yet to be made.

Peter Pruyne noted that software for the registry should support multiple registries, and that any solution will need to support multiple approaches.

Several participants discussed cost and financial implications, noting that a previous Strategic Implementation Task Group (SITG) estimate for a registry had a high price tag. Rawlins cautioned that contributions from vendors may work for the development phase of the project, but once operational, the registry will likely require ongoing resources from DISA. Miller added that the registry idea is still quite new and DISA will not likely find packaged software that performs the registry functions. He suggested that any solutions be cooperatively developed and shared.

Chris Driscoll cited a DISA news release that talked about a repository as well as a registry. He said the release made it sound like DISA had already made a decision to go ahead with both the registry and repository. Kotok said the repository stores objects, while the registry provides the index and access to the objects. DISA has been working on making X12 and other DISA affiliate standards available electronically, which will require an electronic repository for their storage. DISA has made a commitment to develop this capability, but because there are few precedents for this service, DISA has not yet decided how to implement it.

Martin said X12 asked DISA to work on a solution for making its standard available electronically, to provide better offerings of publications than is available now. Tim Cochran added that Open Travel Alliance, a DISA affiliate, includes as part of its charter that its documents will be available freely and electronically.

Webber said work on ebXML registries has not stopped, and that the National Institute of Standards and Technology (NIST) is considering a proposal to fund the continuation of the work. He also urged that the discussion focus on the registry rather than the repository, since the registry is where the functionality resides. He added that if organizations see value in the functions of the registry they will want to contribute to it.

Mission and scope

Rawlins said at a high level he had no problems with the idea of a DISA registry, but he did have questions about the objects to be registered in it. Subsequent discussions focused on the registered objects, specifically schemas and company profiles. The ebXML specifications define collaboration protocol profiles (CPPs) that describe a company's technical capabilities to conduct e-business, including processes and messages supported. Several participants questioned whether a DISA registry should include CPPs or just the standards.

Jonathan Allen asked if the registry required XML, and if the registry could run under open source software, such as Linux or Apache. Kotok said the ebXML specifications required that registries support thin clients, i.e. web browsers, so at least for human-readable access, XML is not required.

Martin asked that anyone with comments on the mission and scope of the project should send them to DISA, c/o Alan Kotok (akotok@disa.org) by 15 June. [ACTION] She asked participants for comments on specific sections of the paper, which resulted in the following suggestions:

  • Include the development of a business plan or financial model, perhaps as a separate section, as one of the activities of the initiative
  • Define "registry" and "repository" ;indicate clearly if the scope covers a registry only, registry for a specific repository, or registry and a repository
  • List all other ebXML specifications and technical reports to which the registry refers, not only the two registry specifications
  • Change the wording referring to organizations managed by DISA, to organizations serviced by DISA
  • Specifically mention consideration of company profiles as part of the objectives
  • Note the distinction between development and operation of the registry
  • Change the wording of "create technology" to "deploy technology"

Other discussion concerned the projected volume of activity in the registry, whether it would have a constant, high volume of messages or occasional use. Webber said companies would use the registry as they get started using ebXML, but do not need to access the registry once regular message traffic is underway. Therefore, traffic would likely be occasional rather than constant.

Another question concerned the need to interoperate with non-ebXML registries. At this time the ebXML specifications cover only those compliant with the ebXML specifications, but other types of registries, such as those developed with UDDI, are likely to be numerous.

Comments on the scope part of the document included:

  • Add "subscribe" as a registry function, defined as notification of updates to the registry, when that function is covered in the ebXML specifications
  • Indicate more clearly that the registry needs to be able to send and receive ebXML-compliant messages.
  • ASC X12 standards in the database can be included, but questions of formats for the standards need to be resolved
  • Work on ebXML core components specifications is continuing and including them in the registry will depend on when that work is completed
  • DRIve participants need to make a decision on including company profiles (CPPs) as well as standards and specifications
  • The plan needs to indicate that the registry will not be confined solely to objects from DISA-affiliated organizations and that standards from other organizations could be included as well

Timetable and milestones

Participants recommended use of virtual meetings (e.g. conference calls) as much as possible, with in-person meetings scheduled in conjunction with other events.

The group discussed the six-month timetable for definition of the registry, with participants divided between those considering it too long and too short. Work on some of the ebXML specifications, core components in particular, is continuing and will affect the timing of the registry.

Other suggestions included:

  • Make the end date a more realistic 15 December rather than 31 December
  • Break the work into phases, with the first phase scheduled for completion in October, about the time of the next X12 meeting

Organization and membership

The group agreed with the idea of separate steering and working groups, with the steering group providing direction and oversight, and the working group performing the technical and business tasks. DISA should ask for volunteers for both groups, with a target date of 15 June for getting underway. [ACTION] The group made these additional suggestions:

  • The working group will consist of user and vendor representatives, but the chair should represent a user's company or organization.
  • DISA will establish list-serves for each group, although comments on the mission and scope statement should be gathered on a combined list. [ACTION]
  • DISA should post a sign-up list at the X12 meeting and announce its availability in a general session at the meeting [ACTION]

Action items

1. Anyone with comments on the mission and scope of the project should send them to DISA, c/o Alan Kotok (akotok@disa.org) by 15 June

2. DISA staff should ask for volunteers for both groups, with a target date of 15 June for getting underway.

3. DISA staff will establish list-serves for each group, although comments on the mission and scope statement should be gathered on a combined list

4. DISA staff should post a sign-up list at the X12 meeting and announce its availability in a general session at the meeting

[ Top ]

 

Return To Disa
Copyright Year 2001 DISA All Rights Reserved. This material may not be reproduced in any form without permission.