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

[A Gregory <agregory@aeon-llc.com>]

Title: Message

Bill:

 

Let me try to clarify a bit: the generic header project is going to come up with a standard set of names & datatypes that are aligned with "envelope" specs such as ebXML Messaging so that they can be included in the document *inline*, in various syntaxes. I am suggesting that UBL could take the generic header work and put a set of option attributes on the document element of all doctypes.

 

The case for this is as follows:

 

- Let's say I have a "gateway" that receives messages in various syntaxes and vocabularies, and despatches them to the right back-office applications within my company. I have to deal with EDI; I have to deal with Rosettanet; I have to deal with xCBL, etc., etc. On the XML side, I will be receiving SOAP with attachments "envelopes", containing various XML messages. To me, these all boil down to the same thing - a flat-file format that my (sometimes aging) back office can understand.  I implemented most of these apps before XML was used, and certainly before the current ebXML architecture had been developed.  When a message hits the gateway, I determine its format, use the envelope data to determine which application to send it to, and then I hand the contents of the "envelope" to a translator (but not the envelope itself).

 

Many of these standard translators were designed for EDI before XML came along, and they expect the "envelope" data to be inside the message (EDI "control" fields). These tools still expect this information to be inside the message, which is important because I may have to do things in my translator that are specific to a particular trading partner (custom codes, for example). In many cases, it is possible to write a database that stores the envelope data, and to make calls to it from my translator, but this is not simple, and sometimes not possible. It is much easier to simply put the envelope data into the XML message when I unwrap the envelope.

 

(As an aside, I would point out that no matter what your architecture, documents always carry information about "state" in them. Take the line-item information in an Order Response: it has the same names and types as the information in an Order  [say, Quantity], but it represents a different thing in reality: in an Order, that number is a request for X number of widgets; in an Order Response, it is a confirmation of x number of widgets. Different thing. I process the two identical elements differently depending on where I am in the business process.) 

 

When an application is creating a message to be sent to a trading partner, it often needs to have access to the "envelope" data in order to determine how that message is created. State may be important, for example. It may be that I need to use specific parts of a document with some trading partners, but not with others. I need, therefore, to know who I am sending the message to. But this is really "envelope" information. Many applications have no good way to communicate this information to their gateways other than by sticking the envelope information in the document, since that file will need to go back out through the translators before being wrapped in its envelope. (We don't know, but it is possible, that some applications will directly create UBL for transmission. In other cases, a natively-supporting UBL application may have its contents transformed into something else before being sent, depending on who it is going to. There are many, many combinations here.)

 

The reason you want to have a place to put control data inside an XML message is that it may be the easiest way for an application to communicate with the gateway that handles envelope information. It is not something that the latest systems typically need - but it is something that people who run large gateways often find very helpful.

 

UBL does not have to do this. It could let users define sets of attributes that use the generic header standard, but in a variety of different ways, as extensions. I think this is not the best solution, since it means that UBL-supporting software from vendors can't provide any native support for the use of these fields, which would always be extensions. I guess it's not a  huge deal, really. I just thought it was a place where UBL could leverage someone else's work to provide some useful functionality for vendors.

 

I certainly don't want to get into a big debate about architectures, since there are a lot of other issues that we are dealing with. My experience with xCBL was that having this type of in-line "envelope data" capability within a message structure was very useful, and many of our users requested it, so we put it in. So you see, this isn't about something going on the outside of the message in an envelope - if that's where you're putting it, then fine, but its a different issue.

 

What makes me uncomfortable is the idea that we are creating documents according to some judgement about what is "good" or "bad" architecture. There's lots of both out there, and I feel we ought to be trying to enable use under whatever conditions we can. The generic header idea is one of the ways in which we might be able to make our messages a bit more flexible and easier to work with. I think that's a reasonable motivation for including a set of attributes on our messages.

 

Cheers,

 

Arofan

[A Gregory]  -----Original Message-----
From: Burcham, Bill [mailto:Bill_Burcham@stercomm.com]
Sent: Friday, February 21, 2003 8:50 AM
To: 'A Gregory'; ubl-lcsc@lists.oasis-open.org; ubl-ndrsc@lists.oasis-open.org
Subject: RE: [ubl-lcsc] Re: [ubl-ndrsc] UN/CEFACT ATG "Generic Header" Project

There is an implicit premise here Arofan: that some _action_ is necessary on the part of the UBL design team in order to "support" generic headers.  That's where I lose the trail.  Isn't it true that if someone wants to define some "generic envelope" in XML that they can just do that and that and any old UBL document can just be added as an element inside that envelope?  Same for any XML-based document standard right?  Envelopes go on the _outside_ right?

 

-Bill

-----Original Message-----
From: A Gregory [mailto:agregory@aeon-llc.com]
Sent: Friday, February 21, 2003 5:10 AM
To: ubl-lcsc@lists.oasis-open.org; ubl-ndrsc@lists.oasis-open.org
Subject: RE: [ubl-lcsc] Re: [ubl-ndrsc] UN/CEFACT ATG "Generic Header" Project

Folks:

 

I haven't been able to send e-mail for a few days, but now that I can...

 

I guess I am very uncomfortable with the thought that we will be designing documents that are not suitable for use on systems that have large legacy components. Just because some older architectures were not as clean and wonderful as the new ones we're coming up with in ebXML, etc., doesn't mean that users will be moving to newer architectures as the standards are released. Most companies have to deal with some kind of gateway architecture that combines the old and the new, including EDI and possibly some of the newer stuff.

 

This is why I think generic header is important - because it helps people implement a newer architecture while still being compatible with legacy systems that are somewhat limited.

 

UBL is supposed to be immediately useable. I would guess that the number of legacy implementations requiring (or usefully having) some type of control ("envelope") data in the message still vastly outnumber pure ebXML-based architectures. We're not in the business of dictating architectures to anybody, just making useful messages that will work with different types of architectures.

 

I think this argues in favor of providing places in our documents where people can put generic header information if they need to.

 

Cheers,

 

Arofan