RE: [ebxml-dev] Re: [ubl-lcsc] Re: [ubl-ndrsc] UN/CEFACT ATG 'Gen ericHeader' Project

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

Title: RE: [ebxml-dev] Re: [ubl-lcsc] Re: [ubl-ndrsc] UN/CEFACT ATG 'Gen eric Header' Project

The original use case for including the "header information" in the payload is to support some of the existing translation/mapping software tools that can only handle one "document" at a time. They are unable to support message information in a header and simulataneoulsy handle the document itself. Copying the information into a header in the document solves this problem. This is really no more than a different representation of the message information.

But is this the right way of solving the problem?

The questions we need to answer include:
1. Does creating a standard set of header information help? I think the answer is yes at it reduces development cost for *those instances* where you have a business or technical need to do it.

2. Should such a header be a standard (optional) part of each message? I don't think so since in many cases it will not be needed at all

3. Should you define a standard way of including it in a message when needed? I think you should as sometimes you will need it. In this case handling it using XML Schema and its extension mechanism makes sense, I think.

Bottom line, message metadata information should normally go in the header and not in the document but a method of putting or copying the information into the message itself should be defined for use when needed.

David

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Monday, February 24, 2003 12:02 PM
To: Duane Nickull
Cc: Burdett, David; tmcgrath@portcomm.com.au; MKudela@uc-council.org;
ebxml-dev@lists.ebxml.org; ubl@lists.oasis-open.org
Subject: RE: [ebxml-dev] Re: [ubl-lcsc] Re: [ubl-ndrsc] UN/CEFACT ATG
'Gen eric Header' Project

> -----Original Message-----
> From: Duane Nickull [mailto:duane@xmlglobal.com]
> Sent: Monday, February 24, 2003 11:43 AM
> To: Assaf Arkin
> Cc: Burdett, David; tmcgrath@portcomm.com.au; MKudela@uc-council.org;
> ebxml-dev@lists.ebxml.org; ubl@lists.oasis-open.org
> Subject: Re: [ebxml-dev] Re: [ubl-lcsc] Re: [ubl-ndrsc] UN/CEFACT ATG
> 'Gen eric Header' Project
>
>
>
>
> Assaf Arkin wrote:
> ...
> > The information exchanged between the processes is described in
> one place.
> > Let's call it 'input' for a second. If the process needs to
> know when the
> > request was made than it's input will include some property
> 'tns:createdAt'.
> >
> > The manner in which that information is contained in the
> message is defined
> > elsewhere.
>  >>>>>>>
> Assaf:
>
> Yes - we also do that.  In fact, a party knows exactly what the content
> is before they look at the payload.  This is determined by a number of
> artifacts.
>
> In ebXML architectures, the BPSS + state, along with the assertions of
> CPA ID and Conversation ID in the incoming message can alone determine
> the exact content.   If someone uses the entire ebXML arch, there is no
> need for an additional Generic Header.
>
> The need for this arises out of partners who do not use the stack.  They
> would identify a requirement for the GH then include it in the payload,
> where it belongs.

Let's say someone uses a different stack that does not include the
standardized ebXML headers.

In the definition of the payload they say what information is required in
order to process the message, including time at which it was created.

To deploy the implementation the stack must be able to somehow transmit that
information. From its perspective it may include it in the header or the
payload. I may extend the payload to include that information. I may also
use some other standard header to include that information (e.g. WS-RM).

All you need is to differentiate between the input/output of the process and
the actual message that travels over the wire (protocol dependent). You can
then let the stack determine how to encode the input/output, whether to
include it in the payload or header, and which header (e.g. SOAP header,
HTTP header, etc).

So the input would look something like:

1. purchase order
2. created by
3. created at

And the messaging layer would include way to encode that information in
different ways for different protocols.

arkin

>
> Duane
>
> --
> VP Strategic Relations,
> Technologies Evangelist
> XML Global Technologies
> ****************************
> ebXML software downloads - http://www.xmlglobal.com/prod/
>
>
> ----------------------------------------------------------------
> The ebxml-dev list is sponsored by OASIS.
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.ebxml.org/ob/adm.pl>