OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel-spec-edit message

[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


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/wsbpel-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]