OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ebxml-msg] packaging comments


I would like to see the specific model of batching  that is probably behind all these proposed XML changes explained in much more detail before buying into all these XML changes.

For example, why not just approach batching by using MIME multiparts with each part its own SOAP envelope? Or multiparts of SOAP with attachments? Or use the transport to send multiples on a single connection? And so on…

 

There are probably a lot of ways to batch, and I would like to understand requirements and use cases before jumping into these changes.

 

1)       eb:UserMessage element to be renamed eb:UserMsgUnit. To avoid confusion with ebMS User Message, now that we have the notion of "message unit". (In a future release, bundling could allow several units within an ebMS Message.)

 

 

2)       eb:SignalMessage element to be renamed eb:SignalMsgUnit.

 

        

 

3)       eb:MessageId element is renamed to eb:UnitId. (only message units are really identified and referenced in  MEPs, not SOAP messages)

 

        

 

4)       eb:RefToMessageId element is renamed to eb:UnitRef.

 

 

5)       The attribute eb:Partref/@eb:id is removed (no different from an XML Id).

 

6)       The attribute eb:Partref/@eb:idref is renamed to eb:Partref/eb:cid. The absence of the attribute eb:cid in the element eb:Partref should indicate that the payload being referenced is nothing but the SOAP body element itself. For example, a declaration like the following would simply be referencing the contents of the SOAP body: <eb:PayloadInfo> <eb:Partref/> </eb:PayloadInfo>

 

7)       The element eb:property has two new optional attributes added to it: xsi:type and eb:cid. The attribute xsi:type indicates the XML type for the value of the property, while the attribute eb:cid indicates the content ID of a possible property attachment (when the value of a property is an attachment).

 

8)       It must be clearly stated in the spec that the value for the element eb:cid (whether in the attribute eb:property/@eb:cid, or in the attribute eb:PayloadInfo/eb:Partref/@eb:cid) should be the exact value of the "Content-ID" mime header element of an attachment. In other words, if the Content-ID mime header has a value like the following:

 

                    Content-ID: <someId@domain.com>

 

             then the value of the attribute eb:cid should be <someId@domain.com>,  not someId@domain.com or #someId@domain.com.

 

 

9)       Suggest that eb:Message element be renamed eb:Messaging. This reflects the name of the spec and avoid possible confusion with both ebMS Message (denotes the entire SOAP message containing this header) and with message unit.

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]