OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: CSG Answers to Mark Crawford's Questions regarding the UN/CEFACT Position Statement on ebXML

Title: RE: CSG Answers to Mark Crawford's Questions regarding the UN/CEFACT Position Statement on ebXML

Thanks Klaus, these precisions are very helpful. However, if we take a concrete case, like the one that happened in BPSS in the first half of 2003.

The case is easy to understand, this is why I am replaying it here (keep me honest if there are some inncuracies):
UMM r12 has been published in the fall of 2002. Some people felt that BPSS needed to be immediately aligned with ebXML BPSS, since it was one of the design constraint for BPSS since its inception. So BPSS 1.01 was a subset of UMM r10 but BPSS 1.1 would not have been a subset of BPSS r12. Kind of a classic problem in software engineering. I think in Microsoft technology lingo this is often refered as DLL hell.

The editorial BPSS team had identified that the alignment with UMM r12 was possible (I had myself wrote a paper going into this direction in the summer of 2002) but it would break the existing ebXML 2.0 architecture or would have required a significant rework of the architecture for CPP/A and maybe even with implications in RegRep.

What are the mechanisms in place, if the JCC does not exist anymore and UN/CEFACT and OASIS do not talk to each other, to resolve this kind of issue? What committee will decide what is possible to do? UN/CEFACT, OASIS?

What about other specs that are intended to be linked to the BCF framework? Does UN/CEFACT imposes the same constraints on BPEL, WS-I or even maybe WS-CHOR?

Could you explain us in concrete terms what would you, the TMG or UN/CEFACT have done in this instance? Break the ebXML archtitecture or break the UMM / BPSS constraint?

Thanks in advance for your response,

truly yours,

tel: 425-649-6584
Cell: 508-333-7634

-----Original Message-----
From: Klaus-Dieter Naujok [mailto:knaujok@attglobal.net]
Sent: Friday, October 24, 2003 7:59 AM
To: uncefact-tmg-general@listman.disa.org; ebxml-dev@lists.ebxml.org; cefact-atg@list.unicc.org; cefact-tbg@list.unicc.org

Subject: CSG Answers to Mark Crawford's Questions regarding the UN/CEFACT Position Statement on ebXML

Please find below the answers to Mark Crawford's questions regarding
the "UN/CEFACT Position Statement on ebXML". These answers were
developed by the CSG and FCT members present at this week's meeting in
McLean. CSG members did meet with Mark to get some further
clarification regarding a number of his questions before developing its

To avoid the same confusion that surfaced during the last posting, let
me clarify that I am the "messenger" providing these answers to the
lists, I am NOT the "author". Yes, I am a CSG and FCT member, but have
step back as much as possible in the process of developing these

Since Mark has cross posted his questions to a number of list, I
apologize to those who will receive multiple copies of this response in




> 1) What exactly does "UN/CEFACT recognizes that ebXML is a very
> important technology solution which it will continue to actively
> maintain and support" mean?
Please see the additional clarifications provided below which should
eliminate any confusion regarding UN/CEFACT's continuing support of
business content for ebXML and other future technologies.  UN/CEFACT
has made a considerable investment in ebXML and will continue to
support it in a manner equivalent  to that afforded to UN/EDIFACT.

> 2) Is UN/CEFACT now prepared to implement the requirements for
> long-term management of ebXML as defined in the ebXML Requirements
> Technical Specification?

All of the specifications were intended to stand-alone. During the
development period, management under a single joint entity was
appropriate.  Now that development is completed, each organization will
manage the specifications for which they have responsibility.

> 3) Is UN/CEFACT now prepared to reestablish the JCC with OASIS?

No, the relationship successfully concluded.

> 4) Will UN/CEFACT reverse its recent actions of removing ebXML
> branding  from what are rightfully ebXML specifications as agreed to
> in Vienna  and in keeping with the belief that they were furthering
> ebXML  specifications by those individuals who worked on them?

No branding changes have been made to any specifications agreed to in
Vienna; in particular, BPSS version 1.1 released October 18, 2003, is
clearly branded ebXML.  The current UN/CEFACT Core Components Technical
Specification version 2.0 document title has a recommendation under
review to add a subtitle "Part 8 of the ebXML Framework".

> 5) Will UN/CEFACT firmly commit to continuing to progress these ebXML
> specifications in full partnership with OASIS to ensure that the ebXML
> framework remains intact?

During the last JCC conference call (which was after the announcement
in August) it was mutually agreed that OASIS and UN/CEFACT would
continue to separately maintain their respective areas of

> 6) Will UN/CEFACT commit to publishing its ebXML core components,
> business information entities, and defined business processes in an
> ebXML compliant registry as part of the developing ebXML framework?  
> (please note this does not in any way limit the ICG options - it only
> states than any registry ICG decides on will support the ebXML
> registry specifications in addition to any other specifications they 
> decide on) please also note that ebXML core components are syntax 
> neutral and as such the premise put forth that the ebXML branding 
> implies some syntax is misleading)

UN/CEFACT is committed to storing and publishing its work (including
core components library) in its own registry for standards development
and review.  In accordance with the CCTS version 2.0, ebXML compliant
registries should link to the UN/CEFACT Core Component Library, which
will be stored in a UN/CEFACT repository.

> 7) Will UN/CEFACT commit to acting as a harmonization and approval
> mechanism for ebXML core components from other interested standards
> organizations?

UN/CEFACT is committed to harmonize any candidate CCTS version 2.0
compliant core components submitted by any external organization that
has agreed to work under its policies and submission processes.

> 8)  Will UN/CEFACT commit to working with OASIS to establish the joint
> ebXML architecture team that was promised in Vienna?

In Vienna each group agreed to have its own architecture efforts and
agreed to liaise with each other.

> 9) Will UN/CEFACT put in place procedures that will guarantee that
> individuals cannot, under any circumstances, unilaterally change work
> products submitted by working groups?

UN/CEFACT is already governed by its Open Development Process (ODP) and
UN publication rules that preclude such changes.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]