Re: [regrep] "ebXML Registry and Web services" Federal Pilot

["Chiusano Joseph" <chiusano_joseph@bah.com>]

<Quote>
I would still like to see the set of requirements for this PoC.  Does 
anyone have them? 
</Quote>

There are no such requirements yet - which is wonderful, as we have a
clean slate to start with. I am not certain of the process for creating
requirements (if there is one) - this would need to be discussed with
the chair of the Federal CIO Council XML Working Group. 

I would recommend that we continue to build on Duane's excellent list
below, and - now that I see a high level of interest - I will suggest
this to the chair of the Federal CIO Council XML Working Group within
the next few days. This will allow us to continue discussing
requirements, so that I can convey those to him as well in order to give
him a better idea of scope.

Other requirements?

Joe

Duane Nickull wrote:
> 
> Farrukh Najmi wrote:
> 
> >> I would argue against using the ebXMLrr for a few reasons ....
> >
> >
> > I make it a point to never place ebxmlrr in a competitive posture with
> > any commercial ebXML Vendor and I definitely do not bad-mouth any
> > commercial offering. Your speaking negatively on ebxmlrr would not be
> > productive for our common goals. I will not bother defending against
> > your assertions.
> >>>>>>>>>>>
> Farrukh:
> 
> I was not out to bad mouth the open source ebxmlrr.  In fact, some at my
> company have even contributed to it and we will likely do so in the
> future ;-)
> 
> The bothersome comment was to lock out vendors without considering them
> on purely technical merits aligned with the end users requirements.  I
> believe this group (and all other groups) must function clearly out of a
> philosophy to match a solution with a set of requirements, regardless of
> political motives.
> 
> I would still like to see the set of requirements for this PoC.  Does
> anyone have them? Can we discuss how two or more registries can work
> together?
> 
> I would like to see the following:
> 
> 1. Registry "A" has several intrinsic objects
> 2. Registry "B" points at Registry "A"'s intrinsic objects as extrinsic
> objects.
> 3. Registry "C" points at both objects but recognizes that Registry "A"
> is the true source of the intrinsic objects.
> 4. A registry user can query for a Registry object in registry B or C
> but when they wish to get a copy ofthe registry object, the "get" clause
> grabs it from its' home registry ("A").
> 5. Registry B and C know that they must renew their metadata from
> Registry "A" at either (choice):
> 
>        - a certain pre-determined time
>        - when they receive a notification from registry A that the
> object has new metadata association with it.
> 
> 6. an object in Registry "A" is associated to an object in Registry "B"
> by a "users" association.
> 7. A classification scheme from registry C branches to the top level
> node of Registry B or A and can be replicated dynamically.
> 
> ....
> 
> comments?
> 
> Duane
> 
> >
> 
> --
> Yellow Dragon Software Corp. - http://www.yellowdragonsoft.com
> Service Oriented Architectures - ebXML, Web Services, Registry, SOAP
> Project Team lead - United Nations CEFACT eBusiness Architecture
> +1 (604) 738-1051
> ***********************************
begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard