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