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

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

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


Subject: btp conference call - messaging issues


The following issues were reviewed (after discussion by an ad-hoc subgroup
previously) and agreed nem.con. by the quorate BTP conference call 27
September.

This summary has not been reviewed !

1. Format of document

Need to make an editable version available to oasis and our successors.
Pdf as publication format; and editable version word given to karl best
and/or made available to the c’ttee.

( 2. updating schema.  pending input from PRF and Alex Ceponkus )

3. msgs in/out scope.   Covered by conformance subset definitions.
Implementations can say which interfaces they implement in the standard
interoperable way, leaving it open for them to do other interfaces their own
way.

4. msg names: lower-case.

5. use of soap faults (for btp-detected problems).    SOAP specifiers leave
decision on how to use to us – they do not mandate either way.    Premise :
only use soap faults for errors in soap, btp for errors in btp.  Recognised
that some things (eg bad XML) might be detected at soap or btp level, in
which case the detector reports using their mechanisms.  SOAP-detected
faults will not cause transmission of btp-defined msgs.  (Consider also case
of BTP/not-SOAP, where the same error would be (possibly) btp detected)

Abstract msg/procedures need to state that lower-layer faults must be dealt
with in similar way to btp faults.  Since not all abs. msgs need have a real
(xml) encoding in a binding, it would be appropriate to define an abstract
fault of “Communication fault”.

5a. Need for binding proforma as an element of the spec. With our example
complete bindings being soap; soap+attachments.

6. binding names.  Though the names may be readable by humans, they don’t
have any required structure – string-matching of the whole is sufficient.
e.g. urn:oasis:names:tc:btp:bindings:soap-http-7

is the urn:...:bindings part necessary ?  Could it just be soap-http-7, cos’
we know this must be the binding string.

But, proprietary binding names must be uri’s to avoid collisions.
Standardised ones will be simple strings (with no : )

7. identifiers – hex digits.
Don’t want to go for the whole Unicode bundle. Ascii would be cultural
imperialism.

Will be hedgits.

8. Superior type marker – attribute with string value.

9. ready-received now called prepared-received

10. msg relationship by containment:
   all the phones from 13 Austin Friars disconnected at this point so I'm
not sure what was said.



Peter

------------------------------------------
Peter Furniss
Technical Director, Choreology Ltd
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: 07951 536168
13 Austin Friars, London EC2N 2JX





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


Powered by eList eXpress LLC