[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [bt-spec] Issue 78: revised solution
Peter, What you've done improves things more than my simple change. It makes me wonder, though, why are we talking about URI values at all? Wouldn't the text be simpler throughout the specification if it discussed names rather than identifiers and URN's rather than URI's? I haven't resorted to looking up the proper RFC documents. I might be ignoring something major like http: or uuid: not being valid URN schemes. If we go with the lesser change you've proposed, I have a couple of minor corrections: (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 ^ir specify an network location (i.e. it is a URL) it is treated as an opaque value by ^, BTP) ^. <snip /> is to use them as URNs). ^, thanx, doug ----- Original Message ----- From: "Peter Furniss" <peter.furniss@choreology.com> To: "BT - spec" <bt-spec@lists.oasis-open.org> Sent: Saturday, February 02, 2002 6:17 PM Subject: [bt-spec] Issue 78: revised solution 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 ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC