Hi Rania,
[1]
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).
[2]
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?
Regards,
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.
*[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
|