[ubl-lcsc] Re: [ubl-ndrsc] UN/CEFACT ATG "Generic Header" Project

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

I must admit to being confused by this.  I recognise the concerns that 
EDIFACT folks might have about this data, but I am not sure that they 
need to have any.  It is being tackled by the OASIS ebXML MS TC.

Either I missed soemthing here, or what you describe sounds to me like 
the ebXML MS specification, which i think you will find covers the same 
ground.

Therefore, my first reaction would be to suggest that rather than 
re-invent this protocol we remain agnostic of it.

However, I would like to make a few observations and ask some further 
questions, either of Arofan or Melanie....


A Gregory wrote:

>This is an incredibly common set of data - we found ourselves adding it in
>xCBL, and every other major e-business vocabulary lists this data, typically
>as a set of attributes on the document-level element. It includes such
>information as who sent the message, who is receiving it, what business
>process it is part of (correlation IDs), and similar. It is very similar to
>some of the control fields found in EDI messages.
>  
>

The reason that every major e-business vocabulary lists this data is 
that they want to remain independant of messaging and transport 
protocols.  The problem with this is that you establish  duplicate and 
possibly conflciting data sets.  One of the strengths of the ebXML 
framework is that is separates the 'business/core components' , 
'business processes' and the 'messaging, routing and transport' 
protocols.  They do not overlap. Rather, they work with each other (but 
do not rely on each other).  

I must plug a ( :-[ ) reference for this comparison 
(http://www.amazon.com/exec/obidos/ASIN/1861005903/qid%3D1044929975/103-7202419-8491066). 
 Specifically, chapter 15 compares EDIFACT control fields with ebXML MS 
elements.

>The generic header project is standardizing the names and datatypes for
>these fields. It would be fairly simple to adopt the proposed standard, and
>fit this information in as a set of standard, optional attributes at the
>document level. (And I can guarantee that of we don't include this basic
>information in our version 1.0, we'll have requests to include it in our 1.1
>release...)
>  
>
Isn't this a 'higher level' protocol?  doesn't it run the risk of 
overlapping with others?  I think you will find that the ebXML MS spec 
has mappings to the EDIFACT control fields (UNB-UNZ, UNG-UNE, and 
UNH-UNT) - this is not accidental, those building the ebXML MS spec used 
these (and the NASI counterparts ) as a basis for their work.

>Typically, these fields are used by translators that are communicating with
>a back office application, and which are capable of only performing the
>translation on a single XML document at a time. If the envelope information
>isn't present, then the translator has to make calls out to a database or
>other place where the envelope information is stored. This is often not
>possible, especially for users with less sophisticated systems, since a link
>to the envelope received and opened at a corporate gateway doesn't always
>exist.
>  
>
Again, what you decribe is the business proccess interface that is part 
of ebXML  BP definitions.  Isn't this a CPP reference accessed from a 
repository?

>Melanie and her group can supply materials describing the project, but I
>think it would be great if we could adopt this standard as a part of the UBL
>library, and figure out how to implement it. At the very least, I'd like to
>add it to the agenda for discussion at the next NDR con-call.
>  
>
I am all for unified standards , but i am not clear what problem this 
project is addressing that ebXML isn't already working on.  

Perhaps we can see the materials you refer to, and specifically how this 
varies from that of the ebXML MS OASIS technical committee (ref: 
http://www.oasis-open.org/committees/ebxml-msg/documents/ebMS_v1_092.pdf) ?

>Cheers,
>
>Arofan Gregory
>
>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>  
>

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