Issue - 9 - Entries for consideration

["Yaron Y. Goland" <ygoland@bea.com>]

I'm reply to Bernd's mail to get it included in Issue 9 since I think 
that the list provided here will become part of the resolution for issue 9.
	Thanks,
		Yaron

Eckenfels. Bernd wrote:

> 
> 
> Hello,
> 
> on the BPEL-Impl phone conference, we discussed a few issues in the 
> samples of the spec, which can be verified by static checks:
> 
> name: undeclared throwables
> ------------------------------------------
> severity: error
> purpose: this static check is verifying the faultName attributes of the 
> catch for undeclared faults
> check: for each qname in catch@faultName check if there is at least one 
> defined portTypes which contain an operation with a fault element, with 
> the same qname in the name attribute. For thrown faults, this check can 
> also be used (throw@faultName), but only can raise a warning, since it 
> is legal to throw undeclared faults.
> 
> name: throwable message mismatch
> ------------------------------------------------------
> severity: error
> purpose: verify the type of variable for faults
> check: for each catch@faultName where faultVariable is defined, look up 
> the fault message declaration, and compare the message type with the 
> type of the variable, which must match
> 
> 
> name: faults not unique
> ----------------------------------
> severity: portability warning
> purpose: identify unsupported wsdl 1.1 feature.
> check: according to the bpel spec fault's qname need to be globally 
> unqiue, so if there are two operations inside a process defined where 
> the declared fault has a different type, but the same name, this is 
> legal for wsdl, but may create problems while catching that fault. it 
> can be chcked with the "undeclared throwable" case with the follwoing 
> modification: for each qname in catch@faultName check if there is 
> _exactly_ one defined portTypes which contain an operation with a fault 
> element, with the same qname in the name attribute.
> 
> 
> name: undeclared fault catched
> ---------------------------------------------
> severity: design warning
> purpose: find catch statements, which can never occur.
> check: for every activity with a catch element, check if any of the 
> enclosed activites actually declare the fault to be thrown. (asume that 
> all activites may throw any of the bpel system faults without actual 
> declaration)
> 
> 
> Mit freundlichen Grüßen
> Bernd Eckenfels
> Chief Architect
> --
> SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany
> Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256
> mailto:b.eckenfels@seeburger.de - http://www.seeburger.de
>