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

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

+1

Anish Karmarkar wrote:
" type="cite">
  
  
  

  
Attached.

  

The changes are based on discussions from last week. Diff between v1
and v2:

1) Added SBPEL2ZZZ in anticipation of issue 52 resolution.

2) made the changes to the example as suggested by Danny.

3) Added the last paragraph in the proposal.

  

-Anish

--

  

Anish Karmarkar wrote:

> 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:

>>>

>>> 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

>>> --

>>>

  
  

S/MIME Cryptographic Signature