Great. I will apply the changes tonight when I get CVS access at home.
Best Regards,
Kevin
-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com]
Sent: Wednesday, Oct 27, 2004 02:41 PM
To: Liu, Kevin; ygoland@bea.com; Alex Yiu
Cc: bpel spec
Subject: RE: [wsbpel-spec-edit] Friendly amendments to issue 89 proposal
I am fine with Yaron's text, except for the nit that queryLanguage is
used in WSDL for defining property aliases not properties :-)
OK to put in 6.2 for now. Later on we probably need to reorganize to
merge this type of stuff with section 3 but that is not something to
take on right now.
Satish
-----Original Message-----
From: Liu, Kevin [mailto:kevin.liu@sap.com]
Sent: Wednesday, October 27, 2004 12:03 PM
To: Satish Thatte; ygoland@bea.com; Alex Yiu
Cc: bpel spec
Subject: RE: [wsbpel-spec-edit] Friendly amendments to issue 89 proposal
OK, We need to move on with this.
First, let's see if we can agree on the location. Do we all agree that
section 6.2 is the right place given the change is applicable to both
abstract and executable process (note section 14 is only for executable
process)?
As for the text, personally I like Yaron's version better since it fits
into the context of section 6.2 and re-uses the "processor" term instead
of introduce another one. It also clarifies the case for WSDL.
Satish, do you agree that we can move on with Yaron's text as the base?
Best Regards,
Kevin
-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com]
Sent: Tuesday, Oct 26, 2004 03:18 PM
To: ygoland@bea.com; Alex Yiu
Cc: Liu, Kevin; bpel spec
Subject: RE: [wsbpel-spec-edit] Friendly amendments to issue 89 proposal
The executable/abstract distinction is not relevant here. The only
point we are trying to make is that you MUST *statically* determine if
you can FULLY understand the process definition before you do anything
with it. In other words, the various language attributes have
"mustUnderstand" status.
-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com]
Sent: Tuesday, October 26, 2004 3:12 PM
To: Alex Yiu
Cc: Liu, Kevin; bpel spec; Satish Thatte
Subject: Re: [wsbpel-spec-edit] Friendly amendments to issue 89 proposal
When I wrote 89 the status of abstract processes was unclear so I stuck
to just addressing executable processes. Officially speaking nothing has
changed in the status of abstract processes but I believe that the
direction we have been heading is to define some level of syntax
conformance requirement for abstract processes (e.g. it will be possible
to perform non-trivial static analysis of an abstract process). The
consequence of this is that it makes sense to apply 89 to both abstract
and executable processes and it therefore makes sense to move the text
to a section that applies to both types of processes, section 6.2 seems
like a good candidate.
I also agree with Alex's concerns. I think the proposed language may
have unintentional implications that could complicate things.
I therefore propose that we edit your proposed language to read:
The value of the queryLanguage and expressionLanguage attributes on the
process XML element are global defaults and can be overridden on
specific activities like assign using the mechanisms defined later in
this specification. In addition the queryLanguage attribute is also
available for use in defining BPEL properties in WSDL. BPEL processors
MUST:
* statically determine which languages are referenced by queryLanguage
or expressionLanguage attributes either in the BPEL process definition
itself or in any BPEL property definitions in associated WSDLs and
* if any referenced language is unsupported by the BPEL processor then
the processor MUST NOT process the submitted BPEL process definition.
What do y'all think?
Yaron
Alex Yiu wrote:
Hi Kevin,
Thanks for the update.
The wordings of "the processor MUST stop processing the process" seems
to imply that the BPEL implementation will behave like an interpreter,
when the implementation is an executation engine. It looks like that
the
processor stops processing only after it discovers the
expression/query
language support problem.
Does it imply that a BPEL execution engine implementation should not
do
static analysis?
Or, I am just reading too much into the intention of the sentence?
One way or the other, I think it would be better to put addtional
sentences to explicitly state that whether static analysis may/must be
performed to detect this error condition.
And, if an execution engine implementation is ever allowed to discover
this problem on the fly in the middle of the process execution, then a
runtime fault may be needed.
Instead of have one vague statements that covers all kinds of BPEL
processors. We may want to have some terms introduced: e.g. BPEL
execution processor and BPEL analysis processor (which do static
analysis and other analysis without executing the BPEL process). Then,
our description against different kinds of processors can be more
precise.
I think these 2 terms are needed also, when we want to give a context
for Issue 9.
Thanks!
Regards,
Alex Yiu
Liu, Kevin wrote:
>Hi Yaron and all,
>
>There was a brief discussion on 89 in the editors' call last week.
Since Yaron
had already been swamped with many issues, the group felt obligated to
take some
burden from his shoulder, and somehow I ended up with an AI to come up
with new
text to address some concerns Satish brought up.
>
>Here is the strawman proposal I would like to you to bring up for
your
consideration. Though the changes might appear violent (at least more
than I was
thinking), I believe the principal idea is the same as the initial
proposal.
>
>To be honest, I don't have a strong feeling on this issue and am
totally open
for any suggestions. Please just send me (or to the editor's group
directly)
your wording if you have a preference.
>
>
>The issue:
>===============
>Handling Unrecognized Query/Expression Languages - What is a BPEL
engine to do
if the query/expression language identifier given in
queryLanguage/expressionLanguage attributes are unrecognized?
>
>Initial Proposal:
>================
>From: "Yaron Y. Goland" <ygoland@bea.com>
>To: wsbpeltc <wsbpel@lists.oasis-open.org>
>Date: Wed, 15 Sep 2004 18:16:31 -0700
>
>Add the following language to the end of section 14.1:
>
>If the value of a queryLanguage or expressionLanguage attribute in a
>BPEL executable process identifies a language that the execution
engine
>does not support then the execution engine MUST NOT execute the BPEL
>process.
>
>Concerns from Satish:
>====================
>1. The wording sounds like that it only applicable to "execution
engine".
Actually the logic should be applicable to any thing that deals with a
BPEL process
>
>2. Need to clarify that this is not only concerned with the two
attributes in
the root element, but to all levels
>
>My strawman amendments:
>==============================
>The issue called out "BPEL engine", but if I understand Satish's
concern
correctly, he thinks the proposal should work for all BPEL processors
and to all
levels of BPEL elements. How about the following?
>
>1. The location
>The proposal is to change section 14.1. In the latest draft, section
14.1 only
deals with executable extensions for expressions.
http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/9094/w
sbpel-specification-draft-Sept-08-2004.html#s.Extensions.top
>
>Since the issue address both query language and expression language,
and is
general for both abstract and executable processes, I feel section 6.2
is a
better place to address this general issue.
>
>2. The text
>
>Change the following section in 6.2 to add a paragraph (proposed
changes
marked with [[...]])
>
>The top-level attributes are as follows:
>
>* queryLanguage. This attribute specifies the default XML
query
language used for selection of nodes in assignment, property
definition, and
other uses. The default value for this attribute is XPath 1.0,
represented by
the URI of the XPath 1.0 specification:
http://www.w3.org/TR/1999/REC-xpath-19991116.
>
>* expressionLanguage. This attribute specifies the
expression language
used in the process. The default for this attribute is XPath 1.0,
represented by
the URI of the XPath 1.0 specification:
http://www.w3.org/TR/1999/REC-xpath-19991116.
>
>* suppressJoinFailure. This attribute determines whether the
joinFailure fault will be suppressed for all activities in the
process. The
effect of the attribute at the process level can be overridden by an
activity
using a different value for the attribute. The default for this
attribute is
"no" at the process level. When this attribute is not specified for
an
activity, it inherits its value from its closest enclosing activity or
from the
process if no enclosing activity specifies this attribute.
>
>* abstractProcess. This attribute specifies whether the
process being
defined is abstract (rather than executable). The default for this
attribute is
"no".
>
>[[
>The value of the querLanguage attribute and the value of the
expressionLanguage attribute at the process level can be overridden by
an
activity using a different value for that attribute. If the specified
query or
expression language is not supported by a processor which has to deal
with the
relevant query or expression, the processor MUST stop processing the
process.
>]]
>
>...
>
></new>
>
>Please note the term "processor" is already used in section 6.4, so
I am not
inventing a new term for this issue, though a separate issue might be
opened for
defining what a "processor" is.
>
>Thoughts?
>
>Best Regards,
>Kevin
>
>