[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 058 - definition of Referencing Specification
Alastair, comments in line. Alastair Green wrote: > 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.) It occurs in one place at present, but I think it could be used elsewhere once defined. > > 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). Isn't that a little tautological: it's fairly obvious that WS-Coordination is about coordination ;-) However, it is not so obvious that WS-Coordination cannot be used stand-alone, i.e., it is not a concrete definition of a coordination protocol. > > *"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). So you're saying that we should allow mandatory elements in WS-Coordination to be relaxed by referencing specifications? That makes it difficult to say something is conformant with WS-Coordination for a start, and if not used with care could break a lot of other parts in the specification. If we mandate some element in WS-Coordination then I'd like to think it's for a good reason. If someone doesn't want that mandatory element to be mandatory, then they probably shouldn't be using WS-Coordination. > > 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 don't have anything more to add that I haven't already. > > * * * > > 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." > / So I don't like this for the following reason: "/ which may restrict or extend them for its own purposes/" implies that rules within WS-Coordination can be broken by referencing specifications. Going back to what I said above: if we set a mandatory element, it should remain mandatory. Maybe that's not what you meant by this statement? > / > /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). I think that's too loose an argument. In general, I'd prefer to see a statement that captures the essence of the current proposal. I'm not tied to any specific wording: it's the principle behind the text that is more important. Mark. > > 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: >> >>>> Precisely because we do not know what the RS will be or want to do, >>>> >>>> >>> and we wish to make sure that restrictions are not implied by our >>> silence. >>> >>> How does silence imply restrictions? >>> >>> -----Original Message----- >>> From: Peter Furniss [mailto:peter.furniss@erebor.co.uk] >>> Sent: Friday, May 05, 2006 2:44 PM >>> To: Ram Jeyaraman; Mark Little >>> Cc: ws-tx@lists.oasis-open.org >>> Subject: RE: [ws-tx] Issue 058 - definition of Referencing >>> >> Specification >> >>> Ram asks: >>> >>> "Why should a specification make such a general statement?" >>> >>> Precisely because we do not know what the RS will be or want to do, >>> >> and >> >>> we wish to make sure that restrictions are not implied by our silence. >>> For example, to make sure the following statements are invalid: >>> >>> - WS-C can only be used for transaction protocols >>> >>> - If <x> is optional in WS-C, an RS cannot forbid <x> when WS-C >>> >> is >> >>> used with the RS >>> >>> - If <x> is optional in WS-C, an RS cannot require <x> when WS-C >>> >> is >> >>> used with the RS >>> >>> - This protocol A cannot legitimately use WS-C because the >>> specification of A is proprietary and unpublished >>> >>> - This end-user application cannot use WS-C because what is >>> >> added to >> >>> WS-C is only defined in some of the comments in the code >>> >>> Of course, if we are sure no-one would be so daft as to make any of >>> those statements, then we don't need to have the longer RS definition. >>> But some remarkably daft statements are sometimes made about standards >>> >> >> >>> and having chapter and verse to contradict them can be useful. >>> >>> Peter >>> >>> >>> -----Original Message----- >>> From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com] >>> Sent: 05 May 2006 19:21 >>> To: Mark Little >>> Cc: ws-tx@lists.oasis-open.org >>> Subject: RE: [ws-tx] Issue 058 - definition of Referencing >>> >> Specification >> >>> We really do not know at this point, how this affects other >>> specifications and implementations, and what the implications are. >>> >>> Why should a specification make such a general statement? >>> >>> -----Original Message----- >>> From: Mark Little [mailto:mark.little@jboss.com] >>> Sent: Friday, May 05, 2006 3:27 AM >>> To: Ram Jeyaraman >>> Cc: ws-tx@lists.oasis-open.org >>> Subject: Re: [ws-tx] Issue 058 - definition of Referencing >>> >> Specification >> >>> I disagree. In fact, how much more general a definition can you get >>> >> ;-)? >> >>> Mark. >>> >>> >>> Ram Jeyaraman wrote: >>> >>> >>>> It is hard to anticipate how other specifications from other >>>> >> standards >> >>>> >>>> >>> >>> >>>> bodies that may refer to the WS-Coordination specification are >>>> >> defined >> >>>> >>>> >>> >>> >>>> and used. Further, the current WS-Coordination specification does not >>>> >> >> >>>> preclude the possibility of referencing specifications restricting >>>> >> the >> >>>> >>>> >>> >>> >>>> optional behavior described in the WS-Coordination specification. >>>> >>>> So, it is probably best not to make a statement about Referencing >>>> specifications. >>>> >>>> -----Original Message----- >>>> From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com] >>>> Sent: Thursday, May 04, 2006 1:52 PM >>>> To: ws-tx@lists.oasis-open.org >>>> Subject: [ws-tx] Issue 058 - definition of Referencing Specification >>>> >>>> This is identified as WS-TX issue 058. >>>> >>>> Please ensure follow-ups have a subject line starting "Issue 058 - >>>> definition of Referencing Specification". >>>> >>>> -----Original Message----- >>>> From: Mark Little [mailto:mark.little@jboss.com] >>>> Sent: Thursday, May 04, 2006 9:21 AM >>>> To: ws-tx@lists.oasis-open.org >>>> Subject: [ws-tx] NEW issue: definition of Referencing Specification >>>> >>>> NOTE: Please defer discussions on this issue until a time this issue >>>> >>>> >>> is >>> >>> >>>> accepted and is assigned a number by the TC. >>>> >>>> Reference documents: >>>> >>>> >>>> >>>> >> http://www.oasis-open.org/apps/org/workgroup/ws-tx/download.php/17311/ws >> >>> >>> >>>> tx-wscoor-1.1-spec-cd-01.pdf >>>> >>>> with amendment from issue 030 >>>> >>>> Description: >>>> >>>> Text within WS-C refers to Referencing Specification. We have no >>>> >>>> >>> formal >>> >>> >>>> definition of that. >>>> >>>> Resolution: >>>> >>>> One or more other specifications, such as (but not limited to) >>>> WS-AtomicTransaction may reference the WS-Coordination specification. >>>> Referencing Specifications are generally used to construct concrete >>>> protocols based on WS-Coordination. 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. For the purpose of this document, the >>>> >> term >> >>>> >>>> >>> >>> >>>> Referencing Specification covers both formal specifications and more >>>> general applications that use WS-Coordination. >>>> >>>> Mark. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]