[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [regrep] Implementing CCTS in Registry - further thoughts
-1 I can imagine that not making the essential business artifacts 1st class might sound technically nice but we are trying to enable business. I think there will be a set of business focused use case 'asks' for specialized business services we'd hope the Registry will provide; to make the business experience even more effective. Therefore, in the interest of the business community, I'd like to suggest waiting for the CC and BP teams input before passing any judgment. Dave > -----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 > > +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