← Prev in month ← Prev in thread
Next in thread → Next in month →

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

From
Tony Fletcher <>
Date
2005-01-21T12:32:01+00:00
ID
002701c4ffb5$323e3e80$
Thread
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.
Links: 

Changes: 20 Jan 2005 - new issue

 

Best 
Regards,

Tony                           

  
  

    
      

    
      
Tony 
      Fletcher

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

  

    
      
Phone:  
      

    
      
+44 
      (0) 1473 729537

  

    
      
Mobile: 
      

    
      
+44 
      (0) 7801 948219

  

    
      
Fax:    
      

    
      
+44 
      (0) 870 7390077

  

    
      
Web:

    
      
www.choreology.com

  

    
      
Cohesions™

  

    
      
Business 
      transaction management software for application 
      coordination

  

    
      

      

Work:  
      

  

    
      
Home: 
      
← Prev in month ← Prev in thread
Next in thread → Next in month →