OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Issue - 280 - Proposal to Vote



(resend the response to the correct email thread)

Hi Dieter,

-1 to the proposal.

Copied from the word doc:
======================

- paragraph after the fault catching rules, from:

Matching the type of a faultVariable to fault data as mentioned in points #1 and #4 above is more restrictive than in points #2 and #5. A WSDL message type variable can only match a WSDL message type fault data, while an element variable can only match element based fault data. They match only when their QNames are identical.
 

to:
 

Matching the declared type of a faultVariable to the declared type of the fault data as mentioned in points #1 and #4 above is based on QName matching of the declared variable types. This means, if a variable declared with element type tns:bar is thrown, a catch with faultElement="tns:bar" will catch it.
======================

As mentioned before, this proposal essentially create a psuedo-data-model in BPEL which treat type always *static*.

This static psudo-data-model significantly contradicts:

The not-well-founded urge to quest for skin-deep-level symmetry in <catch> will abrupt the future adoption of other standards.

I would prefer Mark Ford's original proposal.

Mark Ford's proposal is just a bug fix/clarification, while Dieter's proposal is definitely a new feature. That really violates the practice that we should ONLY do clarification/bug-fix in this stage of specification.

And, this <catch> with "type" discussion was discussed way back when Yaron suggested to add "element" . It was a conscious decision that we do NOT add type related feature to <catch> to stay way from type related complexities: inheritance and polymorphism complexities.


Thank you!


Regards,
Alex Yiu



Dieter Koenig1 wrote:
Also as Word-File to highlight the changes:
http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/18915/Issue%20280%20-%20Proposal%20for%20Vote.doc

Proposal for vote (Issue 280)

Change the syntax descriptions of <catch> from:

   <catch faultName="QName"? faultVariable="NCName"?
                             faultMessageType="QName"?
                             faultElement="QName"?>*
       activity
   </catch>

to:

   <catch faultName="QName"? faultVariable="NCName"?
                             faultMessageType="QName"?
                             faultElement="QName"?
                             faultType="QName"?>*
       activity
   </catch>

This change has to be done in:
- Section 5.2, basic structure of <process>
- Section 5.2, basic structure of <invoke>)
- Section 10.3, syntax of the <invoke> activity
- Section 12.5, syntax of <faultHandlers>

Change in section 12.5:

- paragraph 7 and 8, from:

   Data thrown with a fault can be a WSDL message type or a XML schema
   element. Each <catch>, which specifies a QName as its faultName
   attribute value, can only catch a fault matching that particular QName.
   This one-to-one relationship is necessary in order to guarantee proper
   targeting for fault catching. If the data to be caught is a WSDL message
   then the faultMessageType attribute is used to specify the message
   type’s QName. If the data to be caught is a XML element then the
   faultElement attribute is used to specify the element definition’s
   QName.

   To have a defined type associated with the fault variable, the
   faultVariable attribute MUST only be used if either the faultMessageType
   or faultElement attributes, but not both, accompany it. The
   faultMessageType and faultElement attributes MUST NOT be used unless
   accompanied by faultVariable attribute.

to:

   Data thrown with a fault can be a WSDL message type, a XML schema
   element or a XML schema type. Each <catch>, which specifies a QName as
   its faultName attribute value, can only catch a fault matching that
   particular QName. This one-to-one relationship is necessary in order to
   guarantee proper targeting for fault catching. If the data to be caught
   is a WSDL message then the faultMessageType attribute is used to specify
   the message type’s QName. If the data to be caught is a XML schema
   element, then the faultElement attribute is used to specify the element
   declaration's QName. If the data to be caught is a XML schema type, then
   the faultType attribute is used to specify the type definition’s QName.

   To have a defined type associated with the fault variable, the
   faultVariable attribute MUST only be used if exactly one of the
   faultMessageType, faultElement or faultType attributes accompany it. The
   faultMessageType, faultElement or faultType attributes MUST NOT be used
   unless accompanied by faultVariable attribute.

- fault catching rule 1 with associated data, from:

   If there is a <catch> construct with a matching faultName value that has
   a faultVariable whose type matches the type of the fault data then the
   fault is passed to the identified <catch> construct.

to:

   If there is a <catch> construct with a matching faultName value that has
   a faultVariable whose declared type matches the declared type of the
   fault data then the fault is passed to the identified <catch> construct.

- fault catching rule 4 with associated data, from:

   Otherwise if there is a <catch> construct without a faultName attribute
   that has a faultVariable whose type matches the type of the fault data
   then the fault is passed to the identified <catch> construct.

to:

   Otherwise if there is a <catch> construct without a faultName attribute
   that has a faultVariable whose declared type matches the declared type
   of the fault data then the fault is passed to the identified <catch>
   construct.

- paragraph after the fault catching rules, from:

   Matching the type of a faultVariable to fault data as mentioned in
   points #1 and #4 above is more restrictive than in points #2 and #5. A
   WSDL message type variable can only match a WSDL message type fault
   data, while an element variable can only match element based fault data.
   They match only when their QNames are identical.

to:

   Matching the declared type of a faultVariable to the declared type of
   the fault data as mentioned in points #1 and #4 above is based on QName
   matching of the declared variable types. This means, if a variable
   declared with element type tns:bar is thrown, a catch with
   faultElement="tns:bar" will catch it.

- paragraph after the fault catching example, from:

   Assume that a fault named ”x:foo” is thrown from within the scope to
   which this <faultHandlers> construct is attached. The first <catch> will
   be selected if the fault carries no fault data. If there is fault data
   associated with the fault, the third <catch> will be selected if and
   only if the type of the fault’s data matches the type of variable “bar”,
   otherwise the <catchAll> fault handler will be selected. Finally, a
   fault with a fault variable whose type matches the type of “bar” and
   whose name is not “x:foo” will be processed by the second catch. All
   other faults will be processed by the <catchAll> fault handler.

to:

   Assume that a fault named ”x:foo” is thrown from within the scope to
   which this <faultHandlers> construct is attached. The first <catch> will
   be selected if the fault carries no fault data. If there is fault data
   associated with the fault, the third <catch> will be selected if and
   only if the declared type of the fault’s data matches the declared type
   of variable “bar”, otherwise the <catchAll> fault handler will be
   selected. Finally, a fault with a fault variable whose declared type
   matches the declared type of variable “bar” and whose name is not
   “x:foo” will be processed by the second catch. All other faults will be
   processed by the <catchAll> fault handler.
  



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]