[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 058 - definition of Referencing Specification
|
Mark, Ram, Peter: When lawyers know that a strict natural language interpretation will cause head-scratching, they use the wonderful phrase "for the avoidance of doubt ..." to preface the negative or positive example that helps to nail it all down. In this case, I'm not sure there is really that much room for doubt, if we keep it very simple or indeed avoid any formal definition. The use of the term "referencing specification" occurs in one place, as I understand it, and concerns the need for an RS to specify the rules for WS-Coordination fault message formulation and delivery with respect to WS-Addressing, if it borrows the fault messages from WS-Coordination. (Going without the minutes -- no criticism of Paul K. intended, you really do a fantastic job -- so I'm not quite sure if that was the outcome.) Given that one-time use and context, I think that relying on the natural language meaning of "referencing specification" (no definition) would be fine. It would also be fine to use the anodyne first sentence of Mark's original proposal. Saying more may take us into the dread territory of conformance, and I think I share some of Ram's unease. * * * I went back to Mark's original text to look again at the detail, as he requested us to do in a post earlier today, and here are my comments: "One or more other specifications, such as (but not limited to) WS-AtomicTransaction may reference the WS-Coordination specification." I think this a statement of the obvious. All specifications create facilities which will have a client, a using application, and it will always have a specification. The spec already talks about extensibility etc. But the sentence is harmless. "Referencing Specifications are generally used to construct concrete protocols based on WS-Coordination." If "concrete" said "coordination" then the sentence would be clearer. But removing the sentence would remove any suspicion that we intend to restrict the use of WS-Coordination in any way. It would be safer to remove it: examples often cause trouble (they tend to induce normative inferences). "The usage of optional items in WS-Coordination, or those protocol aspects where terms such as MAY or SHOULD are used, may be further restricted by the requirements of a Referencing Specification." This sentence bothers me. Saying "X and Y may be further restricted" can create the implication "Only X and Y can be restricted". Why call it out, otherwise? But a referencing specification might decide to use or cite only a part of WS-Coordination, and might endow that part with restricted (or extended) behaviours, even if WS-Coordination deems the part concerned to be "required" for general conformance (in reality, to be required because the feature is needed for AT and BA). For example, let's posit a protocol called WS-BusinessIdentity (WS-BID). It decides to use CreateCoordinationContext to get an XML-ised identity from a Coordination Service that is acting as an identity service, handing out tokens that unambiguously identify business process instances, or some such. It decides that in some cases the resulting CoordinationContext will be used simply to distribute the UUID to non-transactional parties, and that in other cases it will be used to register those parties for e.g. a WS-BA protocol. In a particular application WS-BID is used just to distribute the UUID: that's OK because WS-BID is divided into two conformance levels: Simple and Transactional, and we only need WS-BID Simple to do this application. WS-BID Simple does the following: it makes mandatory the use of an optional feature of WS-Coordination (CCC/CCCR exchange). It forbids the use of a required feature of WS-Coordination (R/RR). It uses the CoordinationContext, and ignores a required element (/RegistrationService). This is a real use case, incidentally. Even if we attempt to prohibit the use of WS-Coordination in this way, we will never succeed, because the referencing spec can introduce its own rules, and take our components, and we can never be the wiser. "For the purpose of this document, the term Referencing Specification covers both formal specifications and more general applications that use WS-Coordination." I agree with the intended meaning, but the wording falsely counterposes "formal specs" to "more general applications". I think this is another case where saying more is creating questions that don't need to be aired. * * * I previously suggested the following text, which I think doesn't suffer from the problems I see in Mark's original draft, and scoops up all the points he wants to make (I believe): "A referencing specification is a coordination protocol or other specification which uses some or all WS-Coordination features, and which may restrict or extend them for its own purposes. Examples include WS-AtomicTransaction and WS-BusinessActivity." And, going back to square one, I could live without any definition at all (just reliance on natural language meaning of the RS term), given the actual use at present. (Bit like XP: don't factor out the base class till you've got the second use case). Alastair Ram Jeyaraman wrote: The goal is not to prevent implementations or specifications from going beyond the boundaries of the WS-Coordination specification; they are free to, but at *their* own risk. It is just that we don't want to provide a specific guidance, until we know for sure what those specific usages are. This way the implementations cannot hold us responsible, if we chose to require the optional parts in a future revision. Really, it just boils down to the fact that we don't have enough data yet, to provide a specific guidance. Thanks. -----Original Message----- From: Peter Furniss [mailto:peter.furniss@erebor.co.uk] Sent: Monday, May 08, 2006 3:19 PM To: Ram Jeyaraman; Mark Little Cc: ws-tx@lists.oasis-open.org Subject: RE: [ws-tx] Issue 058 - definition of Referencing Specification Ok, now I understand what you were concerned about. But surely if one of our specifications makes something optional it is because our protocol will work with or without the feature (albeit with some kind of variation in detail presumably). And somewhere in the sequence: base-spec -> referencing spec -> product -> configuration options -> real instance of one transaction, that optionality will get resolved to does or doesn't do it. What would it mean to say that some feature must be optional down implementation level ? [ that's assuming right use of the MAY/MUST terms - commonly, a feature that MAY be used on sending, MUST be accepted on receiving for interoperability ] And silence won't prevent what you are concerned about. In the absence of a statement, a referencing specification is apparently permitted to make a ws-tx optional into MUST/MUST NOT. The point is not that silence is really confusing (because whatever is not prohibited, is permissible), but that it may be assumed to be confusing. Probably making more of this than its worth. Peter -----Original Message----- From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com] Sent: 08 May 2006 20:44 To: Peter Furniss; Mark Little Cc: ws-tx@lists.oasis-open.org Subject: RE: [ws-tx] Issue 058 - definition of Referencing Specification Peter, I am just concerned that it will be hard for us to retract, if we discover later that we do not intend other specifications to restrict or limit the optional items. We just don't have enough data at this point to make a definitive statement; so it is best not to provide a specific guidance. Thanks. -----Original Message----- From: Peter Furniss [mailto:peter.furniss@erebor.co.uk] Sent: Monday, May 08, 2006 12:14 PM To: Ram Jeyaraman; Mark Little Cc: ws-tx@lists.oasis-open.org Subject: RE: [ws-tx] Issue 058 - definition of Referencing Specification Ram, You seem to be reading the text in the opposite way to the way I, and I perceive, Mark and Alastair read it. The longer texts are all intending to maximise the potential set of RS. You seem to be reading it as imposing bounds. The risk is that, in the absence of a clear statement that there are no limits to an RS, some other statement in the spec (perhaps intended by the authors to illustrative) is taken as implying a limit. Peter -----Original Message----- From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com] Sent: 08 May 2006 19:21 To: Mark Little Cc: Peter Furniss; ws-tx@lists.oasis-open.org Subject: RE: [ws-tx] Issue 058 - definition of Referencing Specification Mark, When implementations go over and beyond the specification requirements, they carry a risk, and they should know it. They cannot come back and say "The specification said such and so". On the other hand, yes, specifications make general statements to set expectations; to provide future guidance. For example, a specification may generally describe how to handle a specific situation, and later on, in a future version, require the described behavior. But this is well intended and directed by the specification towards a specific outcome, and implementations follow it, even though it may not be a requirement. In this case, if the specification reverses the guidance in a future version, then implementers can always come back and say "Well, you lead me in that direction; why are you changing the specification now?" It becomes really hard for the specification to make changes. At this time, we do not know about other specifications (potentially in other standards bodies) that may compose with WS-Coordination; and we do not have enough data at this point to provide a concrete guidance. So, it is better not to say anything, until a time, we have more data on other compositions. So, I suggest we provide a definition for the term Referencing specification, as you proposed earlier: "Referencing Specification One or more other specifications, such as, but not limited to, WS-AtomicTransaction, that may reference the WS-Coordination specification." Later, when we have more data about other compositions, we can discuss about providing specific guidance in the specification. Thank you. -----Original Message----- From: Mark Little [mailto:mark.little@jboss.com] Sent: Saturday, May 06, 2006 1:41 AM To: Ram Jeyaraman Cc: Peter Furniss; ws-tx@lists.oasis-open.org Subject: Re: [ws-tx] Issue 058 - definition of Referencing Specification In the same way that saying nothing about something can be read by different vendors in different ways to imply conformance. This is a age-old "feature" of standards. You should know that from having worked on the JTA ;-) Basically: if you don't say anything then everybody can interpret the lack of information in their own manner and there is no way to prove the original intent of the authors. Mark. Ram Jeyaraman wrote: |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]