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 52] CT generation (section 2.1.1) does nottake into consideration the multRefFrom attribute -- Version 2


Version 2 based on last week's comments.
Attached.
The only change is in SBPEL2010.

-Anish
--

Anish Karmarkar wrote:
> Spec with inlined proposed amendment, listed by Michael (below), attached.
> 
> -Anish
> -- 
> 
> Michael Rowley wrote:
>>  
>>
>> Proposal amendment: Change 2.1.1 so that any partner link with 
>> MultiRefFrom attribute is not made into a service or reference and the 
>> partner link must not include a sca:reference or sca:service annotation.
>>
>>  
>>
>> Also the <multireference> element should also include a name attribute 
>> so that people can customize the reference name that is generated.
>>
>>  
>>
>> Michael
>>
>>  
>>
>>  
>>
>> *From:* Michael Rowley
>> *Sent:* Thursday, July 23, 2009 1:48 PM
>> *To:* Michael Rowley; Danny van der Rijn
>> *Cc:* Anish Karmarkar; OASIS BPEL
>> *Subject:* RE: [sca-bpel] [Issue 52] CT generation (section 2.1.1) 
>> does not take into consideration the multRefFrom attribute
>>
>>  
>>
>>  
>>
>> This time with attachment.
>>
>>  
>>
>> *From:* Michael Rowley
>> *Sent:* Thursday, July 23, 2009 1:47 PM
>> *To:* 'Danny van der Rijn'
>> *Cc:* Anish Karmarkar; OASIS BPEL
>> *Subject:* RE: [sca-bpel] [Issue 52] CT generation (section 2.1.1) 
>> does not take into consideration the multRefFrom attribute
>>
>>  
>>
>>  
>>
>> Sure.  Here is a marked up spec.
>>
>>  
>>
>> Michael
>>
>>  
>>
>> *From:* Danny van der Rijn [mailto:dannyv@tibco.com]
>> *Sent:* Thursday, July 23, 2009 1:14 PM
>> *To:* Michael Rowley
>> *Cc:* Anish Karmarkar; OASIS BPEL
>> *Subject:* Re: [sca-bpel] [Issue 52] CT generation (section 2.1.1) 
>> does not take into consideration the multRefFrom attribute
>>
>>  
>>
>> I'm having trouble shuffling this all around in my head.  If it's not 
>> too much trouble could you either include context-diff-like text or a 
>> marked up spec doc?
>>
>> Fuzzily yours,
>> Danny
>>
>> Michael Rowley wrote:
>>
>>  
>>
>> Alternative proposal:
>>
>> Move requirements 3006 and 3007 to the end of section 2.1.1 (and 
>> possibly renumber the requirements).
>>
>> In the place where those requirements used to exist, insert the text: 
>> "The introspected component type will include a reference with 
>> multiplicity 0..n for this variable, as specified in section 2.1.1."
>>
>> Michael
>>
>> -----Original Message-----
>> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
>> Sent: Wednesday, July 15, 2009 8:11 PM
>> To: OASIS BPEL
>> Subject: [sca-bpel] [Issue 52] CT generation (section 2.1.1) does not 
>> take into consideration the multRefFrom attribute
>>
>> This is now issue 52
>> http://osoa.org/jira/browse/BPEL-52
>>
>> Anish Karmarkar wrote:
>>>  Title: CT generation (section 2.1.1) does not take into consideration
>>>  the multRefFrom attribute
>>>
>>>  Target: BPEL C&I spec
>>>
>>>  Description:
>>>  If a partnerLink does not contain a sca-bpel:reference or a
>>>  sca-bpel:service attribute, the algorithm in section 2.1.1 Generating
>>>  Services and References requires doing a static analysis (SBPEL2005) to
>>>  figure out if the PL should be mapped to a sca reference or a service.
>>>  It does not give any consideration to the sca-bpel:multiRefFrom
>>>  attribute that may be present on the PL.
>>>
>>>  A PL with such a attribute should be mapped to an SCA reference and
>>>  never to a SCA service.
>>>
>>>  Proposal:
>>>
>>>  Add two new requirement (after SBPEL2004):
>>>  [SBPEL2004.1] If a partner link specifies a sca-bpel:multiRefFrom
>>>  attribute, then a reference MUST be generated for the introspected
>>>  component type. [SBPEL2004.2] If the name of the partner link is unique
>>>  within the process, then it MUST be used as the name of the reference.
>>>  Otherwise, the name is determined according to the rules of section 
>>> 2.3.
>>>
>>>  Modify SBPEL2005 as follows:
>>>  s/If neither sca-bpel:service nor sca-bpel:reference is present/If none
>>>  of the attributes: sca-bpel:service, sca-bpel:reference or
>>>  sca-bpel:multiRefFrom is present/
>>>
>>>  Modify SBPEL2007 to include the two new requirements.
>>>
>>>  -Anish
>>>  --
>>>
>>>  ---------------------------------------------------------------------
>>>  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
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
> 
> ------------------------------------------------------------------------
> 
> ---------------------------------------------------------------------
> 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 

sca-bpel-1.1-spec-cd02-rev2+issue52-ask-v2.doc



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