[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ubl-lcsc] Re: [ubl-ndrsc] UN/CEFACT ATG "Generic Header" Project
Tim: I think there might be some confusion here. You are correct in pointing out that this is duplicative of messaging fields, and that point has not been lost on those doing the Generic Header project - alignment is key. The point is that long before the message envelope has been created, and after the envelope has been received and opened - some of the messaging information is still needed by applications that *cannot* access the envelope information. This is a very common problem, especially with tools such as EDI translators that are now being equipped to handle XML (they always relied on the control fields in the message). The idea is to have an optional, standard place to put this data *in the message* should that be needed. Melanie can probably better answer your questions, but I would point out that this is not a business modelling concern - it is strictly mechanistic, to accomodate the capabilities of tools and applications. Cheers, Arofan -----Original Message----- From: Tim McGrath [mailto:tmcgrath@portcomm.com.au] Sent: Monday, February 10, 2003 6:24 PM To: A Gregory Cc: UBL-NDR; UBL LCSC; mkudela@uc-council.org Subject: Re: [ubl-ndrsc] UN/CEFACT ATG "Generic Header" Project 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,typicallyas 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-7202 419-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 our1.1release...)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 alinkto 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 theUBLlibrary, 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 ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC