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

[Duane Nickull <duane@xmlglobal.com>]

David:

Your solution #1 is what both the UMM and architecture have been saying. 
  IF you desire having a generic header,  then place it into the payload 
with the rest of the business information.  That is the same for any 
business information needed by the parties.

Business information is

1.  identified as needed during the modeling phase
2.  developed using UMM
3.  expressed in the syntax for the transaction.

What members of the architecture team expressed was that adding business 
information into a space in the ebXML MS is a Pandora's box.  Where do 
we stop?  If someone now says they need a second element for giving 
their applications a direction for more specific processing, do we place 
that as an architectural component too?

I personally like clean and clearly defined areas of functionality, 
consistent with OO programing methodology.  Keep the messaging layer 
doing messaging etc.

There is nothing in the architecture document that says you cannot have 
a generci header in the business payload.  It is clearly allowed when 
following the process of UMM to model a business payload.  If it is 
identified as needed, then it will be there.

If we call attention to it with a sentence, then what else would we have 
to call attention to?  Do we have to list "address" in the architecture 
document, along with "name" "po number" and other business elements?  I 
personally would be against listing any specific syntax of business 
information in the architecture document.  We already allow all 
information that any user deems necessary - one of the key strengths of 
ebXML and related specifications.

Duane Nickull

I am sure this will be discussed in greater detail in


Burdett, David wrote:
> As counter thought (I would not put this as strong as an opinion), there is
> one use case for having a generic header.
> 
> If, for example, you take using UBL with ebXML MS, then there is information
> in the ebXML MS header that "might" be useful to the process that is
> handling the UBL document, for example the time the message was created, or
> its identity.
> 
> I would guess that most implementations separate the ebXML MS envelope from
> the UBL document, therefore there is a risk of this information being lost.
> There are a number of ways around this, including:
> 1. Copying the information from the ebXML MS header into a "generic header"
> within the UBL document - this should be optional, if done at all.
> 2. Providing an API to the ebXML MS implementation that allows an
> application to derive this information.
> 
> Just my $0.02c.
> 
> David
> 
> -----Original Message-----
> From: duane@xmlglobal.com [mailto:duane@xmlglobal.com]
> Sent: Saturday, February 15, 2003 6:18 PM
> To: tmcgrath@portcomm.com.au
> Cc: 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
> 'Generic Header' Project
> 
> 
> 
>>I don't want to buy into this debate, just get a clearer view of the
>>architecture being proposed.  ...> As Duane Nickull has indicated on the
>>ebxml-dev list, this is an> architectural issue, not one that those in the
> 
> ebXML MS team
> 
>>necessarily  appreciate (from their comments i suspect they just think
>>
> 
> Tim:
> 
> To clarify my own opinion,  I do not see any need for a generic header
> since this does duplicate infromation already avaiable to both sender and
> receiver.  As such,  our architecture team made a decision NOT to place
> the GH in the architecture.
> We did agree, however, that in certain circumstance,  one or both parties
> may feel that they desire  the generic header (identified via UMM?) and
> can use it.
> The architecture does not prescribe it or disallow it.
> 
> Duane Nickull
> 
> 
> 
> ----------------------------------------------------------------
> 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/