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]