4A8CEEC8.3000904@oracle.com" 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
>>> --
>>>