[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 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.
>>
>
> *[AYIU]*:
> "<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?
>
>
> Thanks!
>
>
> Regards,
> Alex Yiu
>
>
>
>>
>>> 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
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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]