If I remember correctly, the example has a wsu:Id because there can only be one ID attribute on an XML element (a weird constraint in XML Schema) and because this example uses WS-Security (although the content of wsse:Security is omitted, but there would be a ds:Reference to the Body in it), the ebMS module cannot create an xml:id attribute because then there would be two if the WSS module adds the other one. The WSS module could use the id attribute, but see the
https://issues.oasis-open.org/browse/EBXMLMSG-39 issue on why it may not do so. It's true that ideally the MSH shouldn't need to know about this. The same issue is with eb:Messaging that AS4 wants to have signed and has an id attribute. On 06/22/2015 12:51 PM, Sander Fieten wrote: I agree with creating an issue for this as the spec is not very clear on payloads contained in the SOAP Body. I find the example also a bit strange because I assume the wsu:Id is typically added by the WS-Security processor so the id is not available when the eb:PartInfo element is created. Would expect the root element of the payload (CrossIndustryInvoice) to have the id attribute or no reference at all in eb:PartInfo/@href attribute. Problem however with that however is that Core Spec states: The absence of the attribute href in the element eb:PartInfo indicates that the payload part being referenced is the SOAP Body element itself ”. So root element of payload delivered to consumer application would be <SOAP:Body>. But to have the payload equal at producer and consumer side this would require the producer to submit a complete SOAP Body. I would therefor propose to change the text of the Core Spec so that a eb:PartInfo without a href attribute refers to the content of the SOAP:Body element instead of the SOAP:Body element itself. In AS4 this will result in the child element of the SOAP:Body because of the WS-I BP rule Theo mentioned (WS-I BP compliance is not defined in Core Spec). I will also add comment to the issue to keep discussion centralised in issue tracker. Regards, Sander On 22 Jun 2015, at 11:55, Pim van der Eijk <
pvde@sonnenglanz.net > wrote: The developer sends me the following comment: Then the definition of partInfo needs to be corrected in the spec. “The PartInfo element is used to reference a MIME attachment, an XML element within the SOAP Body , or another resource which may be obtained by resolving a URL, according to the value of the href attribute” I will file a JIRA issue. On 06/22/2015 11:38 AM, Theo Kramer wrote: I would agree with this. Also according to WS-I Basic Profile 2.0 section 3.2.1 SOAP Envelope Structure rule 9981, an ENVELOPE MUST have exactly zero or one child elements of the soap12:Body element. So allowing references to sub-nodes in the body could open interpretation up that more than one payload is permitted in the soap body. This potentially leading to interop issues. On 22 Jun 2015, at 10:23 , Pim van der Eijk <
pvde@sonnenglanz.net> wrote: Hi, The example in AS4:
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/AS4-profile/v1.0/os/AS4-profile-v1.0-os.html#__RefHeading__58427_149522555 Has a reference to the XML payload in the SOAP Body by referencing its wsu:Id <eb:PayloadInfo> <eb:PartInfo href= /> </eb:PayloadInfo> <S12:Body wsu:Id= _f8aa8b55-b31c-4364-94d0-3615ca65aa40 > <CrossIndustryInvoice xmlns= urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:2 > <!-- content omitted --> </CrossIndustryInvoice> An implementer asks if that attribute should not be on the business document (CrossIndustryInvoice) instead, Now in many cases the schema does not have such an ID, and anyway we don't want the MSH to change the XML payload. Do we agree that a Payload reference to an ID the SOAP Body is to be interpreted as referencing the payload in the Body, rather than the sub-node, as the example suggests? (I am aware that the href can be omitted and then it implicitly references the payload in the body, but this is about situations where there is an explicit reference). There is a similar issue
https://issues.oasis-open.org/browse/EBXMLMSG-39 but it is about signing. Kind Regards, Pim