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

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-messaging message

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


Subject: RE: Post-SJ messaging issues


 
> 0) Mark Hale of Interwoven, who was involved in ebXML 
> Messaging, raised an argument in favour of using MIME 
> attachments for multiple (compound) messages, rather than 
> putting a bundle of BTP messages inside a SOAP header. The 
> argument was based on efficiency of processing given current 
> tools. I wasn't able to note down precisely his description of this. 
> I'm not the best qualified to comment on this, although I 
> would have thought that a brisk parse with the likes of SAX 
> would get you pretty quickly to the SOAP header where a 
> namespace with the BTP URI was used. 
> From our prior discussions, where I raised the question of 
> MIME attachments, I believe that you will favour the use of a 
> SOAP header, which seems cleaner and simpler to me. 
> Can I request that the messaging group take this bull by 
> whichever horn appeals, and drive the matter through to an 
> early conclusion? 

MIME is useful when we want to wrap entire XML documents, non-XML data, or
are dealing with very large data sets.  However, I don't believe that we are
dealing with any of the above.  The btp msgs that we have specified are just
elements and not entire documents (so no need to deal with PIs, etc.)

We could consider introducing a SOAP + Attachments
(http://www.w3.org/TR/SOAP-attachments) binding in addition to the SOAP
binding for those who need MIME packaging.  Independent of that binding, it
would be a good idea to provide an example in the spec that uses SOAP +
Attachments for those who need to use the linking capabilities from their
application specific data.

Mark, is that along the lines of what you were thinking?


> 2) We have decided to place the BTP messages inside some 
> wrapper element, e.g. 
> <SOAP-ENV:Envelope> 
>     <SOAP-ENV:Header> 
>         <btp:messages 
>           xmlns:btp="http://www.oasis-open.org/2001/BTP"> 
>            ... 
>         </btp:messages> 
>     </SOAP-ENV:Header> 
>     ... other people's headers ...              ***
>     <SOAP-ENV:Body> 
>        ... application message ... 
>     </SOAP-ENV:Body> 
> </SOAP-ENV:Envelope>

By fixing a typo in the above snippet further reinforces the need for a
wrapper element.

<SOAP-ENV:Envelope> 
    <SOAP-ENV:Header> 
        <btp:messages 
          xmlns:btp="http://www.oasis-open.org/2001/BTP"> 
           ... 
        </btp:messages> 

        ... other people's headers ...  ***

    </SOAP-ENV:Header> 
    <SOAP-ENV:Body> 
       ... application message ... 
    </SOAP-ENV:Body> 
</SOAP-ENV:Envelope>

A SOAP Envelope contains only one Header element and all headers fall into
that element; hence the requirement (in the soap spec) for them all to be
namespace qualified.  By having a wrapper element, BTP implementators can
register one handler (btp:messages) with the SOAP layer to process all BTP
header messsages.




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


Powered by eList eXpress LLC