Re: Why isn't Core Components an ebXML Specification?

[Tim McGrath <tmcgrath@tedis.com.au>]

i am not sure it requires too much courage.  whilst i cannot speak for
the OASIS or UN/CEFACT or ebXML Exeuctive, as the Team Lead for ebXML
Quality Review(retired), I can explain what happend.

There are three categories of ebXML documents...

A "Technical Specification"has material that fulfils requirements of the
ebXML Requirements document.   It has been through at least two internal
(to ebXML) and external review and comment periods before approval by
the ebXML Plenary.

A "Technical Report" contains either guidelines (information to guide in
the interpretation or implementation of ebXML concepts) or catalogues
(foundation material based on ebXML Technical Specifications or Reports)
material.  A "Technical Report" has been through at least one internal
(to ebXML) and external review and comment period.  It  has also been
approved by the relevant ebXML project team and accepted by the ebXML
Plenary.

There is also a "White Paper" document that represents a snapshot of
on-going work within this Project Team.  This may not have had any
public review or comments but has been approved by the relevant ebXML
Project Team and accepted by the ebXML Steering Committee.

The decision on document categorisation for core components was based on
the fact that some of documents were obviously catalogues or
overiews/guidelines.  In addition, there were some documents where the
material had not yet been developed to a stage where it explicitly and
unambiguously addresses the ebXML Requirements in this area.  That is,
it is not at the stage of a "specification", that can be used to
implement ebXML conformant solutions.  In addition, most of this
material had only been through one round of internal and external review
and comment before the closing Plenary meeting.  Therefore,  the Quality
Review team recommended these documents also be categorised as
"technical reports".

So, in the main, there was a procedural difference, but it also reflects
the need for on-going work within the core components area.  A broader
interpretation of this would be, "we feel we are on the right track ,
but not there yet."

Had the ebXML team continued, then we would have expected this material
would have matured into ebXML "technical  specifications".  This work
will still happen, but under the stewardship of UN/CEFACT.

There, i said it!  and i am not at all embarassed.

PS.
I am glad to see you are assisting with this on-going work.

Todd Boyle wrote:

> Why are the Core Components technologies called "Reports"?
> There is not a single piece of the entire Core Components
> work products listed in the "Specifications".
> http://www.ebxml.org/specs/index.htm
>
> The press release is:
> http://www.ebxml.org/news/pr_20010514.htm
>
> Was this a problem of incompleteness and quality, or did the
> governing executives OASIS and UN/CEFACT see a systematic problem
> or flaw in the whole approach?
>
> Is there a better, competing technology?
>
> Was the competing school of thought based on emerging technologies,
> or based on backward compatibility issues?   What are the key
> factors that prevented any consensus to approve Core Components
> as a specification ?  Language or national differences?  Were
> dependencies on particular software vendors discovered in the spec?
>
> The answers to these questions are important to future work
> and the architecture decisions of many organizations outside
> of ebXML.  Many of us will appreciate it if executives of ebXML
> or its governing OASIS or UN/CEFACT will have the courage to
> address these issues in writing -- or -- have they already
> done that, someplace?
>
> Todd
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org

--
regards
tim mcgrath
TEDIS   fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142