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


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

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

Subject: Re: [wsbpel] Issue 107 - updates based on feedback, with changelog

Recommended changes to proposal based on received comments (mainly 

Rania Khalaf wrote:

>  Expanding on Peter's existing 107
proposal (details, syntax,
>  examples), assuming concepts in 82 (base+profiles) :
>  ----------------------------------------------------------------
>  15.1 Language extensions for Abstract Processes
>  The language extensions consist of opaque

Add: tokens which are used as explicit

>  'placeholders'

Add: for missing details.

>  . Note that "opaque" is not a new semantically meaningful construct
>  but a syntactic device for indicating incompleteness. As such,
>  "opaque" entities have no semantics of their own.>

>  There are three kinds of opaque placeholders: expressions,
>  activities, and attributes. A usage profile may

Replace: decrease the allowed level of opacity
With: restrict the kinds of opaque tokens allowed.

>  discretion.

Add: For example, a profile could specify that it allows only opaque 
but not opaque expressions and attributes, or a profile could specify 
that it allows
all attributes to be opaque except the “partnerLink” attribute. However, 
a usage profile

>  may not

Replace: increase
With: expand

>  it above what is allowed by the "common base".

Add: For example, a profile cannot specify that it allows <faultHandler> 
elements to be opaque.

>  -Under the 'common base' section
>  ---------------------------------
>  Three types of opaque tokens are allowed in abstract processes:
>  activities, expressions, and attributes. The functions of these
>  opaque placeholders are described below, with examples:

>  Part A - Opaque activities:
>  An opaque activity

Replace: explicitly hides a concrete BPEL activity
With: is a placeholder for exactly one executable BPEL activity (not
counting any activities that could be nested within that single executable

>  whose behavior is not relevant to the recipient/user of the abstract
>  process. An opaque activity is a BPEL activity and therefore has the
>  same standard elements and attributes that all BPEL activities have
>  (see spec section 11.1 and 11.2). It has the following form:

Replace: <opaque standard-attributes> standard-elements </opaque>
<opaqueActivity standard-attributes>

>  One examples of using opaque activities includes creating process
>  templates (marking the points of normative extension in a process).
>  Another is when creating an abstract process from a known executable
>  process and wanting to hide an activity that is a join point for
>  several links. If that activity, on the other hand, had just been an
>  unlinked activity in a 'sequence' it could have just been omitted
>  from the resulting abstract process.

>  At first glance, it seems that this could instead be done using

Replace "empty". The difference is that "empty"
With : <empty>. The difference is that <empty>

>  explicitly says "nothing happens here," whereas

Replace "opaque"
With <opaqueActivity>

>  is really saying "something happens here, but it's hidden
>on purpose".

>  A.1 Level of opacity allowed in the base: Opaque activities are
>  allowed.

Replace : Level of opacity
With: opacity of activities allowed in the base

>  PART B - Opaque expressions:
>  Opaque BPEL expressions shall be allowed exclusively for the use
>of abstract processes. An opaque expression explicitly hides a

Replace: concrete
With : a corresponding executable

>  BPEL expression.
>  An example usage of an opaque expression is that of copying a
>hidden value into a known variable. Opaque assignment can be used to
>express non-determinism: the obvious case being a process that needs to
>  show a decision point with alternative outcomes without specifying how
>the decision is reached. In this case the expressions that constrain
>  each branch may need to be left unspecified, but it may also be
>  convenient to make a specific value or quantity such as a price
>  threshold unspecified, so that explicitly specified conditions
>  relative to the threshold become non-deterministic as a result of
>the threshold value being unknown.
>  All expressions in BPEL, and their corresponding opaque
>  representations are listed below:
>  1-Boolean valued expressions:
>  -Transition Condition: <transitionCondition
>  expressionLanguage="anyURI"? opaque="yes"/>

>  -Join Condition:

>  <joinCondition expressionLanguage="anyURI"? opaque="yes"/>

>-While Condition:
 > <condition expressionLanguage="anyURI"? opaque="yes"/>

>  -Switch Case Condition:

Add: Editor's Note: Update to reflect new if-then-else syntax.

 > <case>
 > <conditionexpressionLanguage="anyURI"? opaque="yes"/>
 > activity
 > </case>


>  2- Deadline valued expressions:


>  -Until element of onAlarm and wait:
 > <until expressionLanguage="anyURI"? opaque="yes"/>

Delete (moved to assignment section): Opaque assignment (<from 
opaque="yes"> is used for capturing
variable creation/modification in a yet-to-be-concretized mechanism/fashion

>  3- Duration valued expressions:

>  -For element of onAlarm and wait:
>  <for expressionLanguage="anyURI"? opaque="yes"/>

>  -repeatEvery element of onAlarm: <repeatEvery
expressionLanguage="anyURI"? opaque="yes"/>

>  4-

Replace: General Expressions
With: From-Spec in Assignment

Delete: Expressions in 'from-spec' in an assign activity:
<from><expression expressionLanguage="anyURI"? opaque="yes"/>

Replace: *Special case for generic opaque
assignment: <from opaque="yes">
With: <from expressionLanguage="anyURI"? opaque="yes"/>

>  is allowed, and represents hiding any of the forms of the

Add: Opaque assignment (<from opaque="yes"> is used for capturing
variable creation/modification in a yet-to-be-concretized mechanism/fashion.
>  See section 9.3.

Add: (editor’s note: update with any new expressions
from any new activities)

>  B.1

Replace: Level of opacity
With: Opacity of expressions allowed

>in the common base:
>  All BPEL expressions are allowed to be opaque.

Delete: The
generic form of opaque assignment is also allowed.

>  PART C - Opaque attributes:
>  An opaque attribute

Replace: hide
With: hides

>  the value of

Replace: a concrete
With: an executable

>  BPEL attribute.

>  For example, an opaque variable attribute in a receive activity

>  where the data is stored once the corresponding message is

>  The reserved value "##BPELopaque" shall be made available for use

>  the value of any BPEL attributes in a BPEL abstract process that

Replace: accept a QNAME or NCNAME. The reserved value's semantics are 
that it
is a placeholder for some other QName or NCName.

With: are allowed to be opaque.

Add: (editor’s note: this may change to make sure have a value for 
attribute types based on XSD.

>  C.1:

Replace: The level of opacity in
With: Opacity of attributes allowed in

>  the common base:

>All BPEL attributes are allowed to be opaque in the common base.

>  Rania's note on spec editing : if 82 passes, then A.1, B.1, and C.1

>  could go in the bullets of the common base where it says that it

>  depends on 107.




>  To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org For

>  additional commands, e-mail: wsbpel-help@lists.oasis-open.org

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