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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

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

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

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.


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


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>


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

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

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC