Next in thread → Next in month →

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

From
Munter, Joel D <>
Date
2002-04-26T15:22:24+00:00
ID
Thread
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.

Joel

 

-----Original Message-----
From: CHIUSANO, Joseph 
[mailto:]
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

Joel, 

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. 

Regards, 
Joe 

> 
************************************************************************** 

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

> 

-----Original Message----- 
From: Munter, 
Joel D [mailto:] 

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 
https://www.oasis-open.org/committees/regrep/documents/2.0/specs/ebXMLRegist 

ry-v2-spec-IssuesList.xls is simply wrong and would do an 
injustice to the 
Oasis Standard approval process. 

Thanks, 
Joel Munter 
Distributed Systems, Intel Labs 
 
(480) 552-3076 

(602) 790-0924 (cell) 

 <<Oasis ebXML RR Spec Review (jdm).pdf>>
Next in thread → Next in month →