Compound and app-within-BTP message proposals

[Alastair Green <alastair.green@choreology.com>]

1. Concrete proposal for compound and related messages:

<btp:compound related=true>
    <btp:address>target-address</btp:address>
    <btp:begun> ... </btp:begun>
    <btp:context> ... </btp:context>
</btp:compound>

Note that there is an implicit "collapse" of the repeated target
addresses for the enclosed simple messages.

2. App within BTP compound, BTP compound within App:

a) SOAP approach: what a communicator/gateway must do:

Find <SOAP-ENV:Envelope> and within it find <SOAP-ENV:Header> that
contains an element in the namespace "http://oasis-open.org/2001/BTP"
(or whatever).
Take that element and its siblings in the same namespace and hand them
off for BTP processing. Find <SOAP-ENV:Body> and hand its contents off
for appplication
processing.

b) A general app-within-BTP approach creates one additional rule for BTP
Communicators:

Find <btp:app-request> within <btp:compound>; and hand its content off
for application processing; hand the rest of the <btp:compound> off for
BTP processing.

If we do not have this general facility then we have to create a new
rule for each binding ad infinitum.

I therefore propose that we have to allow the following (where
related=false can presumably be defaulted)

<btp:compound related=false>
    <btp:address>target-address</btp:address>
    <btp:compound related=true>
        <btp:app-response> ... </btp:app-response>
        <btp:enrol> ... </btp:enrol>
    <btp:compound related=false>
    <btp:vote> ... </btp:vote>
</btp:compound>

implying we define btp:app-request and btp:app-response. This has the
added virtue of capturing the fact that BTP does assume an application
level request response
model (or at least, request-ack) in order to assure the proper
enrollment of participants, and the correct completion of application
work prior to attempting to terminate
the transaction.

Alastair