OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-poc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: Proposal: A Registry Browser GUI tool



I might have missed something but
are we still planning to have
an automated TPP merge capability
in the registry (if all that is
needed is just to adjust
the partner-- oops, party-- identities.)

I still am not certain how the merge
or TPA formation was to work within the registry.

Farrukh, do you think that is a reasonable
thing to complete for this POC or maybe
that it will take a little more time?

Also, I am not clear on how all these
proposals for functionality for the POC
get merged. Does someone like say
Nick ;-) supply that service? Do 
we have to thrash around reviewing
each one and then reach a consensus (yikes).


Dale Moberg




> -----Original Message-----
> From: Farrukh Najmi [mailto:Farrukh.Najmi@east.sun.com]
> Sent: Wednesday, September 13, 2000 10:05 AM
> To: ebXML poc
> Cc: Krishna Sankar
> Subject: Proposal: A Registry Browser GUI tool
> 
> 
> 
> Maybe this is already covered by one of our many excellent POC
> suggestions but....
> 
> This idea came about in a converstaion with Chris Ferris 
> recently and I
> then bounced it off Krishna.
> 
> 
> We should consider adding a functionality to Phillipes POC 
> functionality
> matrix for a Registry Browser GUI tool.
> 
> (As an aside we should have line items for other GUIs as well such as
> buyer GUI, seller GUI, Message Monitor GUI etc.)
> 
> The Registry Browser GUI tool would be a client of the 
> Registry Services
> and would allow a human user to use a browsing
> oriented navigation to sift through the Parties registered 
> and find the
> Parities that match their needs. The tool would make use
> of RegRep object classification support ((not yet speced but soon will
> be)) to drill down to the interesting Parties. They could then
> get the associated Party Profile Object Association support (not yet
> speced but soon will be) in Registry Services.
> 
> A second GUI (potentially in the same GUI application), a TPA 
> Assembler
> tool, could then be used to assemble the TPA between the Party
> represented by the tool user and the Party selected by the user.
> 
> Once a TPA is established the parties could conduct the rest 
> of the demo
> based on ebXML TRP messaging.
> 
> I realize that the "(not yet speced but soon will be)" aspects are
> risky, but we are working very hard in RegRep to make it happen by Sep
> 21st. We are working closely with other WGs that are defining
> meta-models for their specific areas on the classification support.
> 
> I have run this idea by Krishna since he had good insights 
> and interest
> in the discovery area. Note that this scenario shows 
> discovery based on
> up and coming ebXML specs (not eCo and not UDDI). Krishna was 
> supportive
> of the thoughts at a high level and had some additional ideas. I think
> we should start some dialog on this subject to get the teams input.
> 
> Thanks for your thoughts and comments.
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC