[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 058 - definition of Referencing Specification
I don't think we're actually going to get anywhere with this discussion, so why don't we just vote? I'd rather not end up in another 030 issue debate, particularly over this. Mark. Alastair Green wrote: > Hi Mark, > > That's what I feared -- we are off into a conformance discussion. :-) > > That's why silence might be a good policy, given that the term is used > once in a context where its meaning is pretty clear. There is a strong > case for stopping right there, and relying on the English language to > explain the meaning, aka "resolve with no change". > > I think the most sensible kind of conformance statement you can make > about interop protocols is: this implementation supports these roles. > E.g. Registration Service, Coordination Service for creation of > contexts, Coordinator for Participant registration, Registrant of > Participants, etc. If it doesn't support a role, you know it won't > work if you approach it in the counterpart role. In practice people > say things like: my product implements the whole spec, or it doesn't > support CCC/CCCR processing, and the like. > > The question of /valid use/ is different. I can have an implementation > that supports everything, but never use the CCC/CCCR feature. If I > don't give you a WKEP for that facility, you can't use it, and if I > do, then you may choose not to use it. > > So, in my example WS-BID, I can probably build that by choosing to use > an implementation that implements everything, but only choosing to use > some of its features, sometimes. I presume, for example, that I could > build an application called: "Alastair's Business Identity Service" on > top of JBoss WS-Coordination, exactly as I described: you would have a > wholly conformant implementation, and my application would be a > "general application" referencing specification in the sense you mean > it. Restriction would come because I chose not to ask you to ever > perform certain roles, and chose to ignore certain present elements in > message documents, and extension would come because you'd correctly > support the extension points and give me an API or the raw XML > manipulation access to permit me to use them. If we called the spec of > such a service WS-BID, and got it standardized it would be a formal > spec in the sense you mean. All the kind of thing I think you have in > mind (and which we should permit, or rather, not ban). > > The trouble is, it's very difficult to capture every nuance of how > this may work out in a general statement (which I think is part of > Ram's point), so, although I prefer my draft to your draft, I actually > prefer silence to both. > > Alastair > > > > Mark Little wrote: >> 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]