This file last updated 13:33 15 Sep 2003 (UTC)
This list covers real and perceived errors and omissions in the Business Transaction Protocol Committee Specification 1.0, as distinct from suggested additions and enhancements (which go in the extensions list).
Members of the committee should comment on these issues by sending to the bt main list, with a subject line that begins "Issue - <issueid> - " (e.g. "Issue - maint-4 - ") or is a reply to such a message. (The script that finds and links relevant emails from the archive looks for this string, after discarding Re: etc.). Members of the committee can submit new issues by sending to the issues list maintainer, Peter Furniss, Choreology, who will assign a number, add an entry and announce the issue on the bt main list.
The list is uploaded to the OASIS BTP TC pages on a regular basis, if there have been changes, and will be the most recent document titled btp_maintenance_issues_list.html in the "Issues" folder in the BTP TC document list. Since the uri of an uploaded document includes the document number assigned in the upload process, the uri for the current official TC document version is unpredictable. However, the editor's working copy of the list is also maintained on this constant url - at times of rapid change, this may be more up-to-date.
Issue numbers are maint-1, maint-2 etc to distinguish them from the original, pre-1.0 issues, and the extensions issues (ex-1, ex-2 etc). (The extensions list will be the most recent Issues document with the title "btp_extra_issues_list.html" - again the editor's working copy has a constant uri.)
| IssueID | Title | Status | Date added | Last changed |
|---|---|---|---|---|
| Issue maint-1 | HAZARD after receiving CANCEL | new | 17 Oct 2002 | |
| Issue maint-2 | CONFIRMED element should be confirm-received | new | 17 Oct 2002 | |
| Issue maint-3 | CONFIRM_ONE_PHASE against autonomous confirm | new | 17 Oct 2002 | |
| Issue maint-4 | reply to cancel_inferiors | open | 16 Jul 2003 | 16 Jul 2003 |
| Issue maint-5 | Superior identifier needed before sending INFERIOR_STATE/unknown | open | 16 Jul 2003 | 16 Jul 2003 |
| Issue maint-6 | "confirming" status should include auto-confirming | open | 16 Jul 2003 | 16 Jul 2003 |
| Issue maint-7 | Differences between xml schema and informal message description | open | 16 Jul 2003 | 16 Jul 2003 |
| Issue maint-8 | Allow late enrollments | open | 16 Jul 2003 | 16 Jul 2003 |
| Issue maint-9 | Qualifiers for each inferior on CONFIRM_TRANSACTION | open | 16 Jul 2003 | 16 Jul 2003 |
Status category is shown in headers :
green=closed, one way or another,
teal=deferred (closed for 1.0 - transferred to extensions and additions list),
maroon=solution proposed,
fuchsia=voting,
orange=depends on another issue,
red=new, open
The error occurs in both the schema and specification (section 10.2.13, line 3700)
Original reports: Mark Potts, 9 Jul 2002 Alex Ceponkus, 10 Jul 2002
Target document:
Committee Specification 1.0 (3 June 2002)
and
Core schema (3 June 2002)
Links: Announcement, 17 Oct 2002
Changes:
This imposes restrictions on an implementation, as it may be difficult to avoid the messages crossing inside
the superior communications mechanisms.
Suggested solution:
Allow a transition to S1 in the decide to confirm one-phase / H1 cell.
Target document: Committee Specification 1.0 (3 June 2002)
Links: Announcement, 17 Oct 2002
Changes:
The problem is that the INFERIOR_STATE/unknown needs to carry the superior identifier so the message will get delivered to the approriate state machine. But the superior identifier is not on the PREPARE (the superior address is, at least logically). The inferior has no record of what superior was involved with the deceased inferior node.
The only right answer would seem to be to add the superior identifier as a parameter to the superior to inferior messages that can get a reply of INFERIOR_STATE/unknown (PREPARE, CONFIRM, CANCEL, CONFIRM_ONE_PHASE).
Bad alternative:
drop the superior identifier in the INFERIOR_STATE/unknown case. The message will get back to the sending system, but it has no easy way of knowing which of its superiors this involves. This special case would require the superior system to keep an inferior:superior lookup for all inferiors it was involved with. (and if made general, would mean we didn't need the superior id on any of the up tree messages.
Changes: 16 Jul 2003 - new issue
Response requested is not mandatory (minOccurs=0 and specified default) for enrol/resign/inferior-state/superior-state in the xml schema but there is no indication that they are optional in the informal message set.
decider, inferior address and transaction identifier is not mandatory for begun in the xml schema but not in the informal message set.
In the xml schema "fault" doesn’t contain a fault text.
Changes: 16 Jul 2003 - new issue
Allowing late enrollment makes it possible to have a first, enrolled inferior (A) that hands over its work to another inferior (B) when A receives PREPARE. B is enrolled (and typically would spontaneously prepare), and then A either sends PREPARED or RESIGN. Sending RESIGN makes the behaviour essentially equivalent to the pre-completion synchronization behaviour of other protocols, but without requiring a separate kind of enrollment or knowledge by the superior of what is going on.
The changes needed in the spec would be to allow "use" of a CONTEXT for new enrollments after a CONTEXT-REPLY(completed) has been sent.
Changes: 16 Jul 2003 - new issue
Controlling this via CONFIRM_TRANSACTION requires some way of passing qualifiers and identifying which inferiors they are to be sent to. This could be done by changing the inferiors-list, or having a separte list of qualifiers-for-inferiors. If the former is done, it will be necessary to allow inferiors-list to be present even for an atom.
Changes: 16 Jul 2003 - new issue
This file last updated 13:33 15 Sep 2003 (UTC)