Re: Definitions and Requirements drafts

["Tim McGrath" <tmcgrath@tedis.com.au>]

unfortunately, Florida at  the other end of the world from me (literally), so i
will be unable to attend.

still, i thank you for your comments and it has helped me clarify my thoughts
(somewhat).

it is important that these ground rules are understood if we are to rationalise
the ebXML approach with existing EDI applications.


David Burdett wrote:

> Tim
>
> See my comments below marked with ##
>
> David
>
> -----Original Message-----
> From: Tim McGrath [mailto:tmcgrath@tedis.com.au]
> Sent: Monday, January 24, 2000 8:34 PM
> To: Rik Drummond
> Cc: Ebxml Transport
> Subject: Definitions and Requirements drafts
>

>  The comparitive EDIFACT structure for a 'Document' would be something like:
>
> 'Interchange' (a header a bit like a META tag) within which are:
> ...Functional Group (cf group of same 'Document' types)
> ......Message (cf  'Document')
> ......Message (cf  'Document')
> ......Message (cf  'Document')
> ...Functional Group (cf group of same 'Document' types)
> ......Message (cf  'Document')
> ......Message (cf  'Document')
>
> Is there value is having this additional 'group' structure - wouldn't  it be
> useful for the definition and management of 'Services and Transactions'?
>
> ## Tim I'm not sure I completely get the point you're trying to make here. I
> **think** that we have different understanding of the smantics of various
> things. For example I think you're suggesting that a Message is closely
> related to the physical transport used, e.g. HTTP, where as I tend to think
> that a message is just a lump of data that needs to be transported between
> two points that is then wrapped in whatever data the chosen transport
> protocol needs. I suggest we try and clarify each other's understanding at
> the meeting in Orlando next week.##
>
>

yes i think you have clarified this.  i agree with you that the 'Message' should
not be transport layer dependant.

In which case it is closely akin to an "Interchange".

This concept of an 'Interchange' grew from the idea that one data file would
equal one data transfer.  However this is not often the case. For example it is
now common practice to use deliver multiple 'Interchanges' as seperate
attachments to one SMTP message.

>
> 1.2 A Document
>
>
> 1.2.2 Message
>
> Message <-> Interchange
>
> A Message is data that is sent from one Party to another. A Message consists
> of information such as:
>
> 1) a Message Envelope that indicates who sent, who should receive and the
> reason for sending the
>
> message
>
> 2) Message Routing Information, that indicates how the message was delivered
>
> 3) zero or more Digital Signatures to bind the data in the message, or
> elsewhere, together, and
>
> 4) zero or more Documents which is the business data that actually needs to
> be sent
>
> All the data in a Message is contained within a Message Wrapper.
>
> Examples of a Message include:
>
> 1) a Purchase Order that is sent by a buyer to a supplier
>
> 2) an Invoice that is sent by the supplier back to the buyer
>
> 3) a request to make a payment of $50 sent to a Credit Card acquirer
>
> 4) the authorization received from a Credit Card acquirer as a result of
> making a payment
>
> 5) Status Data indicating the success or failure of a Service
>
> The 'Message' wrapper should only concern itself with transport layer data.
>
> ## I'm not sure I agree with you. I think that in a business sense, it will
> sometimes be important to have available information in a transport protocol
> independent way that defines where the message came from and where it's
> going to. This would have a lot in common with stuff that you would also see
> in a transport-protocol-dependent message wrapper. The key issue is that you
> actually might want to digitally sign the "wrapper" information and if you,
> at some point, have to change the wrapper because you are using a different
> transport protocol, then you would break the original signature. So for
> example, if you started sending a message using one transport protocol, you
> would have to use that same protocol all the way through the intermediate
> servers it passed through if you didn't want to break the signature. On the
> other hand if you have a message wrapper that is transport protocol
> independent, then you can digitally sign it and transport over whatever
> transport protocol you want to.##
>

i agree. the difference between the 'transport-protocol-dependent message
wrapper' and the 'transport-protocol-independent ebXML message wrapper' would be
that the latter has information content agreed (even if by default) to the
trading partners (parties) involved.

For example, Company/Service/Application/Standards identifiers, Digital
Signatures, control references, etc..

The 'transport-protocol-dependent message wrapper' would have things like the
HTTP/SMTP Header information.

whilst there may be a relationship  between these two i suspect not many values
actually do overlap.

For example, in the SMTP example above (deliver multiple 'Messages' as seperate
attachments to one SMTP message) the SMTP header would not have much overlap
with the individual Message wrappers. This 'mailbag' concept is popular with
Application Servers and Value Added Networks, where thay act as clearing houses
for Messages.

- and so, where does this leave the second item ( Message Routing Information)?
What would be in there?


>
> Aren't these examples of Documents?  A 'Message' could carry several of
> these.
>
>
> ## On re-reading the above I think I can see where you're coming from. The
> point I was trying to make was that a Purchase Order is, for example, a
> document, it becomes a "message" only when it is being sent from one place
> to another.##
>

Ok  - then maybe it becomes 'part of a message'

>
> 1.2.7 Request Message
>
> A Request Message is a Message sent from one Party to a second Party with
> the intent that the second
>
> Party act upon the data in the Request Message by carrying out a Service.
>
> 1.2.8 Response Message
>
> A Response Message is a Message that is generated by the Party that received
> a Request Message. It is
>
> produced as a result of carrying out the requested Service. It is the last
> Message in a Document
>
> Exchange unless the Message contains errors.
>
> Response Messages are sent back to the sender of the Request Message.
>
> Shouldn't Service Requests operate at the Document level?
>
> Therefore aren't these 'Request Document' and 'Response Document'?
>
> ## I think this reflects our difference in understanding in what is meant by
> a Message compared with a document as described earlier.##
>

my conern is that i think/thought a Message could hold more than one Document.
Can we allow a Message to carry a Purchase Order and a Request for Quote
together?

>
> I guess my general point is that I beleive a 'Message' and its wrapper
> should be objects dealing with the transport layer issues and that
> 'Documents' should carry the application information.
>
>
> ## I'd welcome an opportunity to clarify the definitions to reach a shared
> understanding. Perhaps we can do this during the meeting in Orlando. Will
> you be there?##
>

sorry, only if i walked :-)


--
regards
tim mcgrath
TEDIS   fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142

begin:vcard 
n:McGrath;Tim
tel;pager:australia 016 631 632
tel;cell:041 381 6846
tel;fax:+61893352142
tel;work:+61893352228
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:tmcgrath@tedis.com.au 
x-mozilla-cpt:;-4960
fn:tim mcgrath
end:vcard