Re: [ubl-comment] Re: UBL and UN/CEFACT

["Michael C. Rawlins" <mike@rawlinsecconsulting.com>]

Ralph, Jamie, Klaus-Dieter, Ray, Jon, and other interested parties:

I would like to offer my 2 cents worth on this, since for the time being I 
am an uninvolved bystander.  I have been no more than an observer and 
occasional commenter on the UBL work for most of this year.  My OASIS 
membership has lapsed (though I will probably renew soon).  I have no 
affiliation with CEFACT.  So, what concerns me is what will be the best for 
the user community.  I think the things that matter in that area are a 
single standard for XML business documents, having it soon (if not 
yesterday), and having it be good.  These goals may be somewhat in conflict 
with each other, but if you don't ask for what you want you're for sure not 
going to get it.

In that light, it would be beneficial if CEFACT and the OASIS UBL TC could 
work together to develop a single, good standard.  That seems to me to be 
the optimal solution.  However, in the current climate I have concerns 
about that negatively impacting the "soon" requirement.  CEFACT is just 
spinning up a new organization.  Even a casual observer would expect that 
it will take them awhile to sort things out and hit their stride with their 
currently planned work program.  Brining a new effort like UBL under the 
umbrella could only slow things down.   From the other perspective, the UBL 
TC has been up and running (de facto, if not officially) for about a year 
now.  It has hit its stride.  It is half way through a planned work 
program.  A casual observer might find it hard to understand why they would 
want to undergo a disruptive organizational change this far through the 
effort.  In short, I see trying to work in the short term on a single 
standard as being in conflict with user community requirements for a 
standard soon.

That said, we don't have to give up on a single standard.  Let's look at 
reality.  CEFACT is planning on using Core Components as the basis for XML 
schemas.  The CC technical specification isn't approved yet.   Do we 
realistically think that CEFACT will have an approved Core Component 
dictionary in the next year?  By that time, if the UBL work goes as planned 
most of it should be finished.  This timing works quite nicely.   The bulk 
of the UBL work finishes up in OASIS, it gets transitioned to CEFACT, and 
then continues development in CEFACT and forms the basis for the CEFACT XML 
document standards.  That's not to say that the UBL work couldn't still 
have some official status in OASIS, but the primary venue should be 
CEFACT.  Even though I have several negative opinions and feelings about 
CEFACT, as a UN organization it still has the best credentials and mind 
share to be the host of a single, international standard.

Three major things are required to make this happen:

1)  CEFACT and the OASIS TC need to agree that this is a good plan and work 
toward it.  A Letter of Intent might be a very good message to send to the 
community.

2)  The OASIS TC needs to finish up its work program on time.

3)  CEFACT needs to defer work on XML syntax until the UBL work transitions 
over to CEFACT.  I expect that there will be people in CEFACT who will find 
this a bitter pill to swallow.  But, let me remind you.  You asked the rest 
of the world to stop work while you and OASIS worked on ebXML.  We did, and 
we still don't have much to show for it.  I think it's your turn to sit on 
your hands and get out of the way while someone else does something.

Now, tell me reasonably why this doesn't appeal to your common sense?

Cheers,

Mike

At 10:47 PM 9/8/02 -0700, Jon Bosak wrote:
>As chair of the OASIS UBL Technical Committee, I welcome the
>recent message from Ralph Berwanger, Jamie Clark, Klaus-Dieter
>Naujok, and Ray Walker expressing their interest in pursuing a
>closer relationship between UN/CEFACT and the UBL initiative.
>
>In this message I would like to briefly review the history of the
>UBL-UN/CEFACT relationship to this point, summarize the issues,
>and set forth what seem to me to be the viable alternatives going
>forward.
>
>First, however, a process issue.  The message to which I am
>responding was sent to five different mailing lists:
>
>    ubl-comment@lists.oasis-open.org
>    cefact-ewg@list.unicc.org
>    un-tmwg@gefeg.com
>    ebtwg@lists.ebtwg.org
>    ebxml-mgmt@lists.ebxml.org
>
>As far as I know, only one of these lists, ubl-comment, is
>publicly subscribable.  Since everyone in the world can subscribe
>to ubl-comment, and since cross-posting is in any case generally
>considered bad practice, I am going to send this reply only to the
>ubl-comment list and ask those copied on the previous message to
>forward this reply to the remaining lists along with a request to
>subscribe to ubl-comment if people are interested in pursuing the
>discussion.  The ubl-comment list can be subscribed to using the
>list manager at
>
>    http://lists.oasis-open.org/ob/adm.pl
>
>People who come into this discussion late will be able to catch up
>using the publicly visible ubl-comment archive.
>
>##################################################################
>HISTORY
>##################################################################
>
>The ebXML initiative ruled the development of a standard XML
>payload syntax out of scope early in the project (Brussels, May
>2000).  UBL arose from a desire on the part of some ebXML
>participants to supply what they saw as the piece needed to
>complete the ebXML framework envisioned in the specifications that
>were eventually released May 2001 in Vienna.
>
>The purpose of this group as it has evolved over the two and a
>half years since the ebXML meeting in Brussels can be summarized
>as the rapid development of a standard cross-industry payload
>syntax designed for use in ebXML and similar XML-based B2B
>frameworks and having the following characteristics:
>
>  - Builds on existing EDI practice and recent XML marketplace
>    experience while anticipating future directions in
>    web-service-based B2B technologies
>
>  - Captures the semantics of current EDI standards and industrial
>    XML vocabularies
>
>  - Incorporates the experience of the widest possible array of
>    business domain experts
>
>  - Reflects the lessons gained in two decades of SGML and XML
>    document design
>
>  - Utilizes the expressive power of XML schemas
>
>  - Employs a library-based data architecture that will enable the
>    application of ebXML context methodology in order to produce
>    document formats tuned for particular trading contexts
>
>  - Aligns with the ebXML Core Components effort for semantic
>    harmonization
>
>  - Aligns with the UNeDocs effort and existing fax- and
>    paper-based business processes in order to promote adoption by
>    small and medium-sized enterprises
>
>  - Is free from intellectual property claims
>
>  - Can serve as an international standard for the electronic
>    representation of business documents
>
>A pragmatic decision was made early in the UBL project to base the
>work on an existing XML library rather than starting from scratch.
>At the beginning of 2001, the xCBL specification was chosen as the
>basis for this work for the following reasons:
>
>  - xCBL 1.0 was developed in 1997 under a grant from the
>    U.S. government that put the work in the public domain
>
>  - xCBL 2.0 added significant functionality needed for use in
>    industrial ecommerce marketplaces
>
>  - xCBL 3.0 added EDI semantics, including an explicit mapping to
>    UN/EDIFACT and X12 EDI
>
>  - xCBL uses a library architecture that maximizes the reusability
>    of shared data structures and satisfies the UBL requirement for
>    the future application of ebXML context methodology
>
>  - xCBL is licensed under terms that allow the free creation of
>    derivative works without royalties or other fees
>
>  - xCBL has been widely deployed and represents four years of
>    practical experience in the use of XML for electronic commerce
>
>The decision to adopt xCBL as a starting point for UBL
>accomplished a number of practical objectives but also led many
>people to the mistaken assumption that UBL would resemble xCBL.
>After a year of UBL development, however, it is now quite clear
>that this is not the case; UBL is very much its own specification
>and is as independent of xCBL as it would have been if development
>had started from nothing.  The basic difference is that UBL is
>about four years further along in its development than it would
>have been if we had not started with an existing XML business
>library.  A recent review package containing the data model and
>XML schema for UBL Order and Order Response, together with a
>library of about 500 reusable data elements, is available for
>download, inspection, and public comment via the ubl-comment list;
>for details, see the announcement at
>
>    http://lists.oasis-open.org/archives/ubl-comment/200208/msg00028.html
>
>UBL was proposed as an OASIS Technical Committee in February 2001.
>A delay in the creation of the TC allowed the group to consider
>the possibility of forming in UN/CEFACT instead.  After a meeting
>in April 2001, I was authorized to propose the formation of UBL as
>an XML Syntax Subworking group within the EDIFACT Working Group of
>UN/CEFACT.  This proposal was submitted to the CEFACT Steering
>Group (CSG) in May 2001 but was rejected due to a planned
>restructuring of CEFACT that was considered at that point to be
>imminent.  Suspecting that the CEFACT reorganization might take
>some time to accomplish and eager to begin its work, the UBL
>organizing committee went ahead with plans to work in OASIS until
>the CEFACT reorganization was complete.  UBL was formally
>constituted as an OASIS Technical Committee in October 2001.
>
>With the meeting this week of the new CEFACT Forum, the
>reorganization of UN/CEFACT has reached a stage where the
>discussion of future coordination between UBL and UN/CEFACT is now
>felt to be productive.  In the meantime, however, UBL has
>attempted to fulfill the requirement for the widest possible range
>of business input by co-locating UBL meetings with meetings of the
>EDIFACT Working Group (March 2001) and ASC X12 (June 2001) and by
>establishing relationships with a number of industry data
>standards organizations through the appointment of liaisons to the
>UBL Liaison Subcommittee.  For details, see the LSC web page at
>
>    http://oasis-open.org/committees/ubl/lsc/
>
>The existence of these relationships with industry data standards
>organizations has added another dimension to the discussion of
>relations between UBL and UN/CEFACT.
>
>##################################################################
>UBL-UN/CEFACT ISSUES
>##################################################################
>
>Notwithstanding the decision to move ahead in OASIS during the
>UN/CEFACT reorganization, several discussions have taken place
>within UBL regarding the potential for UBL-UN/CEFACT
>collaboration.  The most recent of these discussions took place in
>the UBL Liaison Subcommittee during the June UBL meeting hosted by
>ASC X12.  The relevant portion of the minutes from that meeting
>(5 June 2002) reads as follows:
>
>/==================================================================
>|
>| Relationship with UN/CEFACT
>|
>|    The chair reported on the previous day's meeting with X12 COTG
>|    and the invitation extended by Ralph Berwanger to consider
>|    putting UBL into the new UN/CEFACT Forum.
>|
>|    A couple of general problems with the new CEFACT structure were
>|    noted:
>|
>|     - That domain working group procedures are being determined by
>|       people outside of the domain groups
>|
>|     - That there are no determinative criteria for establishing
>|       compliance with a UMM requirement
>|
>|    Particular problems with UBL functioning in CEFACT were noted:
>|
>|     - That the UMM process is not applicable to work that is
>|       attempting a synthesis of existing XML syntaxes
>|
>|     - That organizationally, UBL is a unique task group attempting
>|       to accomplish a specific project and would have to stay that
>|       way to work inside CEFACT
>|
>|     - That some groups within the new Forum have a mandate that
>|       overlaps ours
>|
>|    Conditions that would have to be established if we were to join
>|    CEFACT were noted:
>|
>|     - UBL would need to be its own group, not part of another
>|
>|     - The CCs and BIEs coming from the UBL work would have to be
>|       introduced into the CEFACT harmonization process and not
>|       vetoed or modified on methodological or non-technical
>|       grounds
>|
>|     - It would have to be recognized that the "open development
>|       process" is inappropriate to this project (we can't have
>|       non-participants trying to change the specifications)
>|
>|    It was noted that our default position (continue as an OASIS
>|    TC) has some advantages:
>|
>|     - That we can function to pull together the experts from X12
>|       and EDIFACT as well as a number of vertical industry data
>|       exchange organizations
>|
>|     - That the alternative in which CEFACT outsources this work to
>|       us continues to be attractive (though the UMM and
>|       development processes remain issues)
>|
>|     - That our current position makes us much more responsive to
>|       the needs of organizations like ACORD than if we were part
>|       of CEFACT
>|
>|    The LSC concluded that at this time we should try to become
>|    CEFACT's preferred provider of XML syntax and XML design rules
>|    while maintaining separate ownership and should urge that the
>|    UBL design rules should become the default for ebXML
>|    CC-compliant XML syntax development efforts.
>|
>\==================================================================
>
>The conclusion stated above remains the position of the UBL
>Liaison Subcommittee.
>
>##################################################################
>RESPONSE TO MESSAGE FROM BERWANGER, CLARK, NAUJOK, AND WALKER
>##################################################################
>
>I would now like to consider the message sent 6 September 2002 by
>Berwanger et al. and outline what seem to me to be the viable
>alternatives at this point.  It should be understood in what
>follows that I am expressing my own opinion and cannot formally go
>beyond the decisions previously made by the UBL TC and the UBL
>LSC.
>
>The message of 6 September states:
>
>| Experts and business user communities have expressed concern to us
>| about the duplication of resources between the OASIS UBL project
>| and UN/CEFACT's ebXML Core Components project.  Many implementers
>| are uncertain about whether the two projects are complementary or
>| divergent.  We have also received many inquiries about whether the
>| two projects can be combined.
>
>This passage seems to reflect a basic misunderstanding among
>implementers about the relationship between UBL and CC.
>
>UBL is not an attempt to standardize business semantics.  UBL is
>intended to provide the actual XML syntax for basic business
>documents in a form that can be used across industries as well as
>within industries, thus enabling the deployment of interoperable,
>off-the-shelf B2B systems simply by plugging UBL into the
>framework defined by the existing ebXML specifications.  To
>accomplish this objective, UBL intends to provide four
>deliverables:
>
>  - A set of naming and design rules for B2B XML schemas
>
>  - A library of reusable XML schema components (Business
>    Information Entities) that can be assembled into EDI-like XML
>    business documents
>
>  - A set of basic standard business document schemas constructed
>    from the BIEs in the UBL library
>
>  - A future contextualization technology that builds on the ebXML
>    context methodology effort to produce a standard extension
>    mechanism for the generation of context-specific document
>    schemas
>
>None of these deliverables overlaps the work of the ebXML Core
>Component activity.  The apparent overlap between the UBL and CC
>work is an artifact of the scheduling of the two efforts.  If
>there had been in existence a complete, standard CC library, then
>the task of UBL would have simply been to develop design rules for
>the production of XML versions of the CCs and to produce the
>corresponding XML schema library.  But this is not what we were
>given to work with.  The fact of the matter is that today, after a
>year of UBL work, there is not in existence a single standard
>ebXML core component, let alone a comprehensive standard library
>of core components.  In fact, there is not even a final
>specification for the definition of ebXML core components.
>
>By adopting a pragmatic strategy, UBL stands today at the end of
>five years of XML business library development.  If we had waited
>for the standardization of ebXML CC, we would not even have
>started yet.  As a result of our efforts, ebXML as a practical
>reality is five years closer to realization.  So I view UBL as a
>very positive contribution to ebXML.
>
>An additional contribution lies in our intention to submit all the
>UBL BIEs to the CC effort.  UBL has been committed to this goal
>for its entire existence as an OASIS TC.  It's no coincidence that
>the vice chair of the UBL TC is the editor of the CC
>specification.  UBL inherits from xCBL a huge collection of
>business semantics from EDI and commercial marketplace
>initiatives.  The donation of the UBL candidate CCs to the CC
>library will make UBL one of the largest contributors to the CC
>effort.
>
>To sum up: UBL comprehends far more than the definition of
>business semantics, and it is in no way intended as competition to
>the ebXML CC work.
>
>The relevance of this point lies in this further passage from the
>message of 6 September:
>
>| The CC team and its work currently reside in UN/CEFACT's TMG group
>| (along with the UMM and most other UN/CEFACT ebXML projects).
>| There may be other equally appropriate solutions.
>
>A consequence of the considerations just outlined is that UBL does
>not belong in the Techniques and Methodologies Group (TMG).  UBL
>does have a Tools and Techniques Subcommittee that would seem to
>align with the TMG, but it constitutes just a small part of the
>overall UBL effort.
>
>Since UBL is primarily concerned with syntax definition, the bulk
>of its work maps best to the new Applied Technologies Group (ATG),
>but there is also apparent overlap with the new International
>Trade and Business Processes Group (TBG) and the new Information
>Content Management Group (ICG).
>
>UBL has made tremendous progress over the first year of its
>existence partly because it unifies the various aspects of the
>development of an XML business syntax definition in a single
>technical committee.  Indeed, one of the conclusions we're coming
>to in the UBL effort is that we need more joint work among the UBL
>subcommittees dealing with these various aspects, not less of it.
>So one of the biggest hurdles we would face in making the
>transition to UN/CEFACT would be preserving this unity in the face
>of the far more distributed structure of the new CEFACT
>organization.
>
>##################################################################
>POSSIBLE OPTIONS
>##################################################################
>
>No one seems to deny that there should be a close relationship
>between UBL and UN/CEFACT.  The question is how best to accomplish
>this without slowing down the UBL work.  Here are what seem to me
>to be the most workable options.
>
>OPTION 1: FORM UBL WORKING GROUP IN UN/CEFACT ATG
>
>    Since the ATG is chartered with the definition of specific
>    business syntaxes, it would make sense to form EDIFACT,
>    UNeDocs, and UBL working groups within the ATG for the
>    definition of EDI, paper-based, and XML syntaxes, respectively.
>    I seem to remember that something very much like this was
>    proposed during the discussions some months ago that led to the
>    new CEFACT structure.
>
>    Personally, I find the surface simplicity of this option
>    appealing, but substantial changes would have to be made to the
>    CEFACT terms of reference to overcome the issues listed above
>    by the UBL Liaison Subcommittee and to allow UBL to maintain
>    its unified approach and accomplish its objectives on time.  It
>    seems to me that the changes to the terms of reference required
>    to ensure the integrity of the current work would require
>    formal approval by the CEFACT Plenary.  If that's the case,
>    then realistically we wouldn't have formal approval for this
>    before next spring and wouldn't actually meet under the new
>    organization until the following September.
>
>    This delay might not be as bad as it sounds.  For one thing, I
>    suspect that a transfer of authority a year out from now would
>    actually fit the probable UBL work schedule fairly well.  And
>    if UN/CEFACT and the UBL TC could agree on this as a stated
>    direction, we could announce it far in advance of its actual
>    instantiation.  Such an announcement would go a long way toward
>    rectifying the perception that UBL and UN/CEFACT are working at
>    cross purposes.
>
>OPTION 2: IMPLEMENT UBL AS A WORKING GROUP OF ISO TC 154
>
>    An option that's received very little public discussion is that
>    of implementing UBL as a working group of the ISO body where
>    the formal standardization of EDIFACT syntax takes place.
>
>    In terms of pure standards theory, putting UBL in the ISO TC
>    responsible for the international standardization of electronic
>    business syntaxes makes a lot of sense.  In conversations with
>    various people, however, I've not found much enthusiasm for
>    this idea.
>
>    For one thing, TC 154 seems to function very well as a
>    clearinghouse and a place to formalize technical work done in
>    other groups, providing an established, highly regarded process
>    for international standardization that doesn't really need to
>    have a different kind of project added to it.  Another factor
>    making this idea less attractive is that UBL already has a
>    clear path to eventual ISO standardization through OASIS's
>    Class A Liason status with TC 154, so we would be achieving
>    little practical gain at the price of a fair amount of
>    procedural churning needed to get UBL added to the TC 154
>    schedule of work.  But this alternative may turn out to have
>    real merit if it's the only way to get the active cooperation
>    of UN/CEFACT work groups without running afoul of the UN/CEFACT
>    terms of reference.
>
>OPTION 3: CONTINUE IN OASIS WITH LIAISONS TO TBG
>
>    The easiest option would be to keep UBL in OASIS and add TBG
>    domain groups to the UBL Liaison Subcommittee to provide a
>    conduit for UN/EDIFACT domain expertise into the UBL work.  The
>    EDIFACT Working Group is already represented in the UBL LSC,
>    but adding separate liaisons from the various domain groups
>    would help to promote the flow of domain-specific input into
>    the UBL schemas and would allow us to set up somewhat different
>    relationships with the various domain groups depending on the
>    state of the work.
>
>    A couple of examples will help to illustrate this.  Consider
>    EWG D2 (Purchasing), which is becoming TBG2 in the new
>    UN/CEFACT structure.  UBL has already published schemas for
>    Order and Order Response (see reference above), so a liaison
>    with TBG2 would serve primarily in review mode, organizing the
>    detailed response of the purchasing experts in TBG2 to the work
>    already accomplished.  The situation might be different with
>    EWG D4 (Transport), which is becoming TBG3.  UBL has not yet
>    addressed transport documents at all, so the role of TBG3 in
>    this relationship might be to actually assemble the XML schemas
>    for transport documents using BIEs from the UBL library in
>    accordance with the UBL naming and design rules.  In either
>    case, modifications and additions discovered in the course of
>    domain group analysis would be fed back into the UBL library
>    and then conveyed from there into the ebXML CC library.
>
>    While apparently less integrated than a solution that put UBL
>    into UN/CEFACT, this arrangement would actually have the
>    considerable logistical advantage of allowing the UBL team and
>    the UN/CEFACT domain teams to operate in parallel on different
>    meeting schedules.  This means that participants in the domain
>    groups could concentrate completely on getting the business
>    requirements right, while participants in the UBL work could
>    concentrate completely on the XML realization of those
>    requirements.
>
>    I believe that this alternative would function quite well while
>    avoiding any disruption of the UBL work.  Its only real
>    disadvantage as things stand right now is that UBL would still
>    lack the impramatur of UN/CEFACT.  If UBL were designated the
>    "preferred provider" of XML syntax to CEFACT as proposed by the
>    UBL LSC, however, this objection could be largely overcome.
>
>There are surely other possible options to be considered here that
>haven't occurred to me; I leave it to others in this discussion to
>point them out.
>
>Jon Bosak
>Chair, OASIS UBL TC
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>

---------------------------------------------------------------
Michael C. Rawlins, Rawlins EC Consulting
www.rawlinsecconsulting.com