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 think this thread has gone on long enough on this list and should 
probably be moved to regrep / TRP lists. I am sensitive to the common 
syndrome of "if all you have is a hammer everything looks like a nail". I 
guess what I need to see is a *studious* depiction of the regrep "nail". If 
TRP has specified the wrong capabilities then we should fix it. Until I see 
a regrep *specification* (as opposed to a regrep POC proposal)  I guess I 
will have to (in the POC context) push this issue to the back burner.


At 11:27 PM 9/14/2000 -0400, David RR Webber wrote:
>OK - having discussed this earlier with Farrukh, and made some
>revisions to the draft document I had - yes TRP can be used
>for certain scenarios and requirements - that's not my issue.
>What I want it the flexibility to use a tailored RegRep mechanism
>where it makes sense - Reg <-> Reg comm's is one obvious
>area.  Even within this scenario I'm seeing that  http/MIME
>make sense, just that we will need error handling, enveloping and
>interaction models that are specific and TRP will be clumsy in
>those scenarios.
>What we do want is commonality of philosophy and I believe
>we have that - that someone looking at the complete set of
>TRP and RegRep will see the threads and same items
>running through.   At this point I don;t think we can lock ourselves
>into TRP completely for everything.  We have to be able to
>evaluate here based on the requirements.  Clearly RegRep
>requirements are related but different.
>Here's another thought - we may end up backing in TRP some
>of the stuff coming out of RegRep - that would be cool too.
>Thanks, DW.
>Message text written by Nicholas Kassem
> >
>Clearly you don't see the regrep Client and associated services as just
>another ebXML Business Process (granted that it is a specialized BP).
>I don't see any reason why a WAP enabled device can't be a consumer of
>regrep services. But I wouldn't put a Cell Phone at the design center and
>gut all the ebXML TRP functionality to meet the needs of this single
>device, I would proxy the client and expose it as an ISP service. Whether
>TPA assembly is likely to happen over a shoe phone is an entirely different
>matter - personally I think not.
>What makes RegRep so specialized an application that it doesn't need ebXML
>TRP - can we get passed this obsession with the Client Run-time environment
>- is there a technical basis for the position you are taking ?

[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