Re: [wsbpel] R18 - Proposal For Vote

Hi Danny,

[1]

Regarding to your new paragraph, I would like to tighten up the
wordings a bit and add one more guideline for users:

From:

In WSDL it is possible to declare an operation that
declares more than
one fault using the same data type.  Certain WSDL bindings do not
provide enough information for the WS-BPEL process to infer which fault
was intended.  In this case, the WS-BPEL process MUST infer the first
fault declared for the operation that matches the transmitted data.  A
result of this requirement is that a process may have different
behavior when deployed against different bindings.

To:

In WSDL it is possible to define
an operation that declares more than
one fault using the same data type. Certain WSDL bindings do not
provide enough information for the WS-BPEL processor
to infer which fault was intended. In this case, the WS-BPEL processor MUST infer the first
fault by lexical order in the operation
definition that matches the transmitted data. A
result of this requirement is that a process,
which uses <catch> construct based on faultName and deals with such an operation definition,
may have different
behavior when deployed against different bindings. One possible way to avoid different behavior
results from bindings is to use <catch> construct based
on faultElement or faultMessageType, instead of faultName.
  

What do you think? 

[2]

Regarding to editorial cross-reference changes in section 3

-----------------------------

Section 3, P. 11 currently says:

While WS-BPEL attempts to provide
as much compatibility with WSDL 1.1 as possible there are three areas
where
such compatibility is not feasible. 

·       
Fault
naming with its restriction, as discussed later in this document (see
section  REF _Ref136685269 \h 12.5. Fault Handlers

-----------------------------

I think both references to 10.3 and 12.5 are needed. 

If my memory is correct, restrictions in section 12.5 is talking about
multiple operations in multiple porTypes can use the same fault name.
Given a particular fault name, one cannot tell which portType/operation
is coming from.

So, in short, I am suggesting to add a reference, not replace a
reference.

Thanks!

Regards,

Alex Yiu

Danny van der Rijn wrote:

  
Section 10.3, p. 86 currently says:

  

  
In the case of a request-response
invocation, the operation might return a WSDL fault message. This
results in a
fault identified in WS-BPEL by a QName formed by the target namespace
of the
corresponding port type and the fault name. To ensure consistent fault
identification, this uniform naming mechanism MUST be followed even
though it does
not match the WSDL’s fault-naming model. WSDL 1.1 does not require
fault names
to be unique within the namespace where the service operation is
defined.
Therefore, in WSDL 1.1 it is necessary to specify a port type name, an
operation name, and the fault name to uniquely identify a fault. Using
WSDL
1.1's scheme would limit the ability to use fault-identification and
handling
mechanisms to deal with invocation faults. 

I propose adding the following paragraph after that:

  

In WSDL it is possible to declare an operation that declares more than
one fault using the same data type.  Certain WSDL bindings do not
provide enough information for the WS-BPEL process to infer which fault
was intended.  In this case, the WS-BPEL process MUST infer the first
fault declared for the operation that matches the transmitted data.  A
result of this requirement is that a process may have different
behavior when deployed against different bindings.

  

I propose that this is marked as a substantive change.

  

In addition, I propose the following editorial change:

  

Section 3, P. 11 currently says:

  

  
While WS-BPEL attempts to provide
as much compatibility with WSDL 1.1 as possible there are three areas
where
such compatibility is not feasible. 

  
·       
  Fault
naming with its restriction, as discussed later in this document (see
section  REF _Ref136685269 \h 12.5. Fault Handlers)

  

But Section 12.5 says

  

  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 with a matching
QName (see section 10.3. Invoking
Web Service Operations – Invoke
for the description of how to construct this QName
from a fault defined in WSDL). 

  

Proposed change:

  

P. 11 should have its reference to 12.5 replaced with one to 10.3