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