[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [regrep] Implementing CCTS in Registry - further thoughts
Dave, Thanks for your input. I think we should clarify as to what we mean by "first-class", so you can see if you still feel the same way (apologies in advance if you already know this!). By "first-class" we simply mean having Intrinsic (pre-defined) object types within the Registry to represent Core Components and their associated entities - in the same way that we have pre-defined object types for Service, Classification, Association, etc. If Core Components were to not be first-class, it would mean that they would be represented using Extrinsic objects - much like CPA and CPP are represented. One difference for implementations would mean that queries would be different - as shown in the 2 SQL commands I provided last week (second one used Slots). - Joe Dave Welsh wrote: > > -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>
Attachment:
Chiusano_Joseph.vcf
Description: Card for Joseph Chiusano
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC