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

[Tim McGrath <tmcgrath@portcomm.com.au>]

its a good $0.02c, i'll give you a $AUS 1.00 for it because it identifies
some confusions that exist here.

- "the time the message was created" (whether in ebMS or their equivalents
in EDIFACT UNB/UNG/UNH-UNT/UNE/UNZ) is the time the MSI on the sender party's
application created the envelope, not the time the application created the
business document (this would be the OrderCreationDate or somesuch).  they
are not the same and the former should not be assumed related to the latter.
 why would a business application want to know the scheduling of a messaging
interface.  it is like asking the  accounts receivable clerk if they need
to know the time the customer put the order in the envelope. Remember -this
is not the transport enevelope (e.g. SMTP or HTTP header) so it doesn't even
tell us the actual times of transmission.

- "the message identity" would be the equivalent to the serial number on
page from the Order pad the order was written from. it is not the identifier
of the business transaction, which would be "OrderID" or some equivalent.
 The two are not related concepts and should not be assumed related.  We
need to keep them semantically separate.
 
The goal is to ensure the business document carries all the information necessary
to allow the business application to do its job - we dont want to rely on
options 1. or 2..  

There are BIEs that are common to many documents - things like identifier
and timestamp, but these already exist (or should exist) in the document
definitions.  These are (i suspect) the 'generic header' material being considered
here.  To return to the earlier analogy, if the accounts receivable clerk
needs to know the actual time the document was sent/received then the document
definitions should contain a BIE for it, as part of the document itself.
We should not be recreating them at yet another layer of protocol.

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

-- 
regards
tim mcgrath
fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142