W3C home > Mailing lists > Public > public-ws-chor@w3.org > November 2004

RFC 2119 terminology (was RE: Choreography lifeline Proposal (was RE: Proposal: To remove the initiate flag on the Interation))

From: Furniss, Peter <Peter.Furniss@choreology.com>
Date: Tue, 16 Nov 2004 10:26:52 -0000
Message-ID: <221369570DEDF346AE42821041345E897D3ADC@imap.choreology.com>
To: "Nickolas Kavantzas" <nickolas.kavantzas@oracle.com>, "Gary Brown" <gary@enigmatec.net>, <public-ws-chor@w3.org>
I'm going to have some comments on the specifics of Nicks text but it
has triggered a concern I've had for 
a while.
 
The RFC 2119 keywords - MUST, MAY, MUST NOT etc. were originally used
for, and are very
appropriate for describing the requirements of an implementation of a
protocol. They are not
always quite so useful when describing the requirements of a more
declarative language, such as 
CDL (and various other cases). 
 
 
It's quite straightforward to say "the sender MAY include a
reply-address. If a message with
a reply-address is received any response from the responder MUST be sent
to that address" Those are permissions
and constraints on the behaviour of real systems and programs.
Implementations that disobey the 
MUST or do not allow for the peer's MAY will not generally interoperate
and are not conformant.
 
But for CDL, the target isn't an implementation with active behaviour,
but a document that defines
the required and acceptable behaviour of systems. So MUST means "a
document without this
is not valid" and MAY means "a document with or without this is valid".
(And there are then implications
for an implementation that consumes CDL documents for some purpose).
But the MUST, MAY
terminology can be a bit misleading for CDL.
 
It's clear in some cases with CDL - from Nick's text "Two or more
Interactions MAY be marked as Choreography 
initiators, indicating alternatives ..." - A <choreography /> that
contained more than one interaction marked
as initiator would be valid. (actually 
 
But "Initially, the collaboration MUST be established between parties, 
then work MAY be performed within it and finally it MAY complete. " is
much less clear. Especially, that
sounds like a dynamic constraint on the behaviour, but I think it's just
descriptive, and could be expressed as
simple definition
 
A collaboration
    - is initially established
    - then may perform work
    - finally may complete
 
That uses MAY, but not really in the sense of 2119.  RFC 2119 text on
MAY is all about one implementation 
choosing to do it, another not. But here we are talking about the
characteristics of a collaboration, which if it doesn't
meet the the definition is not invalid, but is just not the kind of
collaboration we are talking about.
 
Although this has been triggered by the lifeline text, it's more a
general matter. I'd suggest that the
editors use the rfc 2119 words with caution especially when dealing with
the description of what something
is, rather than what it must do.
 
 
Peter
 
 
-----Original Message-----
From: Nickolas Kavantzas [mailto:nickolas.kavantzas@oracle.com] 
Sent: 15 November 2004 21:44
To: Furniss, Peter; Gary Brown; public-ws-chor@w3.org
Subject: Choreography lifeline Proposal (was RE: Proposal: To remove the
initiate flag on the Interation)




As I've promised here is the updated proposal/text for the Choreography
Life-line Section:
 
 
***Updated Life Line Completion Proposal***
 
New Choreography Life-line Section Text
 
A Choreography life-line expresses the progression of a collaboration 
through enabled activities and enclosed performed Choreographies.
 
Initially, the collaboration MUST be established between parties, 
then work MAY be performed within it and finally it MAY complete. 
 
A Choreography is initiated, establishing a collaboration when an  
Interaction, explicitly marked as an Choreography initiator, is 
performed. Before this point there is no observable association between 
any of the parties. Two or more Interactions MAY be marked as
Choreography 
initiators, indicating alternatives for establishing a collaboration. In

this case, the first performed interaction will establish the
collaboration 
and the other interactions will enlist with the already established 
collaboration. An initiating interaction MAY be defined within a root 
Choreography or within either a Locally or a Globally defined enclosed 
Choreography. In either case the collaboration is established when the 
initiating interaction is performed.
 
A Choreography completes successfully when there are no more enabled 
activities within it. Alternatively, a Choreography completes
successfully 
if its complete condition, as defined by the optional complete attribute

within the choreography element, is matched by evaluating to "true". 
A complete condition is considered for matching while the Choreography
is 
enabled. The complete condition MUST BE matched in all Roles that
participate
in the Choreography. Once the complete condition of a a Choreography is
matched 
then all activities in the Choreography are disabled, and the
Choreography 
completes as if there were no more enabled activities within it. A
Choreography 
complete condition is an implied complete condition for each enclosed
Choreography
and the semantics are as if the complete condition was defined in each
enclosed 
Choreography. Hence, each enclosed Choreography completes successfully.

 


 
--
Nick

----- Original Message ----- 
From: Furniss, Peter <mailto:Peter.Furniss@choreology.com>  
To: Nickolas Kavantzas <mailto:nickolas.kavantzas@oracle.com>  ; Gary
Brown <mailto:gary@enigmatec.net>  ; public-ws-chor@w3.org 
Sent: Tuesday, October 26, 2004 2:10 PM
Subject: Choreography lifeline( was RE: Proposal: To remove the initiate
flag on the Interation)

Nick proposed:


*Choreography Life-line*
A Choreography life-line expresses the progression of a collaboration
through 
enabled activities and enclosed performed Choreographies.
 
Initially, the collaboration MUST be established between parties, then
work MAY be
performed within it and finally it MAY complete. 
 
A Choreography is initiated, establishing a collaboration when an  
Interaction, explicitly marked as an Choreography initiator, is
performed. 
Before this point there is no observable association between any of the
parties. 
Two or more Interactions MAY be marked as Choreography initiators,
indicating 
alternatives for establishing a collaboration. In this case, the first
performed 
interaction will establish the collaboration and the other interactions
will enlist
with the already established collaboration. 
An initiating interaction MAY be defined within a root Choreography or
within either
a Locally or a Globally defined enlosed Choreography. In either case the
collaboration is 
established when the initiating intaraction is performed.
 
A Choreography completes successfully when there are no more matched
Work
Unit(s) performing work within it and there are no enabled Work Unit(s)
within it. Alternatively, a Choreography completes successfully if its
complete condition, as defined by the optional complete attribute within
the
choreography element, evaluates to "true". In this case, the actions,
including enclosed Choreographies, within the explicitly completed
Choreography are completed abnormally before the Choreography completes.

 
<PRF>
I think we may need to be more explicit on what "actions .. are
completed abnormally" means ?
 
In the collision example, the losing interaction will be represented by
a message that is
winging its way to the supplier, who reached PO-State=completed when he
sent the completion
message and now thinks the choreography is over. That losing interaction
is apparently 
invalid. Endpoint projections will need to recognise that they should
silently ignore the
message if and when it does arrive. (and, in general, it will be very
difficult to work out
where things have progressed to - if the place-order choreography was
performed as an
element of a larger, the supplier may be well into the order-delivery
stage (another sub-choreography)
before the now-irrelevant cancel turns up.
 
What happens if other actions are juggling with variables - do they stop
dead ? In fact,
such a choreography is possibly ill-formed - it should (like Nick's
example) set its
variables consistently at the end. (coordination will help you )
 
Actually, "abnormally" isn't really right anyway - we certainly don't
want them throwing
exceptions etc.
 
Also the Life-line section needs to say something about a choreography's
"life after death" - or rather
finalization after completion, and perhaps briefly, exceptions. That
relates to the coordination 
stuff that Bob is drafting, so this is just a placeholder comment.
 
 
Peter

Choreology Anti virus scan completed

Choreology Anti virus scan completed
Received on Tuesday, 16 November 2004 10:28:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:01:11 GMT