Re: [sca-bpel] Issue 41: proposal with examples

Danny van der Rijn wrote:

  
Strangely, I like this :-)  Thanks for taking the time, Anish, to flesh
this out in spec language.  I like the addition of

  

"
  
o        
  [SBPEL2YYY] If the
sca-bpel:service
or
sca-bpel:reference attribute is present on the partnerLink, its value
MUST NOT
be a member of S. The value of the
attribute is added to S and appropriate
SCA service or reference is generated per section 2.1.1.

"

  

IMO it would be worth changing the example slightly to include a use of
SBPEL2YYY:

  

  

  
<process
…>

  
  <partnerLinks>

  
    <partnerLink name="shipping"
"_shipping_1" sca-bpel:service="shipping" ... />

  
    <partnerLink
name="_shipping_2" ... />

  
    <partnerLink name="receiving"
... />

  
    <partnerLink name="_receiving_2"
... />

  
  </partnerLinks>

  
 

  
  ...

  
 

  
  <scope>

  
    <partnerLinks>

  
      <partnerLink
name="shipping" ... />

  
      <partnerLink
name="receiving"
... />

  
      <partnerLink
name="_shipping_1"
... />

  
      <partnerLink
name="_receiving_1"
... />

  
    </partnerLinks>

  
 

  
    ...

  
 

  
  </scope>

  
 

  
  ...

  
 

  
</process>

  

  

with the resulting tables remaining the same.

  

+1 to the change

I should also point out that the resolution of issue 52 will alter the
algorithm as the sca-bpel:multiReference element can now have a name
attribute.

  

However, the addition of SBPEL2YYY does bring up another edge case.  I
think I'm OK with not closing the loophole and just leaving this sharp
corner there for the few people in the world who will run up against
it, to mix my metaphors.  But I feel the need to point it out, anyway.

  

Consider a modification on the first example:

  

  

  
<process
…>

  
  <partnerLinks>

  
    <partnerLink name="shipping"
... />

  
    <partnerLink
name="_shipping_2" ... />

  
    <partnerLink name="receiving"
... />

  
    <partnerLink name="_receiving_2"
... />

  
  </partnerLinks>

  
 

  
  ...

  
 

  
  <scope>

  
    <partnerLinks>

  
      <partnerLink
name="shipping"  sca-bpel:service="shipping"
... />

  
      <partnerLink
name="receiving"
... />

  
      <partnerLink
name="_shipping_1"
... />

  
      <partnerLink
name="_receiving_1"
... />

  
    </partnerLinks>

  
 

  
    ...

  
 

  
  </scope>

  
 

  
  ...

  
 </process>

  

  

  

This would be an invalid document under SBPEL2YYY since "shipping" will
already have been assigned by the algorithm.

  

Indeed. IMHO, it is ok to call such a document non-conformant document.
The creator specifically used the sca-bpel:service attribute to name
the ref/service associated with the partnerLink and should have chosen
a unique name.

But there is another case which is even tricker: when the creator does
choose a unique name (as far as partner link names are concerned) but
it still results in an invalid document. 

For example:

<partnerLink name="shipping" .../>

<scope>

   <partnerLink name="shipping" .../>

   <parnerLink name="foobar" sca-bpel:service="_shipping_1 .../>

</scope>

This is a result of the fact that we have a one-pass algorithm that
does not do any look-ahead when mangling names. I think it is a trade
off. I'm fine with the one-pass algorithm, but the useful guideline
here for values of sca-bpel:service/reference attribute values is:

don't use underscore as the 1st character of the name, don't use
integers preceded by underscore as the last characters of the name.

-Anish

--

Anish Karmarkar wrote:
  
    
    
    [sca-bpel] Issue 41: proposal with examples

    
Attached.

    

This is based on the proposal that was sent by Danny (which updated the

proposal sent by MichaelR). I have added examples (that were also sent

by Danny in a different email).

    

Comments?

    

-Anish

--