[bt-spec] Issue 78: revised solution

[Peter Furniss <peter.furniss@choreology.com>]

At the conference call, some changes were suggested to the proposed solution
to 78. I applied these to the proposed solution on the issues list, but in
doing wondered if it could be made a bit clearer.  It also might benefit
from distinguishing the "executive summary" in the first two sentences. And
the changes actually made in 0.9.1.1 did not exactly correspond to the
proposed change.


I've shortened the note in the xml section, and . It is possible that in
revising this, intending only to clarify what we meant in the first place,
I've made it less acceptable to Mark and Jim. No doubt something can be
sorted out if this is the case.

Proposed solution (revised):

Summary:
Make Identifier globally unambiguous, rather only unambiguous within the
scope of the related addresses. Syntactically make it a URI.

Drop the disambiguating addresses from messages, and modify the text for the
corresponding identifier

In abstract messages and the XML for the messages:

Change the text introducing the identifiers in the abstract messages (i.e.
in CONTEXT, ENROL, BEGUN) to state that they are globally unambiguous (for
all other messages, identifiers are defined by reference to one of these
three)

CONTEXT_REPLY - delete superior-address

STATUS - delete responders-address.

RESIGN, PREPARED, CANCELLED, CONFIRMED, HAZARD, INFERIOR_STATE - delete
address-as-inferior

REDIRECT will need changing but details can be handled under issue 29 :
Redirection

BEGUN will need changing but details is can be handled under issue 30 :
Assume that coordinators are potential sub-coordinators.

TRANSACTION_CONFIRMED, TRANSACTION_CANCELLED - delete address-as-decider

INFERIOR_STATUSES - delete responders-address

Change the section Identifiers in the XML section

Identifiers shall be globally unambiguous

Note - Apart from their generation, the only operation the BTP
implementations have to perform on identifiers is to match them.


In the section on abstract messages, addresses (line 1051 in 0.9.1) delete
the sentence "In cases b) and c), the identifier is to some extent
redundant, although interoperation requires that it always be present."
Replace the text on Identifiers in the XML section and move it to the
beginning of the abstract message section. New text to be:

Identifiers shall be URIs

Note –  Identifiers need to be globally unambiguous. Apart from their
generation, the only operation the BTP implementations are required to
perform on identifiers is to match them.


In the model, state the identifier : address relation. In summary (may be
modified to fit in the rest of the model, e.g. avoiding forward reference of
particular terms):


An Identifier is a globally unambiguous identification of the state
corresponding to one of Decider, Superior or Inferior. Where a single actor
has more than one of these roles (at the same node in the same transaction),
the Identifiers may be the same or different, at implementation option -
they are distinguished by which messages the Identifier is used on. (A
Superior has only one superior-identifier, although it may be in multiple
Superior:Inferior relationships, each with a separate state in terms of the
state table).

The state identified by an Identifier can be accessed by BTP messages sent
to any of the addresses supplied with the Identifier in the appropriate
message (CONTEXT, BEGUN, ENROL), or as updated by REDIRECT. An Identifier
itself has no location implications. (Identifiers are specified, in the XML
representation, as syntactically URIs - by the use as names of BTP entities,
they are URNs. If an Identifier happens to specify an network location (i.e.
it is a URL) it is treated as an opaque value by BTP)

Identifiers are specified as being globally unambiguous - the same
Identifier only ever identifies one Decider, Superior or Inferior over all
systems and all time. In practice, an Identifier could be re-used if there
is no possibility of the colliding values being confused. However
implementations are recommended to use truly unambiguous Identifiers (that
is to use them as URNs).




Peter

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