OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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

S/MIME Cryptographic Signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]