Re: [wsbpel] New Issue - Import in AP: basic executable completion

[Alex Yiu <alex.yiu@oracle.com>]

Hi all,

Based on a conversation that I had with Rania earlier, I would suggest 
to allow adding declaration of  partnerLinks, variables 
messageExchanges, correlationSets to an existing <scope> and <process> 
as a part of BEC (Basic Executable Completion) and also allow adding 
declaration of import and extension to <process> as a part of BEC, as 
long as all these declaration are NOT referenced by the construct in the 
AP.

The last "as long as" clause is to avoid some ill-defined AP. E.g. an AP 
refers to a variable or a partnerLink not declared in the AP.

Thanks!

Regards,
Alex Yiu


Rania Khalaf wrote:

> hi danny
> there are two concepts of completions:
>
> basic, *only for validation* to make sure you didn't do wierd stuff 
> like one link that has 10 sources and one target. this only lets you 
> replace explicit opaque token. There is no opaque import or opaque 
> extension element in BPEL today.
>
> 'maximal' lets you add whatever you like including all you have below.
>
> The completions that represent your AP's behavior result from the 
> completiion rules *of your profile*, which will be a subset of the 
> 'maximal' completion. So in this one, whether you can do what you say 
> below, depends on the completions set of your profile.
>
> regards,
> rania
>
> Danny van der Rijn wrote:
>
>> what about <extensions>?
>>
>> and a side question:  what are the completion rules for things 
>> outside of the primary activity and handlers?  for instance, can I 
>> add a <variables> element if there isn't one?  If not, can I put an 
>> <opaque> there instead?  Can I add a <variable> element to an 
>> existing <variables> element?  Partnerlinks?  CorrelationSets?  etc.?
>>
>> Rania Khalaf wrote:
>>
>>> The AP basic completion rules were defined before BPEL mandatory
>>> <import>s were introduced. The question that is open now is how do they
>>> affect the basic executable completion rule that is used to
>>> syntactically validate an Abstract Process (from any profile).
>>>
>>> Currently,  the basic exec completion is :
>>>
>>>
>>> A Basic Executable Completion of an Abstract Process is defined as an
>>> Executable Completion whose allowed syntactic transformations are
>>> limited to Opaque Token Replacement, plus the addition of an activity
>>> with createInstance="yes" if none are present in the Abstract Process
>>> (per clause [5] of section 13.1.3. Hiding Syntactic Elements).
>>>
>>>
>>> Where  1b1 is:
>>>
>>> •       Opaque Token Replacement: Replacing every opaque token 
>>> (including
>>> those omitted using the omission-shortcut) with a corresponding
>>> Executable token. For example, replacing an opaque activity with an
>>> <empty>.
>>>
>>>
>>> So, without changing anything and taking the usage of <import> means
>>> that one cannot (1) use wsdl/xsd/etc artifacts in the AP that have not
>>> been defined in an imported documents and (2) replace opaque tokens 
>>> with
>>> artifacts not defined in these documents for the basic exec completion.
>>>
>>> The question is do we want to allow (1) and (2), or just (2), or 
>>> niether?
>>>
>>> This affects section 13.1 and the two profiles (they have to decide
>>> whether their completions allow adding arbitrary imports, aside from 
>>> the
>>> basic exec profile )
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>> generates this mail.  You may a link to this group and 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.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php