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] Implementing CCTS in Registry - further thoughts


However, this will not be the sole agenda item.  We have a number of things to cover.  This will be on the agenda, and I will be sure to leave plenty of time for discussion.  Please send additional suggestions for the agenda as well.  I will prioritize so that we have adequate time to cover the critical items.

Thanks.

-----Original Message-----
From: Duane Nickull [mailto:duane@xmlglobal.com]
Sent: Monday, February 17, 2003 11:58 AM
To: Farrukh Najmi
Cc: Fuger, Sally; Chiusano Joseph; David RR Webber - XML ebusiness;
OASIS Registry List
Subject: Re: [regrep] Implementing CCTS in Registry - further thoughts


+1

Farrukh Najmi wrote:

> Your suggestion has definitely crossed my mind. I have asked myself: 
> "maybe CCTS, BPSS, CPP/A are special and maybe we should give them first 
> class status?"
> 
> After careful analysis I feel that it would be a mistake to give them 
> first class status no matter how "integral" a part of ebXML they are. We 
> still must not have a tight coupling to them in ebXML Registry. Here are 
> some reasons why not:
> 
> -It is not necessary. No use case has been articulated that cannot be 
> met without having a binding to the generic ebXML Registry as it is today.
> 
> -It violates ebXML Architecture's goal of avoiding tight dependency 
> between ebXMl specs (Duane can remind us of the exact verbiage I am sure)
> 
> -It is not a good design. A good design keeps layers one spec on another 
> and avoids a circular dependency. CCTS should depend on ebXML Registry 
> (which is a foundational spec) but not the other way around.
> 
> -It tells others non-ebXML specs (e.g. HL7, OGC, OAG, etc.) to "do as we 
> say, not as we do". That would not only be be hypocritical it would 
> create complexity due to special case handling resulting in creating two 
> ways of doing the same thing.
> 
> I feel that this issue cuts to the very essence of the core philosophy 
> of our ebXML Registry specifications (extensible, generic, 
> content-neutral architecture) and urge that we reach a common 
> understanding on this issue soon. To that end I propose that we make 
> this the main/sole agenda item for our next TC meeting.
> 


-- 
VP Strategic Relations,
Technologies Evangelist
XML Global Technologies
****************************
ebXML software downloads - http://www.xmlglobal.com/prod/


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>


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


Powered by eList eXpress LLC