RE: TRP Work Plan - Version 17 Aug 00

[Henry Lowe <hlowe@omg.org>]

Yep, I can buy that.  But it would be a good idea to sort 
out what comes from where and by what means.

 - hal
-----------------
At 08:45 AM 08/25/2000 -0400, mwsachs@us.ibm.com wrote:
>... and some of the information about the other partner will come from the
>TPA.
>
>Regards,
>Marty
>
>****************************************************************************
>*********
>
>Martin W. Sachs
>IBM T. J. Watson Research Center
>P. O. B. 704
>Yorktown Hts, NY 10598
>914-784-7287;  IBM tie line 863-7287
>Notes address:  Martin W Sachs/Watson/IBM
>Internet address:  mwsachs @ us.ibm.com
>****************************************************************************
>*********
>
>
>
>Henry Lowe <hlowe@omg.org> on 08/23/2000 11:16:48 AM
>
>To:   David Burdett <david.burdett@commerceone.com>
>cc:   "'Henry Lowe'" <hlowe@omg.org>, "'gvh@progress.com'"
>      <gvh@progress.com>, Martin W Sachs/Watson/IBM@IBMUS, "'Jim Hughes'"
>      <jfh@fs.fujitsu.com>, ebxml transport
>      <ebxml-transport@lists.ebxml.org>
>Subject:  RE: TRP Work Plan - Version 17 Aug 00
>
>
>
>David,
>
>Please see single comment embedded below for context.
>
>Henry
>
>At 02:44 PM 08/22/2000 -0700, David Burdett wrote:
>>Henry
>>
>>We have from the requirements and overview document ...
>>>>>
>>1) Servers/systems that support the exchange of documents shall be treated
>>as "black boxes"
>>2) The method used to transport documents shall be completely independent
>>of:
>>  a) the hardware used by the server/services at each end
>>  b) the software or systems architecture of the server/services at each
>the
>>language used for implementation of systems and applications.
>><<<
>>
>>I think these requirements imply that one party need have no knowledge of
>>the technology used by the other party. In turn this means that:
>>1. A party must be able to discover *everything* they *need* to know just
>>from the message, and therefore
><hal>
>I'm not sure the quote above says that everything must come from the
>message itself and excludes some of it coming from parameters of the
>(conceptual or real -- take you choice) service interface.  While I
>can't speak for Gordon, I read between the lines (always dangerous)
>that he saw some of this info coming from these parameters.
></hal>
>
>>2. We must write the ebXML Messaging Services spec so that they can ignore
>>the service interface spec **if** they want to.
>>
>>Please understand, that I think a service interface spec will be a very
>>useful thing to have (in fact we wrote one for IOTP). I'm just arguing
>that:
>>1. The ebXML Messaging Services Spec should not have to rely on it
>>2. Implementers don't have to built to it if they don't want to.
>>
>>David
>>
>>
>>-----Original Message-----
>>From: Henry Lowe [mailto:hlowe@omg.org]
>>Sent: Tuesday, August 22, 2000 1:40 PM
>>To: David Burdett
>>Cc: 'gvh@progress.com'; 'mwsachs@us.ibm.com'; 'Jim Hughes'; ebxml
>>transport
>>Subject: RE: TRP Work Plan - Version 17 Aug 00
>>
>>
>>David,
>>
>>You are stating a goal for our Headers here.  Did we ever agree
>>to this goal, i.e., all info necessary for message exchange be
>>contained in the Header?  I'm not saying this is a bad goal, but
>>if we are not all singing from the same book, we may not agree.
>>
>>
>>I believe Gordon pictures some additional info being conveyed
>>in the parameters of the API, be it real of conceptual.  Personally,
>>I rather like this goal as it severly constrains the API parameters
>>to be trivial.
>>
>>Henry
>>-------------------------------------------
>>At 12:50 PM 08/22/2000 -0700, David Burdett wrote:
>>>Gordon
>>>
>>>I agree that awareness of the Interface is a benefit. I disagree that
>>>"implementations of the wire protocol will require semantic knowledge
>that
>>>is not imparted stricly from the fields in the header".
>>>
>>>If we can't fully define, in our spec, the meaning or semantics behind
>...
>>>1. each field in the header
>>>2. the meanings implied when these fields occur in combination within a
>>>header
>>>3. the meanings implied when messages (e.g. a normal message and it's
>ack)
>>>are received in a specific sequence
>>>
>>>... then, IMO, we are not doing our job properly.
>>>
>>>If we REQUIRE that particular type of interface is used to make an ebXML
>>>Messaging Service Spec work, then we are creating an additional barrier
>to
>>>its use.
>>>
>>>David
>>>
>>>-----Original Message-----
>>>From: Gordon van Huizen [mailto:gvanhuiz@progress.com]
>>>Sent: Tuesday, August 22, 2000 4:07 AM
>>>To: David Burdett
>>>Cc: 'mwsachs@us.ibm.com'; 'Jim Hughes'; ebxml transport
>>>Subject: Re: TRP Work Plan - Version 17 Aug 00
>>>
>>>
>>>
>>>
>>>David Burdett wrote:
>>>> I think it should be possible for two parties communicating using the
>TRP
>>>> spec to achieve COMPLETE interoperability without implementing ANY of
>the
>>>> Interface spec - i.e. conformance to the wire protocol alone should
>>>suffice.
>>>> Do you agree?
>>>
>>>My assertion would be that successfully achieving interoperable
>>>implementations of the wire protocol will require semantic knowledge
>>>that is not imparted stricly from the fields in the header themselves
>>>and can benefit from awareness of the Interface. But that's just a
>>>hunch, since we aren't "there" yet. Regardless, the two levels must be
>>>kept in synch for a developer to stand a chance of implementation, as
>>>well as for us to actually get the spec work done. Witness the deltas
>>>that are appearing elsewhere.
>>>
>>>-gvh-
>
>
>
>