Hi, all,
Here is the summary of direction on how Abstract and Executable Process
differ syntax-wise and how XSD would be applied to capture those
differences:
- As per Issue 24 resolution, there will be two namespaces: one for
executable; one for abstract
- For abstract process:
- a required URI-type "profile" attribute at
<process> element
- a required "boolean"-type ("yes"/"no") "opacityOmissionUsed"
attribute at the <process> element: It indicates whether opacity
omission is used. (See more details below in "How XML Schemas are
applied")
- Introducing 3 kinds of opaque constructs:
- opaque activity: <opaqueActivity>: its structure would
be similar to an <empty> activity but with an additional
"createInstance" attribute
- opaque attribute value: "##opaque": that will be allowed to
be used in almost any existing BPEL attribute construct (include ones
based on NCNAME, QNAME, URI, and etc).
- opaque expression: e.g. the opaque version of from-spec:
<from opaque="true" /> and condition expression used in
"if-then-else".
- For executable process:
- All 3 kinds of opaque constructs are disallowed.
- There will be no "profile" or "opacityOmissionUsed" attributes
at the <process> level.
- How XML Schema are applied:
- Usage of "opacityOmissionUsed":
- This required attribute indicates whether opacity omission is
used in the Abstract Process.
- If opacityOmissionUsed is set to "yes", a WS-BPEL processor
may (intentionally lower
case) need to add opacity token first before attempting to use
the XML Schema for Abstract Process to validate the XML source of the
abstract process. Without adding opacity tokens first, the Abstract
Process may be deemed to be invalid according to Abstract Process
schema.
- If opacityOmissionUsed is set to "no", opacity
omission MUST NOT be used in the abstract process.
- The Abstract Process schema does not attempt make constructs
required
by Executable Process optional. Instead, it makes opaque construct
available to fill in those undecided details required by Executable
Process.
- Examples:
- An empty sequence of this form:
<sequence />
MAY be used within an A.P. with opacityOmissionUsed set to "yes" only,
while the following form of sequence MAY be used within an. A.P.
regardless of its opacityOmissionUsed value:
<sequence> <opaqueActivity />
</sequence>
- A variable declaration of the this form:
<variable name="varX" />
MAY be used within an A.P. with opacityOmissionUsed set to "yes" only,
while the following form of variable declaration MAY be used within an.
A.P.
regardless of its opacityOmissionUsed value:
<variable name="varX" element="##opaque" />
- XML Schema files: we would attempt an XML-schema approach which
avoids massive grammar definition duplication, as described below:
- The current main BPEL XSD file will be spilt into 3 pieces:
- wsbpel_common_main.xsd: which serve as the common base of
BOTH executable and abstract process. It will not have a
targetNamespace.
- wsbpel_exec.xsd and wsbpel_abstract.xsd: These two XSD
files will have their own targetNamespace (one for executable, one for
abstract). These XSD files will reuse the definition of BPEL grammar
from wsbpel_common_main.xsd by <xsd:redefine>. The delta between
abstract and executable BPEL will be captured within the
<xsd:redefine> section of these XSD files.
Thanks!
Regards,
Alex Yiu
|