[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'"
<Monica.Martin@Sun.COM>
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
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 ?
> 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.
ok
>
>
> 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
> OASIS
> 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]