[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 058 - definition of Referencing Specification
Don't get me wrong: I think the discussion has been useful, but it's now moving into the area of diminishing returns. Hence the request for a vote. I think there are 3 (maybe 4) options: (i) my text, (ii) your text, (iii) Ram's text, (iv) no statement. Mark. Alastair Green wrote: > Well, I think the discussion has been useful, but it's not that > important which way it falls. I've certainly said all I want to say, > and would be very happy to see a vote after any further contributions > from others. > > Alastair > > Mark Little wrote: >> 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]