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: More: Proposal: A Registry Browser GUI tool


Ok - your emails got delivered in reverse - so I tried to stiff Dale
with something you've already got the outline done for!!  Ooops!

This also fits in with what Bob Haugen was articulating over on
BP - so I've Cc:d him.

The Tutorial and Test Drive (TTD) section of RegRep spec's maybe
should be something that Coord is doing - so they take each of
the groups TTD sections and combine them - so I've Cc:d Tim McGrath,
over there too.

I started a document like this for Coord back in Brussels - called
Step Processes - I think TTD is more relevant and sexy, so maybe 
now is the time for them to take this work coming out of the PoC 
efforts and put a slick cover on it and sell it as a $55 a copy book!!!?

Message text written by Farrukh Najmi
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