Re: [regrep] Implementing CCTS in Registry - further thoughts

[Duane Nickull <duane@xmlglobal.com>]

Agreed.  I have a high degree of trust for Matt to come up with some 
insights.

Duane

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. 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/
>>
> 
> 
> 
> .
> 


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