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: Issue 68 - Proposal for vote (revised)


I have been advised that posting a new proposal to vote is the right
thing to do when revisions occur.  So here goes.

I propose that we change the syntax of faultHandlers to the following

<faultHandlers>?
    <!-- there must be at least one fault handler or default -->
    <catch faultName="qname"? faultVariable="ncname"?
                              faultMessageType="qname"?>*
      activity
    </catch>
    <catchAll>?
      activity
    </catchAll>
</faultHandlers>

And in addition I propose that we add the following sentences
immediately following the syntax.

Note that the faultName, faultVariable and faultMessageType attributes
are all optional.  However, the faultVariable and faultMessageType
declarations go together, i.e., they must either both be present or both
absent.  This is to ensure that the type of the faultVariable is well
specified even when the faultName is omitted.  Moreover, the faultName
and faultVariable attributes cannot both be absent.

Satish

-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com] 
Sent: Thursday, January 15, 2004 12:09 PM
To: Jim Clune; wsbpel@lists.oasis-open.org
Cc: Yaron Y. Goland
Subject: RE: [wsbpel] Issue 68 - Proposal for vote

Good idea.  Thanks for the suggestion.

My proposal then stands amended as follows

<faultHandlers>?
    <!-- there must be at least one fault handler or default -->
    <catch faultName="qname"? faultVariable="ncname"?
                              faultMessageType="qname"?>*
      activity
    </catch>
    <catchAll>?
      activity
    </catchAll>
</faultHandlers>

And in addition I propose that we add the following sentences
immediately following the syntax.

Note that the faultName, faultVariable and faultMessageType attributes
are all optional.  However, the faultVariable and faultMessageType
declarations go together, i.e., they must either both be present or both
absent.  This is to ensure that the type of the faultVariable is well
specified even when the faultName is omitted.  Moreover, the faultName
and faultVariable attributes cannot both be absent.

Satish

P.S.  As Jim points out, we will probably add a faultType attribute in
future to account for the throw case with an XML typed variable.  But I
would like to deal with that as a separate issue.

-----Original Message-----
From: Jim Clune [mailto:jim@parasoft.com] 
Sent: Thursday, January 15, 2004 11:44 AM
To: Satish Thatte; wsbpel@lists.oasis-open.org
Cc: Yaron Y. Goland
Subject: Re: [wsbpel] Issue 68 - Proposal for vote

Could we call the new attribute "faultMessageType" instead of
"faultType"
for consistency with the meanings of the "type" and "messageType"
attributes
in explicit variable declarations?

Jim Clune
Parasoft Corporation          email: jim.clune@parasoft.com
101 E. Huntington Ave.      voice: (626) 256-3680
Monrovia, CA.  91016           fax  : (626) 256-6884
----- Original Message ----- 
From: "Satish Thatte" <satisht@microsoft.com>
To: "Jim Clune" <jim@parasoft.com>; <wsbpel@lists.oasis-open.org>
Cc: "Yaron Y. Goland" <ygoland@bea.com>
Sent: Thursday, January 15, 2004 9:22 AM
Subject: RE: [wsbpel] Issue 68 - Proposal for vote


Good question.  It is currently interpreted as a WSDL message type since
the faults received from a web service invocation were the original
canonical faults and all BPEL variables were message variables so all
internal faults were also of that kind.  Now that we have XML typed
variables there is a potential inconsistency with throw that we should
fix separately - Yaron was just pointing it out to me.

To summarize:  this is a bug fix that reminds us of another potential
bug that we may need to fix.

Satish

-----Original Message-----
From: Jim Clune [mailto:jim@parasoft.com]
Sent: Thursday, January 15, 2004 8:51 AM
To: Satish Thatte; wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue 68 - Proposal for vote

Satish -

Is the faultType value to be interpreted as a WSDL message type or an
XML
Schema type?

Jim Clune
Parasoft Corporation          email: jim.clune@parasoft.com
101 E. Huntington Ave.      voice: (626) 256-3680
Monrovia, CA.  91016           fax  : (626) 256-6884
----- Original Message ----- 
From: "Satish Thatte" <satisht@microsoft.com>
To: <wsbpel@lists.oasis-open.org>
Sent: Wednesday, January 14, 2004 5:01 PM
Subject: [wsbpel] Issue 68 - Proposal for vote


I propose that we change the syntax of faultHandlers to the following

<faultHandlers>?
    <!-- there must be at least one fault handler or default -->
    <catch faultName="qname"? faultVariable="ncname"?
faultType="qname"?>*
      activity
    </catch>
    <catchAll>?
      activity
    </catchAll>
</faultHandlers>

And in addition I propose that we add the following sentences
immediately following the syntax.

Note that the faultName, faultVariable and faultType attributes are all
optional.  However, the faultVariable and faultType declarations go
together, i.e., they must either both be present or both absent.  This
is to ensure that the type of the faultVariable is well specified even
when the faultName is omitted.  Moreover, the faultName and
faultVariable attributes cannot both be absent.

Satish


To unsubscribe from this mailing list (and be removed from the roster of
the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
oup.php.








To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
oup.php.





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