Definitions and Requirements drafts

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

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

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

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.

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

Aren't these examples of Documents?  A 'Message' could carry several of these.
 
 

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

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