Re: [wsbpel] Issue 82.1 - proposal to vote (directional vote)

[Rania Khalaf <rkhalaf@watson.ibm.com>]

Hi guys,

If we agree about the schema of abstract will only add the opaque tokens 
then I don't see any motivation any more for 24's resolution .

Is it really worth all the pain of xsd:redefine and managing three 
schemas instead of just saying in the text that you can only use 
abstract tokens in AP ?

regards,
Rania


Alex Yiu wrote:
> 
> 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:
>           o a required URI-type "*profile*" attribute at <process> element
>           o 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")
>           o 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:
>           o All 3 kinds of opaque constructs are disallowed.
>           o There will be no "profile" or "opacityOmissionUsed"
>             attributes at the <process> level.
>     * How XML Schema are applied:
>           o 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" />
>           o 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
> 
>