Re: [wsbpel] Issue 82.1 - questions about bullets in proposal.

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

Hi guys

I have some very specific questions about parts of the directional proposal:

1) The opacityOmissionUsed came up in the discussion for 82, but was not 
included in the resolution nor was it in the . I don't recall whether we 
agreed to move it to this issue and the section in the resolution on 
'open issues after resolution of 82' doesn't mention it although the 
e-mails did raise it for discussion. So I am assuming that means it was 
  not accepted ? Am I missing some e-mails where we agreed to move it to 
82.1 ? Or are you proposing it newly here again ?

2) The third bullet child of the second bullet, about the 3 kinds of 
opaque constructs, should just say 'the opaque constructs are those in 
107' - Otherwise, we'll be dealing with two places defining 107 and 
that'll be a mess to keep track of. For example, the first bullet is 
actually incorrect ! The 'createInstance' attribute is NOT allowed on 
<opaqueActivity> (see 107, 99). The third bullet about expressions omits 
a few (condition of 'while' , etc).

3) can you please explain more about the rational behind the three 
schema design instead of deriving the AP schema from the EP schema ? I'm 
not against any of them, I just want to understand the motivation 
especially since the text talks about AP as derived from EP so that 
seemed more natural..

4) i still have a couple of questions about the two namespace idea, but 
I will put those in a separate e-mail to follow up with that discussion



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
> 
>