[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 82.3 - Clarification to the base, and change to template profile
Hi everyone, While going through the missing section on 82.3, there was confusion regarding the use of default values. The confusion was because the text in the base about default values and omission is spread out over several sections. Alex, Danny and I worked on adding a clarification in the base to succinctly spell out what happens to constructs with defaults in an Executable Completion, and to highlight the effect of that on the ability to add new links. The clarification is also referred to now by the newly edited text for the lost section of 82.3. This requires a fix in the template profile: the template profile today allows one to set the value of 'validate' if it is omitted in the AP. With the clarification, it can be changed if it is explicitly opaque, and there is a note about tools. I'm not sure what the right way to address this is (open an issue for both ? for one ? ) We can discuss that in the call tomorrow. In the meantime, here is the text that we have crafted to provide a solution to both things. Here are the pdf and word versions, with track changes on: http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/18967/EC-clarification_EDITED.pdf http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/18968/EC-clarification_EDITED.doc ** AFTER** THE EC definition (unchanged), we add the two paragraphs starting 'A clarification ..'. New Clarification in BaseAn Executable Completion of an Abstract Process is defined as an Executable Process that1.
is derived only by: a)
Changing the namespace to that of Executable WS-BPEL and removing the profile URI. b)
Using some combination of the following syntactic
transformations:
i.
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>.
ii.
Addition of WS-BPEL constructs:
Adding new WS-BPEL XML
elements anywhere in the process. 2.
is a valid Executable WS-BPEL process that satisfies all static
validation rules mandated by this specification including both
schema-based and
non-schema-based rules. A clarification is provided here regarding the completion rules and
their
application to constructs with default values in the Abstract Process,
such as
“createInstance” at <receive>, “validate” at <assign> and
<joinCondition> within <targets>. The completion rules
above do not
allow changing non-opaque constructs when creating an executable
completion
(whether through omission-shortcut or explicitly). As
stated in section "13.1.3. Hiding
Syntactic Elements", a construct, which is not explicitly present in
the
abstract process and has a default value, is not allowed to be made
opaque
through omission-shortcut. Its value will be that of the default in all
executable completions (e.g.: “no” for an omitted “suppressJoinFailure”
attribute). Therefore,
specifying its value in an executable completion is not covered by
“Addition of
WS-BPEL constructs.” In order to allow Execution Completion to specify
the
value of such constructs, explicit opaque tokens should be used in the
Abstract
Process. Completions can then specify
the values specified using “Opaque Token Replacement”. This is especially relevant to the addition of links. New links
cannot be
added as targets to existing activities with at least one link if such
an
addition changes an existing, non-opaque join condition (including the
default
join condition). The default join
condition is included in this consideration because adding a new link
to an
activity using the default join condition effectively changes the
condition to
include the new link’s status. Examples where new links can be added
include
adding them to: 1) an activity with no existing incoming links, 2) an
activity
with incoming link(s) and an opaque join condition, or 3)
an activity with incoming link(s) and an
explicitly specified, non-opaque join condition (whose value cannot be
changed
in any executable completion). New Changes in Template Profile:
1) Drop the bullet about <assign> under "13.4.4. Adding
Constructs without explicit opacity". And add a clarification after all
the bullets: A tool, which generates Abstract Processes of Template Profile based
on user
inputs, is expected to use explicit opaque tokens to denote the
constructs with
default values (e.g. validate attribute at <assign>) in the
generated WS-BPEL
Abstract Processes, when users of the tool do not specify any values
for those
constructs. In the WS-BPEL Abstract
Process itself, omitting such a construct is, as usual, equivalent to
specifying
it using the default value.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]