[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Post-SJ messaging issues
Alastair, A very good overview. I
would also like to express my agreement with Alastair’s
proposal for uppercase names, which of course is a stylistic preference. Thank
you, -- -----Original Message----- Hi Alex and James: I wanted
to make sure you were aware of the decisions at the FTF in San Jose relating to
messaging, and are also aware of a discussion that arose there which leaves us
with an unresolved issue to be decided by the messaging sub-committee. Please
note that the desire is a) to get a final draft by 31 August for voting on or
about 14 September, and b) that we aim to wrap up issues like those below by
the time of the next conference call next Thursday 9 August, via e-mail
discussion, with a bias towards fast back-room fixes among interested
specialists, leading to well-formed proposals. 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? In what
follows I am going to assume that we go for SOAP header. Otherwise some bets
are off, and we need some new proposals to meet the requirements. 1) We
have decided (London, reaffirmed SJ) that BTP protocol actor-in-role
transmitting to BTP protocol actor-in-role we will put BTP messages in the SOAP
body; when BTP messages are related to application messages and travel with
them we will put them in the BTP header. 2) We
have decided to place the BTP messages inside some wrapper element, e.g.
The name of the wrapper was not nailed down: personally I would favour
"btp:messages" as being precise longhand. 3)
Side-point: We need to nail down the URI in consultation with Karl Best, if we
hadn't already done so. 4) The
SOAP envelope is appropriate to any means
of transmission (carrier protocol, binding) [Assaf Arkin, Intalio]. In other
words, we should not attempt to duplicate the expression of relationship
between application messages and BTP messages in a proprietary BTP manner, but
should rather always use the standard SOAP envelope structure for this purpose.
It's just an XML schema, and it's better to use an existing one with standing
than a new one which is narrow and novel. I believe this conclusion will align
with Alex's expressed concern that we not compete unwittingly with SOAP. (It
has taken me a while to understand how little SOAP covers, but the penny is
dropping.) 5) The
relationship of BTP message to BTP message (as noted by & in the
specification) is to be expressed by containment (proposal of Savas and Fred),
thus:
contrasted with simple box-carring, where messages will simply be
aggregated in the top wrapper:
<btp:messages 6)
Side-notes to 5): a) I
believe there is a case for using the upper-case notation for the names of the
message elements, as shown in my pseudo-code, to match the convention of the
spec. I think I may have raised this in private discussion with Bowstreet, but
it has not been discussed at all in the committee, so I raise it now. b) I
believe that Savas wanted to schematize the above as an inheritance hierarchy
where all specific message schemata derived from a base message
schema, where any message could be contained within any message.
The actual permitted containments (like CONTEXT within BEGUN) would be
constrained by the specialized schemata. If I understand this approach aright,
the outermost wrapper that I have proposed be called btp:messages
becomes a specialization of btp:message which allows any btp:message
to be contained; whereas other specializations are very choosy about which
parasites they will host. Can I request that you liaise with Savas on these
issues and let us know the outcome? c) I
believe we have no known need to put btp:messages inside
btp:messages,
but equally have no particular reason to prevent it. I have no strong feelings
about this, and I don't believe the issue has been discussed other than by Alex
and myself at some point. 7) The
abstract message READY has been renamed PREPARED on grounds of consistency
(everything else is imperative/past participle, so this one is now the same). 8) The
spec is written in British English (perhaps that should be Hiberno-British
English, or North Atlantic Archipelago English or These-Isles English), hence
ENROL and ENROLLED which are the first readings given by the Shorter Oxford
Dictionary. Enrolment is the noun, as used in the text, doesn't affect the
message content. I hope
I've captured the issues list here. Yours, Alastair |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC