[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [regrep] Implementing CCTS in Registry - further thoughts
Dave Welsh wrote: >Duane, > >yes I suspect you can even throw the kitchen sink in as an extrinsic >object if that's what you are getting at. Actually on Registry 'short >comings (which may be too strong a term cause the Registry teams done a >great job), Christina Portillo came out with a pretty powerful report on >all this and my basic take away was RegRep is "a bit too generic" and >could be a bit more focused like the UDDI guys have made with theirs. > Hi Dave, There are many misunderstandings about the nature of our generic API and information model. In fact we pointed out many such misunderstanding within the report you cite with Christina Portillo. Ironically, it is that very ultra-generic nature of the registry that enables it to be used by all kinds of verticals, business domains and applications. Ironically, the lack of genericity and extensibility in UDDI is limiting its usefulness and continued growth. I attribute our success to our generic and extensible design. And indeed when it comes to the breadth of user adoption, ebXML Registry is a success compared to any other registry standard. -- Regards, Farrukh >My >concern about the need for 1st class registry (retrieval) services comes >about not with the document level management but with the business >object management services which will need to be optimized - so let's >wait and see what the requirements are. > >-Dave > > > > >>-----Original Message----- >>From: Duane Nickull [mailto:duane@xmlglobal.com] >>Sent: Monday, February 17, 2003 12:21 PM >>To: Dave Welsh >>Cc: Farrukh Najmi; Fuger, Sally; Chiusano Joseph; David RR Webber - >> >> >XML > > >>ebusiness; OASIS Registry List >> >>Dave: >> >>The essential business artifacts and any other artifacts can all be >>referenced in a registry today. Furthermore, the registry allows for >>all relevant metadata to be placed in the existing RIM. >> >>No one has identified any shortcoming of the v2.0 registry where the >> >> >RIM > > >>fails to meet the needs of the artifacts. >> >>Furthermore, most of the artifacts from the CC and BP* teams, with >> >> >the > > >>sole exception of BPSS, have not been serialized into any electronic >>format that can be stored in a registry (or even a file folder for >> >> >that > > >>matter). >> >>Until this is done, asking the Registry team to make special >> >> >allowances > > >>for something that currently doesn't exist makes no sense to me. >> >>IMO, what I hear people suggest seems to be more related to >> >> >presentation > > >>of the artifacts themselves, which is not the responsibility of the >>registry team. >> >>Duane >> >>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> >>>> >>>> >>> >>>. >>> >>> >>> >>-- >>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