[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 clean-up/editorial/consistency): 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 activities, 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 activity) > 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> With: <opaqueActivity standard-attributes> standard-elements </opaqueActivity> > > 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 >'from-spec'. 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 hides > where the data is stored once the corresponding message is received. > The reserved value "##BPELopaque" shall be made available for use as > 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]