RE: Proposal: A Registry Browser GUI tool

[David RR Webber <Gnosis_@compuserve.com>]

Farrukh,

Seems to me you cannot have your cake and eat it however!

On the one-hand you articulate you do not want to re-invent the
query language wheel, and to use existing standards, and to use
http.

What we need here is a decision matrix - I'll try add one to the
RegRep draft.

Bottom line - I'm seeing DASL is a kinda binding!  It does not
dictate like SOAP does, and it is a lot lighter in implementation.
And its IETF so that is very open going forward if we have to 
pick here.

The key difference here is mandating.  My suggestion is that 
we go ahead and use DASL for the V1.0 - and then look at
doing others after.  That way we are not mandating, and
we are not locking ourselves in.  But given the fact that DASL
has already defined a lot of what we need lets go there first.

Once we have this all working - someone can do SOAP, 
Corba et al implementations from a very well defined and
tight spec'.  That's got to be what we need right now.

Thanks, DW.
=========================================================
Message text written by Krishna Sankar
>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.
<