RE: Definitions and Requirements drafts

[David Burdett <david.burdett@commerceone.com>]

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


My apologies for leaving these comments so late, however I do feel it
necessary to input some EDI viewpoints into the debate. 

For my benefit and others from the EDI world following this thread I have
tried to indicate the comparible EDIFACT terminology in the definitions.  I
accept these may not be absolute but want ot be sure that we have a common
reference point. 
  


1 Documents, Parties, Messages and Document Exchanges

1.1 Overview


If i understand this section the hierarchy is: 


Message - transport details (HTTP,etc..) 
 ...Document - service details (XML,HTML,PDF, etc) (eg a service request) 
 ...Document - service details (eg request) 
... Document - service details 


Therefore isn't a 'Service Message' (such as a Document requesting a price
quote) actually 'Service Document' ? 
That is, the 'transport' layer needs to be independant of the 'application'
layer. EDI and specifically EDIFACT deals with the latter. 

 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.##
  

1.2 A Document

A Document is any data that can be represented in a digital form.

Examples of Documents include:

1) a set of XML Elements

2) an XML Document

3) an HTML Document

4) a word processing file

5) a Adobe Acrobat PDF file

6) a binary file.

7) An EDI/ANSI/EDIFACT message   

##   But of course ;-) ## 
1.2.1 Party

A Party is a company, organization or individual or other entity that can
generate or receive Documents.

Examples of a Party include:

1) a Merchant

2) a Customer

3) a Lawyer

4) a Bank

A Party is also used to refer to systems or servers that are carrying out
Services or processes on behalf

of a Party.




In EDI parlance this is a 'Trading Partner'.  

## Perhaps we should include equivalent EDI terminology in the defintions
document ... perhaps we should even consider adopting the equivalent EDI
terminology if there is a good match. Thoughts everyone?##

There may a difference between a Party who receives the Message and the
Party for whom the Document is destined.  That is the difference between the
'transport layer' Party and the 'application layer' Party. For example, a
central server receives Documents to be distributed to various branches,
agencies, systems, etc.  

## You can also get intermediary parties who accept one message, reformat it
and then forward it on to its next destination. ##  


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.##

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.##

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.##

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?##  

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