RE: TRP Work Plan - Version 17 Aug 00

[Henry Lowe <hlowe@omg.org>]

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-