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


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

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

Subject: RE: [regrep] Analysis for April 2002 Oasis ebRS and ebRIM V2 Vote

Title: RE: [regrep] Analysis for April 2002 Oasis ebRS and ebRIM V2 Vote
Hi Joe,
Thanks for reviewing my analysis.  I appreciate the good work by your sub-committee.  Your initial analysis as documented in your recent posts indicate that there may be changes to the ebRS and ebRIM specifications to provide support for CC requirements.  I believe that we should hold off on trying to establish/promote the current V2 ebRS and ebRIM specifications as "Oasis Standards" until we have made the other corrections that I have highlighted with my analysis and possibly incorporated your team's CC-based changes.
-----Original Message-----
From: CHIUSANO, Joseph [mailto:JCHIUSANO@lmi.org]
Sent: Thursday, April 25, 2002 3:08 PM
To: 'Munter, Joel D'; 'Oasis Registry TC'
Subject: RE: [regrep] Analysis for April 2002 Oasis ebRS and ebRIM V2 Vote


I believe I can help to clarify some of the references you've made regarding Core Components, in particular p.6, section "ebXML Core Components (ebCC)".  As you know, our CC Review Subcommittee has been analyzing and discussing the CC Spec since January.  The mission of this Subcommittee is fourfold:

(1) Understand the expectations and requirements for ebXML Registry functionality defined in the Core Components Technical Specification;

(2) Where appropriate propose changes and additions to the ebXML Registry V3 specifications to meet the expectations and requirements defined in the Core Components Technical Specification;

(3) Help ensure that the Registry TC efforts are aligned with CC-related ebXML committee by serving liaison roles;
(4)Serve as a resource to the Registry TC in understanding the CC model and processes.

We have made and are continuing to make great progress in our analysis, and will have concrete information for the TC in the future regarding how the Registry architecture can accomodate Core Components.

Stay tuned - and if you have any questions on our efforts I would be happy to give you more details.


> **************************************************************************
>   Joseph M. Chiusano
>   Logistics Management Institute
>   2000 Corporate Ridge
>   McLean, VA 22102
>   Email: jchiusano@lmi.org
>   Tel: 571.633.7722
> **************************************************************************

-----Original Message-----
From: Munter, Joel D [mailto:joel.d.munter@intel.com]
Sent: Thursday, April 25, 2002 1:38 PM
To: 'Oasis Registry TC'
Subject: [regrep] Analysis for April 2002 Oasis ebRS and ebRIM V2 Vote

Analysis for April 2002 Oasis ebRS and ebRIM V2 Vote

I offer the attached document which summarizes my analysis of the Oasis
ebXML Registry TC V2 Specifications.  While I welcome your comments, I ask
that you read my complete arguments before you reply.  These statements
represent the position of Joel Munter.

The problems identified and discussed during the 90-day review period and
this subsequent 30-day vote period have not yet been fixed.  The current
Oasis process does not allow the Oasis ebXML Registry TC to create the
required Errata in parallel with an ongoing specification review and
approval.  To vote "Yes" for these to become an established Oasis Standard
is not prudent.  The complete fixes for all of the issues identified have
not yet been completely documented and approved by the TC.  Some of the
issues cited relate to normative behaviour that cannot be implemented
without the required correction.

Intel believes that the results of the Oasis Standards Process should be a
specification or in this case a pair of specifications should be of
extraordinary quality.  The specifications should be nearly flawless.  These
specifications contain too many issues.  I strongly recommend waiting until
the identified fixes have been completely documented, incorporated within
next revisions of the specifications, and they have been approved by the TC
before reconsidering them to be cast as Oasis Standards.

The specifications should be complemented with real implementations based
against V2 of the specifications.  While there were emails sent early in Dec
2001 discussing V2 implementations, it is obvious at the bottom of the page
at https://www.oasis-open.org/committees/regrep/ that almost 5 months later
there still are not a sufficient number of V2 based implementations.

To vote "Yes" based on the issues listed herein and the complete list of
issues documented at
ry-v2-spec-IssuesList.xls is simply wrong and would do an injustice to the
Oasis Standard approval process.

Joel Munter
Distributed Systems, Intel Labs
(480) 552-3076
(602) 790-0924 (cell)

 <<Oasis ebXML RR Spec Review (jdm).pdf>>

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

Powered by eList eXpress LLC