[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel-spec-edit] Friendly amendments to issue 89 proposal
Satish,
I am ok with the text you come up with for 89. To put it into the context of section 6.2, the final change should be:
(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.
* ...
[[
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. Any platform component
that is required to interpret a BPEL process
definition MUST statically ensure that it supports all the queryLanguage
and expressionLanguage attribute values used in the process definition.
If it does not support one or more such values it MUST reject the
process definition.
]]
...
If Yaron and others agree with the text and location, I can incorporate the text to the spec.
That takes care of issue 89.
I also want to add a big +1 to Alex's suggestion for defining the different processors. Throughout the spec, we are talking about quite a few different things. Here we are actually defining a conformant behavior of a "platform component", whereas in section 6.4, we are talking about some "processor". The terms "runtime engine", "engine", "process engine" are also used in different places. As Alex already pointed out issue 9 also needs a better definition of the terms.
It would be good if we can clarify what are the conformance targets of the spec and define such targets clearly. At the minimum, the terms need to be reconciled. This might be addressed as part of issue 9, or should a new issue be opened?
Best Regards,
Kevin
-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com]
Sent: Monday, Oct 25, 2004 09:26 PM
To: Alex Yiu; Liu, Kevin
Cc: ygoland@bea.com; bpel spec
Subject: RE: [wsbpel-spec-edit] Friendly amendments to issue 89 proposal
I had the same concern as Alex re static analysis.
In the spec at present we seem to allow "targeted override" (at
query/expression usage points) rather than "global override" (at the
activity level) of the {query,expression}Language default. We should
not change that as an editorial correction. So I take that concern
back.
So then I would say that
Any platform component that is required to interpret a BPEL process
definition MUST statically ensure that it supports all the queryLanguage
and expressionLanguage attribute values used in the process definition.
If it does not support one or more such values it MUST reject the
process definition.
Where exactly should this go? Good question.
Satish
-----Original Message-----
From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Monday, October 25, 2004 5:52 PM
To: Liu, Kevin
Cc: 'ygoland@bea.com'; bpel spec; Satish Thatte; Alex Yiu
Subject: Re: [wsbpel-spec-edit] Friendly amendments to issue 89 proposal
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
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]