[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
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 >>> -- >>>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]