OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Hi Rania,

Rania wrote:
"The objections included the idea that adding createInstance=yes to the opaque activity makes it 'semi-opaque'"

Can you remind me of who were having this opinions? I am quite sure it was not Yaron, the original issue filer.  I really do not recall any discussion on that front in my memory, and I have been involved in opaque construct from the very beginning.

opaqueActivity is never 100% opaque. It has standard elements and attributes (e.g. control-links related constructs) attached to them. When one opaqueActivity has a transition condition, it usually implies that activity would result in a change in the variables used in the transition condition.

Rania wrote:
"direct opposition with the resolutions of 107, 99, and 82"

Can you point out that which part of these resolution are against having createInstance in opaqueActivity explicitly ??

In resolution 107, there is no explicit wording that disallow opaque activity as the start activity.

On the other hand, I would say dis-allowing opaqueActivity as the start activity is heading opposition of the intention behind Issue 107, of which main object is to allow people to use an explicit opaque token to hide execution details in AP. Oblivously, it should cover start activity as well.

This situation is similar to whether BPEL's <import> can import non WSDL / non XSD artifacts. Its intention seems to allow import of other kinds of document but the current syntax grammar disallows it.  It seems to me that both cases are syntax design overlook (aka bug).

For "opacityOmissionUsed" attribute, Issue 82.1 is all about finalizing syntactic details of AP and EP. Its subject is:  "Syntax and Schema Validation Design for Abstract and Executable BPEL"

"opacityOmissionUsed" does not change any semantics of AP. That attribute is a pure syntax validation facility.  If "opacityOmissionUsed" does not belong to 82.1, where does it belong to?

Alex Yiu

Rania Khalaf wrote:

Hi  Alex,

I see both of these issues as ones that were discussed and debated as parts of 99 and 82/107 and not included in the final resolutions. I am dismayed that they are showing up here again as bug fixes and such.

I distinctly remember the discussion about createInstance. The objections included the idea that adding createInstance=yes to the opaque activity makes it 'semi-opaque' because it means it must be receive or pick. I think this is in direct opposition with the resolutions of 107, 99, and 82. It was also discussed in light of 99 and again not included in the resolution.

As for the opacityOmissionUsed, I just recall that there was no interest in including it in 82 and it was not added into the proposal for lack of interest.

These issues are not part of schema design and as far as I know where already resolved.   Their technical merits have already been discussed (or not due to lack of interest) and the related issues were voted on WITHOUT any major changes having happened to the main premises upon which they were based in the meantime.

Either way, 82.1 is not the home for them.

Alex Yiu wrote:

Hi Rania,

See below ...

Rania Khalaf wrote:

Hi ,

pls see below

Alex Yiu wrote:

Hi Rania,

I am glad that the conversation of this thread is becoming a technical discussion again, rather than a religion-like argument. Thank you very much for steering to that direction. :-)

For 1),
"opacityOmissionUsed" has not been in a formal proposal yet in any previous 82.* proposal. "opacityOmissionUsed" is added based on the other email thread between you and me (around Nov 8). You were suggesting instead of duplicating chunks of schema for opacity omission: let's assume people (implementing Abs BPEL) inject those omitted opacity first before submitting it to schema validation. I expressed that I am OK with that idea. Instead of asking a profile-independent Abstract BPEL implementation guessing whether it needs to do such an injection based on profile URI, let's mark the abstract profile explicitly. That's the reasoning behind this "opacityOmissionUsed" attribute.

Hi, This was in http://lists.oasis-open.org/archives/wsbpel/200504/msg00051.html

where I presented your idea to the list, but I can't find any responses and it did not make it into the 82 proposal. The inject-then-validate approach is fine, but why is the attribute there and why is it part of 82.1 which is about Schema design ?

Do you have the info on what we agreed would happen to this attribute after it came up in 82 ?

*[AYIU]*: Thanks for digging that email up. I guess that email summarized the situation about that switch well. We mentioned about that idea but there were not enough follow up discussion on that switch.

Yes, 82.1 is about schema design and how to use syntax, schema and grammar differentiate AP and EP. Based on our Nov discussion on the "inject-then-validate" approach, the value of having that switch is more visible now. Hence, I am proposing we need that switch for us to have a cleaner approach to deal with "inject-then-validate" logic without knowing details of the profile URI.

For 2),
Your suggestion makes sense. I should make a reference to Issue 107.

On the other hand, 'createInstance' is a normative bug fix that I want to use Issue 82.1 to fix Issue 107 resolution. Recently, we realized that we cannot use opaqueActivity to model a start activity, if "createInstance" is not available. So, that is a real bug in Issue 107 resolution and we need to fix this.

For "the third bullet about expressions omits a few (condition of 'while' , etc)" ... those are just examples, in this direction vote, not exhausive list. :-)  The exhausive list will show up in the final proposal to vote for this issue.

I don't see this as a bug fix. We had this discussion already, and the base allows omission of a receive that creates an instance. We had the discussion specifically about this and decided against it because it is a 'partially opaque' activity. If you want to do this, then you can do
<receive createInstance="opaque" operation="opaque" etc etc>  or just omit the activity all together.

"<receive createInstance='opaque' operation='opaque' etc etc>" would not work in all cases. Sometimes people want to use <pick> instead of <receive> as the start activity. People may not want to decide whether they want to use <pick> or <receive> in their AP.

In some AP profiles, the start activity can be omitted all together. However, the whole point of having an opaque activity as the start activity is to use as a place holder to attach other tools-info and control-links related info to it. Omitting the start activity is not the universal solution.

I am not sure why you oppose allowing opaque activity as the start activity. What are technical reasons behind this opposition?


Alex Yiu

For 3) and 4), I will try to discuss them further in the other email thread.



Alex Yiu

Rania Khalaf wrote:

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
                + 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
                        <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
                      # 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.


Alex Yiu

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]