[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 058 - definition of Referencing Specification
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]