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

resending, server trouble.

-------- Original Message --------
Subject: Re: [wsbpel] Issue 82.1 - questions about bullets in proposal.
Date: Tue, 06 Dec 2005 17:55:02 -0500
From: Rania Khalaf <rkhalaf@watson.ibm.com>
To: Alex Yiu <alex.yiu@oracle.com>
CC: wsbpeltc <wsbpel@lists.oasis-open.org>,  Rania Khalaf 
<rkhalaf@us.ibm.com>, Danny van der Rijn <dannyv@tibco.com>,  Ron 
Ten-Hove <Ronald.Ten-Hove@Sun.COM>, "'Monica J. Martin'" 
References: <437FC590.5020609@oracle.com> 
<4395B0F9.3060806@watson.ibm.com> <43960850.1060904@oracle.com>

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

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 ?

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

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


> Thanks!
> Regards,
> 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
>>>                   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
> ---------------------------------------------------------------------
> 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 
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

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