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 - 185 - Clarify relationship between fault name and type of fault data

Title: Message
This issue has been added to the wsbpel issue list with a status of "received". The status will be changed to "open" if the TC accepts it as identifying a bug in the spec or decides it should be accepted specially. Otherwise it will be closed without further consideration (but will be marked as "Revisitable")

The issues list is posted as a Technical Committee document to the OASIS WSBPEL TC pages on a regular basis. The current edition, as a TC document, is the most recent version of the document entitled in the "Issues" folder of the WSBPEL TC document list - the next posting as a TC document will include this issue. The list editor's working copy, which will normally include an issue when it is announced, is available at this constant URL.

Issue 185: Clarify relationship between fault name and type of fault data

Status: received
Date added: 20 Jan 2005
Categories: Fault handling
Date submitted: 19 January 2005
Submitter: Satish Thatte
Description: Per the discussion in the TC call today, it seems that there are different interpretations of allowable relationship between a fault name and the type of fault data associated with that name. My interpretation has always been that a fault is a “package” consisting of a QName and a specific type of data “payload”. Using the same QName with different data types would amount to “overloading” of a kind. But clearly, my interpretation is not the only possible one and in any case this is not clearly stated one way or the other in the specification, which it should be, because this is an issue of normative constraints on the usage of fault names/data.

I therefore propose that we open this new issue, in order to discuss and clarify this ambiguity in the text of the specification.

Submitter's proposal: None so far.
Changes: 20 Jan 2005 - new issue


Best Regards,


Tony Fletcher

Technical Advisor
Choreology Ltd.
68, Lombard Street, London EC3V 9L J   UK


+44 (0) 1473 729537


+44 (0) 7801 948219


+44 (0) 870 7390077




Business transaction management software for application coordination

Work: tony.fletcher@choreology.com

Home: amfletcher@iee.org


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