Re: EDITORIAL CHANGES FOR ISSUE 1008 - Fault Handling

Hi Gary,

Can you also send the updated ixn syntax and the updated ixn example from the  
section 2.5.2.3?

Also, a WSDL 1.1 snippet associated with this example would be useful for
illustrating the connection between CDL and WSDL, regarding the faults.


Thanks,

--
Nick

  ----- Original Message ----- 
  From: Gary Brown 
  To: 'WS-Choreography List' 
  Sent: Thursday, May 19, 2005 4:28 AM
  Subject: EDITORIAL CHANGES FOR ISSUE 1008 - Fault Handling


  SUMMARY OF CHANGES:

  1) Added faultName attribute to the Interaction's exchange element, to enable faults to be distinguished, whether WSDL1.1 or WSDL2 - this means that the associated informationType on the exchange now represents the underlying information type of the fault payload

  2) Removed the 'exceptionType' attribute from the InformationType, as there is no need to identify exceptions as a particular special type

  3) Changed the exception throwing mechanism to allow choreography specific exception names (labels) to be used in the 'causeException' attributes and subsequently matched within the 'hasExceptionOccurred' function in the ExceptionWorkUnit

  RESULT:

  1) Ability to differentiate between WSDL1.1 faults, on the same operation, when of the same type

  2) Reduction in number of unnecessary information type declarations

  3) Ability to use choreography specific exception labels - not just constrained to raising exceptions associated with external declared types

  4) No change in CDL semantics

  ===========================================================

  2.4.1 Information Types

  UPDATE: Syntax for information type to remove the 'exceptionType' attribute

  REMOVE: "When the OPTIONAL attribute exceptionType is set to "true", this Information Type is an Exception Type and MAY map to a WSDL fault type. When the attribute exceptionType is set to "false", this information type MUST NOT map to a WSDL fault type. The default for this attribute is set to "false"."

  REMOVE: "In case of WSDL 2.0, the attribute element within the informationType refers to a unique WSDL 2.0 faultname when the attribute exceptionType is set to "true"."

  REMOVE: Example 4



  ===========================================================

  2.4.2 Variables

  REMOVE: "Can be used to cause Exceptions at one or more parties in a Choreography"

  CHANGE: "A Variable defined using the attribute informationType specifies either Information Exchange Capturing Variables or State Capturing Variables. A Variable defined using the attribute informationType specifies Exception Capturing Variables when the referenced information type has the attribute exceptionType set to "true". A Variable defined using the attribute channelType specifies Channel Capturing Variables. The attributes informationType and channelType are mutually exclusive."

  TO: "A Variable defined using the attribute informationType specifies either Information Exchange Capturing Variables or State Capturing Variables. A Variable defined using the attribute channelType specifies Channel Capturing Variables. The attributes informationType and channelType are mutually exclusive."



  ===========================================================

  2.4.8 Choreography Exception Handling

  CHANGE: "An Exception is caused in the Choreography when an Exception Variable is populated in an Interaction activity with the attribute causeException set to "true"."

  TO: "An Exception is caused in the Choreography when an Interaction activity with the attribute causeException is set. The value of the causeException attribute is used to indicate the type of the exception that has been caused."



  CHANGE: "One or more Exception Work Unit(s) MAY be defined within the Exception Block of a Choreography. At least one Exception Work Unit MUST be defined as part of the Exception Block of a Choreography. An Exception Work Unit MAY express interest on Exception information using its guard condition on Exception Types or Exception Variables. If no guard condition is specified, then the Exception Work Unit is called the Default Exception Work Unit and expresses interest on any type of Exception. Within the Exception Block of a Choreography there MUST NOT be more than one Default Exception Work Unit. An Exception Work Unit MUST always set its block attribute to "false" and MUST NOT define a repetition condition."

  TO: "One or more Exception Work Unit(s) MAY be defined within the Exception Block of a Choreography. At least one Exception Work Unit MUST be defined as part of the Exception Block of a Choreography. An Exception Work Unit MAY express interest on the occurance of a particular type of exception using its guard condition with the "hasExceptionOccurred" CDL function. If no guard condition is specified, then the Exception Work Unit is called the Default Exception Work Unit and expresses interest on any type of Exception. Within the Exception Block of a Choreography there MUST NOT be more than one Default Exception Work Unit. An Exception Work Unit MUST always set its block attribute to "false" and MUST NOT define a repetition condition."



  CHANGE: "When an Exception Work Unit has a guard condition using the hasExceptionOccurred(exceptionType) WS-CDL function, then it is matched when an Exception Variable with Exception Type that matches the parameter exceptionType is populated using an Exception Causing Interaction activity"

  TO: "When an Exception Work Unit has a guard condition using the hasExceptionOccurred(exceptionType) WS-CDL function, then it is matched when an exception causing activity is performed that has a 'causeException' attribute value that matches the exceptionType specified within the function."



  ===========================================================

  2.4.10 Choreography Coordination

  CHANGE: Example needs to be updated to reflect change -- i.e. causeException attributes need to be given a real name 'creditDenied'



  ===========================================================

  2.5.2.3 Interaction Syntax

  UPDATE: Syntax for causeException attribute - no longer boolean NCName (or what ever type means literal string)

  ADD: 'faultName' optional attribute to exchange syntax



  CHANGE: "The OPTIONAL exchange element allows information to be exchanged during an Interaction. The attribute name is used for specifying a name for this exchange element."

  TO: "The OPTIONAL exchange element allows information to be exchanged during an Interaction. The attribute name is used for specifying a name for this exchange element. The OPTIONAL faultName attribute is used to indicate the name of this Fault Exchange."



  CHANGE: "Within the send or the receive element(s) of an exchange element, the causeException attribute when set to "true", specifies that an Exception MUST be caused at the respective Roles. In this case, the informationType of the exchange element MUST be of Exception Type. The default for this attribute is "false""

  TO: "Within the send or the receive element(s) of an exchange element, if the causeException attribute is set, it specifies that an Exception MUST be caused at the respective Roles. In this case, the value of this attribute will identify the exception that should be raised."



  CHANGE: "The request exchange MUST NOT have causeException attribute set to "true""

  TO: "The request exchange MUST NOT have the 'faultName' or 'causeException' attributes specified."



  CHANGE: "When two or more respond exchanges are specified, one respond exchange MAY be of normal informationType and all others MUST be of Exception Type. There is an implicit choice between two or more respond exchanges"

  TO: "When two or more respond exchanges are specified, one respond exchange MAY be a normal response and all others MUST be Fault Exchanges. There is an implicit choice between two or more respond exchanges"



  REMOVE: "The attribute causeException MAY be set to "true" in a record element if the target Variable is an Exception Variable"



  CHANGE: "When the attribute causeException is set to "true" in a record element, the corresponding Role gets into the Exception state"

  TO: "When the attribute causeException is specified, in a record element, the corresponding Role gets into the Exception state"



  CHANGE: "When two or more record elements are specified for the same Role in an Interaction with target Variables of Exception Type, one of the Exception recordings MAY occur. An Exception recording has an non-observable predicate condition, associated implicitly with it, that decides if an Exception occurs"

  TO: "When two or more record elements are specified for the same Role in an Interaction, with their 'causeException' attributes set to indicate that an exception should be raised, then one of the Exceptions MAY occur. The throwing of an Exception has a non-observable predicate condition associated implicitly with it, that decides if an Exception occurs"

  NOTE: Still don't agree with the sentence above, but have reworded to keep consistent.



  UPDATE: Example in this section -- causeException attributes need to be changed

  ===========================================================

  2.5.4 Assigning variables

  UPDATE: Syntax for causeException variable so not boolean, but a name

  REMOVE: "The OPTIONAL attribute causeException MAY be set to "true" in a copy element if the target Variable is an Exception Variable. The default for this attribute is "false""

  CHANGE: "At most one copy element MAY have the attribute causeException set to "true""

  TO: "At most one copy element MAY have the attribute causeException specified."

  CHANGE: "When the attribute causeException is set to "true" in a copy element, the Role specified by the attribute roleType gets into the Exception state after the assign activity has completed"

  TO: "When the attribute causeException is specified in a copy element, the Role specified by the attribute roleType gets into the Exception state after the assign activity has completed"