Folks,
A few editorial changes:
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email:
From:
Anish Karmarkar <>
To:
OASIS BPEL <>
Date:
20/08/2009 07:36
Subject:
Re: [sca-bpel] Issue 41: proposal with
examples -- version 2
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
>>> --
>>>
[attachment "issue41-ask-v2.doc" deleted by Mike Edwards/UK/IBM]
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
issue41-ask-v2_mje.doc
