RE: Proposal: A Registry Browser GUI tool

[Krishna Sankar <ksankar@cisco.com>]

Exactly. I fully agree with you. And we *do* want to show interoperability
and leverage. I did not mean it in another way.
cheers
-----Original Message-----
From: Matthew MacKenzie [mailto:matt@xmlglobal.com]
Sent: Wednesday, September 13, 2000 10:26 AM
To: Krishna Sankar; ebXML poc
Subject: RE: Proposal: A Registry Browser GUI tool


Krishna,
  Our suggestion toward WebDAV and associated specs was an attempt to
enforce the ideas that Farrukh and yourself have expounded upon.  In a POC
team, there are bound to be members of the team utilizing technologies that
are implemented by their employers, so to stay vendor neutral, and thus
unbound to any technology - why not use a standard that is well out of any
one party's hands?  This Proof of Concept is obviously going to be a hands
on interpretation of a lot of the ebXML specification work, how will it
synthesize without being attached to some technolog(y|ies)?

Cheers!

-Matt

-----Original Message-----
From: Krishna Sankar [mailto:ksankar@cisco.com]
Sent: Wednesday, September 13, 2000 10:11 AM
To: ebXML poc
Subject: RE: Proposal: A Registry Browser GUI tool


Hi all,

	Let me add my 2c to the discussion - I could only remain silent so long ;-)

	I agree with Farrukh (for a change) in the sense that the technology
binding would be services over the regrep APIs. And yes, UDDI jumped the gun
by making SOAP binding as a part of the spec. May be the next version will
abstract out that dependency.

	Farrukh, I think we the ebXMLites are in aggrement with the above
statement.

	cheers

-----Original Message-----
From: Farrukh Najmi [mailto:Farrukh.Najmi@east.sun.com]
Sent: Wednesday, September 13, 2000 9:58 AM
To: Matthew MacKenzie
Cc: Farrukh Najmi; ebXML poc; Krishna Sankar
Subject: RE: Proposal: A Registry Browser GUI tool


Mathew,

Thanks for your suggestion. DW has passed this on earlier.

I must stress that the task at hand in Registry Services (RS) spec is *not*
to specify technologies but to specify functional behavior. Once that is
nailed
down then there *must* be a default interoperable ebXML TRP Messaging based
API specified for accessing the functionality. Beyond that we can have any
number
of bindings to specific technologies (e.g. Java RMI, Corba IDL, DASL,
SOAP....).

IMHO, getting married to stuff like DASL up front is not what ebXML is all
about.
We can however look at things like DASL to leverage concepts and ideas.

The above philosophy I propose could be applicable to any and all ebXML spec
work.
To exemplify that philosophy let consider UDDI as a case. It would have been
nice if
UDDI specified the functional behavior of the service independent of any
technology
(e.g. SOAP). It could then have specified a SOAP binding to the UDDI service
and

we in ebXML could contribute an ebXML TRP Messaging binding.

I hope that this philosophy is consistent and resonates with my colleagues
in
ebXML.

--

Regards,
Farrukh

Matthew MacKenzie wrote:

> Farrukh, Everyone,
>
> I have been working a lot on XML Global's registry and repository effort,
> and as such have been investigating adopted standards that are already
> floating around to integrate with our own core technologies with an end
goal
> of providing a complete registry interface.
>
> My main focus has been DASL (DAV Searching and Locating Protocol), but I
> have also dived into the WebDAV spec.  WebDAV has been implemented by
> Microsoft and included by default in their operating systems since Win98
> OSR2 (or earlier).  Using "WebFolders", you can cut, copy, paste, delete,
> mkdir, put and find properties on files from a familiar Windows Explorer
> window. If a registry can "virtualize" its content and expose it via this
> protocol, you have a GUI browser right there.  There are also open source
> Java DAV Browsers available for download if you look for them.
>
> Something to think about, perhaps.
>
> Cheers,
> __
> Matthew MacKenzie
> VP Research & Development
> XML Global Technologies, Inc.
> (604) 717-1100 x 107
>
> -----Original Message-----
> From: Farrukh Najmi [mailto:Farrukh.Najmi@east.sun.com]
> Sent: Wednesday, September 13, 2000 7: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.