NEW ISSUE: BPEL SCA extension NS, what should be the value of mustUnderstand?

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Title: BPEL SCA extension NS, what should be the value of mustUnderstand?

Target: BPEL C&I spec

Description:
In the BPE C&I spec we define the namespace 
"http://docs.oasis-open.org/ns/opencsa/sca-bpel/200801";, this namespace 
contains BPEL extensions for SCA.
For BPEL extensions, a mustUnderstand attribute is specified as follows:

<extensions>
       <extension 
namespace="http://docs.oasis-open.org/ns/opencsa/sca-bpel/200801"; 
mustUnderstand="[yes|no]" />
</extensions>

This attribute tells the BPEL processor whether it is necessary to 
understand the extension.

There are two issues here:
1) Since the granularity of MU is at the namespace level, does it make 
sense to bundle all our extensions attributes in a single NS?
2) Does this mean that the 'requires' attribute that we intend to use 
for intents in a BPEL process be part of 
"http://docs.oasis-open.org/ns/opencsa/sca-bpel/200801"; or can it be 
part of "http://docs.oasis-open.org/ns/opencsa/sca/200712";?

Proposal:

I don't think we need a finer granularity. It is possible that in a 
certain BPEL process, it is ok to ignore the sca:service attribute but 
not the sca:property attribute. But this is about 'understanding' the 
extension, if a BPEL processor understands sca:service it must also 
understand sca:property and vice versa. It can't choose to understand 
only part of the C&I.

WRT requires attribute, I prefer to not copy it from the main SCA NS 
into BPEL NS. There are three potential problems with having two 
extension namespaces:
1) it is now possible that in a particular process, one of the 
namespaces is MU='yes' and the other is MU='no'. We should disallow that.
2) it is now possible that a BPEL process may contain a sca 
attribute/element from the main SCA NS whose use is not defined by the 
BPEL C&I. For example, what does it mean for the 'autowire' attribute or 
sca:binding element to appear in the BPEL process. We should disallow that.
3) 'requires' attribute is not currently defined as a global attribute 
in the main SCA namespace. This will have to change.

Alternately, we can copy the requires attribute into the SCA BPEL NS, 
but this adds the burden of keeping them in sync.

-Anish
--