OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [ebxml-dev] Re: [ubl-lcsc] Re: [ubl-ndrsc] UN/CEFACT ATG 'Gen eric Header' Project

Duane

You don't need two unique ids but you might get them because one is
associated with the document and the other with the message/envelope.

David

-----Original Message-----
From: Duane Nickull [mailto:duane@xmlglobal.com]
Sent: Wednesday, February 26, 2003 8:45 AM
To: Burdett, David
Cc: Assaf Arkin; 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


David:

These are indeed good thoughts.  I have a question for the generic 
header team.

How is a generic header that uniquely identifies a payload different 
from the existing Unique Idenfitier for the payload?  As you are aware, 
  an aggregate BIE has a Unique ID already present.   What are the 
differences?  Why would we want two Unique ID's?

Duane



Burdett, David wrote:
> 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>
> 


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

<<attachment: winmail.dat>>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]