Arofan, a clarification if you please. You say: "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" But if these translators were designed with no XML knowledge, they *will* have to be modified anyway to deal with UBL, and what they'll do is probably convert the XML message to something else, because whatever they are a front for will most probably have no XML knowledge either. It would be trivial, at that point, to merge the envelope and the XML message itself into what this application is used to, right? If so, why oh why do you want to replicate the envelope? On Fri, 2003-02-21 at 09:57, A Gregory wrote: > 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]