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.
|