Arvola, Please see below. Cheers, Chris > Arvola Chan wrote: > > Chris and Marty: > > The RosettaNet message header currently carries a lot of redundant information that can > potentially be derived from the local software configuration (i.e., the implicit bilateral trading > partner agreement that has been configured into the software). For example, David Fischer earlier > asked if there should be a place in the ebXML message header to carry the PIP process identifier > (e.g., PIP 3A4 Request Purchase Order). I believe RosettaNet PIP actions have unique > GlobalBusinessActionCodes, so if we use the Action element to carry a GlobalBusinessActionCode, it > should be possible to do a table lookup using the Action element to determine the RosettaNet PIP > process identifier. Even if my uniqueness assumption turns out to be false, it is still possible > to encode the PIP process identifier information into the Action element (perhaps using it as a > prefix). > > To ease solution providers' migration from the existing RosettaNet Implementation Framework to a > future version that takes advantage of the ebXML messaging infrastructure, it will be highly > desirable if all existing RosettaNet message header elements can be mapped to equivalent ebXML > header elements, or carried as namespace specific extension elements, rather than requiring > convoluted lookups. I probably wouldn't characterize the look ups as convoluted. > > Appendix A (ebXML SOAP Extension Elements Schema) in the messaging service spec shows that the > MessageHeader can take wildcard attributes. It may be useful to also allow an arbitrary number of > namespace specific wildcard elements to be included. Similarly, the MessageData element currently > carries a RefToMessageId element that can be used for correlation purposes. In the RosettaNet > case, an equivalent InReplyTo element carries both a messageTrackingID as well as a > GlobalBusinessActionCode. The latter information while redundant helps the recipient to properly > route the response message. Therefore, it will be helpful if either the MessageData element or the > RefToMessageId can carry additional wildcard sub-elements. Is the messageTrackingId equivalent to the MessageId or is it something else entirely? Couldn't you simply add the InReplyTo header as a separate SOAP block, namespace qualified to the RosettaNet namespace? Either that, or it could simply be added as a namespace qualified extension to the MessageHeader element. I see no explicit need to have the MessageData element explicitly extensible. > > Rather than tailoring the ebXML message header to meet RosettaNet's requirements (and to the > exclusion of all others), I would advocate making the ebXML message header sufficiently extensible > so that it can meet the needs of different industry specific standards. I believe that it already is sufficiently extensible. Some would argue that it is too much so (although I am not one of them). > > Regards, > -Arvola > > Arvola Chan (
arvola@tibco.com) > TIBCO Software (on loan to RosettaNet) > +1-650-846-5046 (US-Pacific) >