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

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-spec message

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


Subject: RE: [bt-spec] BTP Issue 83 : BTP message related to *part of*application message - revised solution in 0.9.0.4


Following the exchange with Doug, and some discussion with Alex, I've
removed the specified mechanism for relating application parts to individual
BTP messages. In 0.9.0.4 there is just the text and notes:

-- quote
Only CONTEXT and ENROL messages are related (&) to application messages. If
there is only one CONTEXT or one ENROL message present in the SOAP Header,
it is assumed to be related to the whole of the application message in the
SOAP Body. If there are multiple CONTEXT or ENROL messages, any relation of
these BTP messages shall be indicated by application specific means.

Note 1 – An application protocol could use references to the ID values of
the BTP messages to indicate relation between BTP CONTEXT or ENROL messages
and the application message.

Note 2 --  However indicated, what the relatedness means, or even whether it
has any significance at all, is a matter for the application.
-- end quote

That puts things back were they were before, with ID's defined in the XML,
but not used in general normative manner. Using them requires something
special in the application coder/decoder (marshall/unmarshall, whatever),
though its an easy enough thing to implement in the BTP part (just build a
table of ID -> context mappings, which the application can do lookups into).
All the fun part is in the application sorting itself out, but that isn't
our problem.

[ on that last sentence, and the second note from the text: all we can do
with the syntax is say that this context or enrol are related to the
application message. There is nothing to stop an application specification
saying it ignores the value in the header, and picks up the appropriate
context from, say, the third parameter of the method, or by some separate
interaction. Hence the special case of the application needing to rummage
through the ID table isn't that special really ]

Peter



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


Powered by eList eXpress LLC