RE: [ebxml-msg] bundling rule clashes with WS-I BP

["Pim van der Eijk" <pvde@sonnenglanz.net>]

Hi Jacques,

 

Good catch.  Yes,  we should use MIME attachments as only option for secondary user message units. (The primary unit could still go to the body, if that is what it would go to in the non-bundled case).    This avoids having to worry about unique identifiers in XML business payloads. Those payloads are typically generated by back-end applications, and for an MSH to be able to just copy them into a separate MIME container has many benefits separate from the WS-I conformance issue. 

 

Pim

 

---

From: Jacques R. Durand [mailto:JDurand@us.fujitsu.com]
Sent: 09 March 2010 20:37
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] bundling rule clashes with WS-I BP

We have a bundling rule that violates the WS-I Basic Profile 2.0:

 

 In Bundling  3.2.1:

• SOAP Body: the Body children elements of every ebMS message unit are listed at same level under the SOAP Body of the bundled message. These parts are still referred to by the eb3:PayloadInfo element of the related message unit header. An application that bundles multiple message units MUST make sure that any XML ID values that are unique in the message unit are also unique in the bundle.

BP 2.0 profile (similar one exists in BP 1.2 for SOAP 1.1):

R9981 (from issue: ) An ENVELOPE MUST have exactly zero or one child elements of the soap12:Body element.

in 4.4.1:

" For document-literal bindings, the Profile requires that at most one part, abstractly defined with the element attribute, be serialized into the soap12:Body element. ..."

Rationale is "...interoperability problems if different implementations do not agree on the number of allowable children for
   the soapXX:Body element. "

Proposal:

We should redefine this bundling rule so that all implementations must comply with WS-I BP, and puts all payloads except one, in attachments.

At best, the possibility of several Body children elements should be just an option (yet a "not recommended" one), that should not be required to be supported in the conformance clause - and can be controlled / agreed on via PMode.

 

Jacques