NEW ISSUE: Title: SCA-BPEL spec can not require bpel:mustUnderstandto be true

TARGET: SCA C+I WS-BPEL spec, General

DESCRIPTION: Section 3 currently reads as follows:

"It is possible to use WS-BPEL processes in
conjunction
with SCA, while the processes have no knowledge of SCA. A few SCA
concepts are only available to WS-BPEL
processors that support SCA
specific extensions.  The capabilities
that require knowledge of SCA are provided by an SCA extension, which
must be
declared in any process definition as follows:

<process ...>

   <extensions>

     
<extension

        
namespace="http://docs.oasis-open.org/ns/opencsa/sca-bpel/200801"

         mustUnderstand="yes"
/>

   </extensions>

   ...

</process>

"

This is too restrictive.  There should be no requirement on the value
of bpel:mustUnderstand.  Let's examine what the attribute actually
means.  From section 14 of the BPEL spec itself:

"

If a WS-BPEL processor does not
support one or more of the extensions with mustUnderstand="yes", then the process definition MUST be rejected.

Optional extensions are extensions which the WS-BPEL process MAY ignore. There is no requirement
to declare any
optional extensions. Optional extension can be declared using the
extensions
element with mustUnderstand="no".
The purpose of allowing optional extensions to be declared using the
extensions
element is to provide a well defined location where additional
information
about the optional extension can be found.

"

Reading the current language of both specifications, consider the
following edge case:

<process...>

    <extensions>

       <extension
namespace="http://docs.oasis-open.org/ns/opencsa/sca-bpel/200801"
mustUnderstand="yes" />

    <extensions/>

    ... a process where NO items from the sca-bpel namespace are used
...

   OR

   ... a process where sca-bpel items are used, but the processor need
not know about them in order to run ...

</process>

In this case, a "vanilla" BPEL processor will process the file with no
issue.  An SCA-BPEL processor MUST reject the process as invalid, since
the requirement in section 3 is not followed.

This is not correct behavior.  SCA-BPEL processors must accept a
superset of what BPEL processors can process.  To do otherwise would
introduce a nightmare of compatibility issues.

PROPOSAL: change the wording in Section 3 to read as follows

It is possible to use WS-BPEL processes in conjunction
with SCA, while the processes have no knowledge of SCA. A few SCA
concepts are only available to WS-BPEL
processors that support SCA
specific extensions.  The capabilities
that require knowledge of SCA are provided by an SCA extension, whose
namespace is "http://docs.oasis-open.org/ns/opencsa/sca-bpel/200801". 
An example of using the namespace in a BPEL process is as follows:

<process ...>

   <extensions>

     
<extension

        
namespace="http://docs.oasis-open.org/ns/opencsa/sca-bpel/200801"

         mustUnderstand="yes"
/>

   </extensions>

   ...

</process>

S/MIME Cryptographic Signature