eBTWG FAQ

Below is a collection of questions either being asked directly or being voiced in public forums. The answers have been composed by the eBTWG executives. We hope that this FAQ helps in eliminating some of the confusion that seems to exist around the eBTWG.

If you have any additional questions, or seek more clarification, please send an email to knaujok@home.com. The eBTWG executives will gladly provide you with an answer.

Regards,

    Klaus-Dieter Naujok, eBTWG Chair
    Ralph Berwanger, eBTWG Vice Chair
    Pierre Georget, eBTWG Vice Chair
    Peter Wilson, eBTWG Secretariat


Where will the ebXML specifications reside?

Following the successful outcome of the Vienna ebXML meeting an agreement was reached to allocate the responsibilities for the further development of ebXML specifications between UN/CEFACT and OASIS. The participants have fulfilled their commitments to create the ebXML Framework and its specifications have been published. The question now is "What happens to all this work?"

There are business processes to be documented and core components to be defined. There are still enhancements required for the version 1 specifications, especially to the messaging and repository work in order to align/migrate with other efforts such as SOAP and UDDI. The ebXML work consisted of two blended efforts: a) technically define the XML-based, electronic business infrastructure and, b) develop a consist method for representing business processes. The other effort focused in the Business Process and Core Component project teams. The first required technology expertise, the second business expertise. The work accomplished by the ebXML group could not have been completed within the mandated time without participation by the OASIS experts. Nonetheless, the business components operating within the infrastructure must be defined and maintained by the business experts. Similar to the OASIS technology expertise,, the business experts are the key to business components. Logic demands that both organizations in their continuation of ebXML provide development and maintenance support to the ebXML specifications by ensuring that the correct domain experts, either representing technology, business disciplines, or both are part of the effort.

Who will maintain the ebXML specifications?

OASIS and UN/CEFACT agreed, following the procedures of their own organizations, to continue to advance the development, promotion, implementation and interests of ebXML by:

  • Jointly publishing the specifications, technical reports, and white papers which were approved and accepted at the Vienna meeting;
  • Allocating responsibility to each organization for parts of the project and its deliverables as defined below;
  • Encouraging and facilitating the participation of current ebXML experts in the project teams identified below;
  • Ensuring the effective coordination and marketing of ebXML and, in particular, striving to avoid duplication of effort between its various parts, by establishing a management committee;
  • Encouraging joint meetings of the UN/CEFACT - OASIS ebXML groups of experts;
  • Coordinating with other relevant international organizations and especially the World Wide Web consortium (W3C) to, where possible, align work programs and seek to minimize the risk of divergent and competitive approaches.

OASIS and UN/CEFACT agreed to the following division of responsibilities:

  • UN/CEFACT:
    • Business Processes
    • Core Components
  • OASIS:
    • Messaging (Transport, Routing and Packaging )
    • Registry and Repository
    • Collaboration - Protocol Profile and Agreement
    • Security
    • Conformance
  • UN/CEFACT and OASIS:
    • Technical Architecture
    • Marketing

How does UN/CEFACT plan to progress ebXML?

The UN/CEFACT Plenary endorsed the proposed strategy for achieving its e-Business vision at its March 2001 meeting. Subsequently, UN/CEFACT and OASIS announced the successful completion of the development stage of ebXML and its agreement for the allocation of responsibility for maintenance and further development of ebXML specifications.

Under the agreement UN/CEFACT will be responsible for Business Processes and Core Components. OASIS will be responsible for maintaining and advancing a series of technical specifications. Jointly UN/CEFACT and OASIS will be responsible for marketing and developing the technical architecture specifications.

In considering these factors as well as the responsibility for achieving the overall e-Business vision, the CSG believe the most effective way forward is to bring together the expertise and resources of the UN/EDIFACT Working Group (EWG), the Business Process Analysis Working Group (BPAWG), the Codes Working Group (CDWG), and the Business Process and Core Component work from the ebXML initiative. The result is the integration of this work into a new Working Group, the e-Business Working Group, that will be able to address the needs of all its users.

What is the role of the Coordinating Committee with regard to the ebXML Agreement between UN/CEFACT and OASIS?

The ebXML Coordinating Committee is responsible for:

  1. Ensuring effective coordination and striving to avoid duplication of effort between the UN/CEFACT Working Groups and the OASIS Technical Committees responsible for maintaining or developing ebXML projects;
  2. Encouraging effective technical linkages between these groups by facilitating, where appropriate, the appointment of liaisons to and from groups who have close technical relationships. UN/CEFACT and OASIS, under their respective procedures, shall ensure that such technical liaisons will be members of the group they are liasing with. The MC will maintain a registry of the liaisons;
  3. Initiating and developing relationships with other organizations so as to advance the interests of ebXML and the development of electronic business;
  4. Promoting and marketing ebXML;
  5. Progressing and resolving other issues that may arise in the maintenance, development, promotion, and implementation of ebXML.

How does the role of the Coordinating Committee with regard to the ebXML Agreement between UN/CEFACT and OASIS relate to other UN/CEFACT Working Groups?

Since the agreement between UN/CEFACT and OASIS only covers the maintenance and further development of ebXML specifications it only affects the projects that are in direct relation to it. Because those projects are part of the eBTWG's workplan no other UN/CEFACT Working Groups are affected.

Organization/ Administrative Structure

Why does the adhoc group need a Chair and two Vice-chairs?

The ebXML initiative has shown that there is an extensive volume of work to be done by a volunteer leadership. By having a leadership team three strong, the work can be split in a better manner. Further, the idea by the CSG was to have ebXML, EWG and ASC X12 members as significant international players in this environment, appointed by UN/CEFACT's leadership team to ensure that those three constituencies are well represented.

Why does the adhoc group need an Executive Committee, Steering Committee and Plenary?

Based on past experience, an activity which works virtually between meetings, as well as meeting 3 to 4 times a year, needs a team that supports the activities between meetings. A steering committee is too large to be effective intersessionally in addressing all operational and managerial issues. An Executive Committee allows issues to be addressed quickly intersessionally. (The same model has been applied to the EWG in terms of its current management structure and operating procedures.) In addition, the CSG feels that an Executive Committee, dealing only with non-technical, managerial issues, will free the project team leads from such items and allow them to concentrate on technical work.

Why does the CSG plan to appoint the Chair and Vice-chairs?

The CSG is doing its utmost to work at the speed required to meet international demands for global standards, yet at the same time slow enough to communicate and consult with the user community. This is a difficult balance to get right. Move too slow and we are criticized for missing opportunities that other organizations are willing to pick up. Move too fast and there is the accusation is that no one is consulted. It is felt that if CSG appointed three representative officers to work closer with the user community and ensure that work items are continued then this could be achieved in a better manner. The three officers are only for the adhoc group. Once the full ebWG is approved then there will be a full election process and the officers and their number is up to the ebWG election process.

Why does the adhoc Chair appoint a member of the group as secretariat?

This is common practice to all UN/CEFACT working groups, adhoc or permanent, when no UN/CEFACT secretariat resources are available. In the present instance, the UN/CEFACT secretariat has indicated that no additional resources are available to support this work.

Why does the adhoc group have a 3-level membership structure?

Over the last few years many UN/CEFACT delegations have asked for its working groups to include a virtual membership that does not require meeting participation. Members of the CSG have seen this membership category be highly effective in similar working environments. Realizing the importance of this initiative and listening to the desires of the UN/CEFACT delegations, the CSG proposed the use of a 3rd level of membership to the current member and observation levels.

What is meant by "UN/CEFACT's Open Development Process" and how will it work?

UN/CEFACT's open development process is designed to involve all materially interested parties in the creation and evolution of Technical Specifications. UN/CEFACT s goal is to produce specifications that are timely, technically excellent, implementable on any platform, and relevant both to industry participants and to end-user communities.

UN/CEFACT's open development process is not revolutionary. It is evolutionary because it builds upon specification development processes already used by industry consortia and standards developing organizations.

Perhaps the most unique feature of this process is the use of iterative refinement and web-wide participation to build international consensus. The premise is that people are usually much better at reviewing and criticizing a specification than they are at compiling a requirement list and writing a first working draft. UN/CEFACT's Working Groups delegate that important task to a small, dedicated editing group that works with recognized experts. That first working draft is then refined in three steps. First, working group experts and implementers review and comment on it. When this group reaches consensus, UN/CEFACT makes the second working draft available for public review at their web site, open to anyone. As comments are received, the editors update the working draft and republish it at UN/CEFACT s web site until broad consensus is achieved. The final step is to verify the working draft via at least two independent implementations that will identify any technical problems. Once the validation review is concluded, UN/CEFACT will publish the Technical Specification on their web site, open to anyone with access to the Internet. For more details see TRADE/CEFACT/2000/22 (UN/CEFACT's Open Development Process for Technical Specifications) and the User Guide to UN/CEFACT's Open Development Process for Technical Specifications. In keeping with the United Nation's mandate, the technical specifications should also be provided to those who do not have web access.

Work items/deliverables

Is the adhoc working group taking on EWG deliverables?

No. The deliverables of the adhoc group are those UN/CEFACT agreed to take on in order to continue the work on ebXML. However, those deliverables also reflect the requirements for new development from the EWG and as such should be completed in the most appropriate forum. No resources will be available to the EWG for new development, therefore, the adhoc group truly is the appropriate forum for this work. No ebXML deliverables were ever part of the approved work program of EWG.

What is the status of the ebXML Core Components Specification?

Not only was the work program of the ebXML CC team very aggressive, but it also addressed a technical area of complexity which many have tried before to resolve but failed. The end result being that instead of having produced ebXML specifications at the end of phase one, nine technical reports were produced. These reports form the foundation for the CC work under UN/CEFACT. The top priority is to advance the technical reports to specifications utilizing the UN/CEFACT Open Development Process.

What are the concepts behind the proposed core components specifications?

As mention above, the ebXML Core Components Specifications are not final. However, over the last eighteen months the following concepts have emerged. ebXML Business Collaboration Knowledge is captured in a Core Component Library. The CC Library contains data and process definitions, including relationships and cross-references, as expressed in business terminology that may be tied to an accepted industry classification scheme or taxonomy. The Core Component Library is the bridge between the specific business or industry language and the knowledge expressed by the models in a more generalized context neutral language. In those models both Business Information Objects and business documents are composed from Core Components, re-usable low-level data structures.

Are the key deliverables of the adhoc group in direct conflict with the work program of the EWG?

This point could be debated endlessly and still miss the most important issue. Everyone concerned - CSG, EWG, ebXML experts - wants to ensure that the work of UN/EDIFACT and ebXML come together under one forum. Ideally this would happen in one step, with the establishment of ebWG, but this is not possible because the time required to undertake a proper consultation process was underestimated. Therefore a two step approach has been suggested, with the recommended establishment of the adhoc group as the bridge. However, the end result, once consultation has taken place to ensure the best way of doing it, is still to have one group where both EWG and ebXML deliverables come together. In the relatively short intervening period (before the ebWG is established), it makes sense for the adhoc group to work on ebXML related deliverables and the EWG to work on UN/EDIFACT deliverables.

What about the work of the Joint Core Components team?

For the reasons given above it makes sense for UN/EDIFACT related deliverables to be continued by the EWG (until the ebWG is established) while the ebXML-related work takes place within the adhoc group. Invitations will go to all of the EWG experts calling for participation in the adhoc group work items (through meeting participation or virtual membership, or both). To bring all the ebXML related work, which includes the Core Component work, under a single roof is a powerful message to the broader community in that it demonstrates UN/CEFACT's immediate commitment to having a high and dedicated profile in this emerging domain.

There have been a few issues surrounding the labeling and the promotion of the work since it is not normally UN/CEFACT practice to elevate one member above others, but these issues are being resolved in a mutually beneficial way. As to the continuation of the core component work, since UN/CEFACT's ebXML work will be continued under the adhoc group and later eBWG, the CC work will have its home there. Participation within the group will be open to all those who have participated in the past, be it via the ebXML CC team or as a member of the JCC work, or who wish to participate in the future. We are encouraging both EWG and X12 members to join the eBTWG work in regard to core components since their experience is greatly needed. As to possible future interim meetings, we welcome either EWG or X12 to host interim meetings of the project teams that will be progressing the CC work under eBTWG.

How do the JCC and UBL efforts inter-relate with eBTWG, if at all?

The JCC work was very promising. It brought together two significant EDI communities - X12 and UN/EDIFACT - to work together on core component work. Fundamentally this helped to provide a convergent path towards ebXML solutions.

In regard to UBL, as termed by the CBL Organizational Committee, it is currently a private project. There was a request by the committee to have the work done under the UN/EDIFACT working group (EWG) as a sub group. However, the CSG response was that the work is part of the eBWG and therefore encouraged the committee members to attend the organizational session in Rotterdam. Since the CSG has delayed the creation of the eBWG, and instead formed the eBTWG, it is recommended that the committee members raise a eBTWG project proposal for their work and attend the first eBTWG meeting in.

Is there a relationship between JCC and UBL?. That question can only be answered after receiving project proposals from both sides of the efforts. There is talk that the UBL work could benefit from the JCC work. It should also be noted that the UBL work is supposed to be a short term solution bridging the time until the Core component and Business Process and Information Model work is concluded.