[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
no, same text same section :-) i just suggested a
minor nit-level correction and a possible move to a different section when we
reorg the whole spec.
From: Alex Yiu [mailto:alex.yiu@oracle.com] Sent: Wednesday, October 27, 2004 3:45 PM To: Liu, Kevin Cc: Satish Thatte; ygoland@bea.com; bpel spec; Alex Yiu Subject: Re: [wsbpel-spec-edit] Friendly amendments to issue 89 proposal Ok. I got a bit confused after all these emails. :-) Just a clarification. It will be basically the same text from Yaron but just ending up in a different section? Right? Regards, Alex Yiu Liu, Kevin wrote: 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 thattheprocessor stops processing only after it discovers theexpression/querylanguage support problem. Does it imply that a BPEL execution engine implementation should notdostatic 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 moreprecise.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 Yaronhad already been swamped with many issues, the group felt obligated totake someburden from his shoulder, and somehow I ended up with an AI to come upwith newtext to address some concerns Satish brought up. > >Here is the strawman proposal I would like to you to bring up foryourconsideration. Though the changes might appear violent (at least morethan I wasthinking), I believe the principal idea is the same as the initialproposal.> >To be honest, I don't have a strong feeling on this issue and amtotally openfor any suggestions. Please just send me (or to the editor's groupdirectly)your wording if you have a preference. > > >The issue: >=============== >Handling Unrecognized Query/Expression Languages - What is a BPELengine to doif 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 executionengine>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 "executionengine".Actually the logic should be applicable to any thing that deals with aBPEL process> >2. Need to clarify that this is not only concerned with the twoattributes inthe root element, but to all levels > >My strawman amendments: >============================== >The issue called out "BPEL engine", but if I understand Satish'sconcerncorrectly, he thinks the proposal should work for all BPEL processorsand to alllevels of BPEL elements. How about the following? > >1. The location >The proposal is to change section 14.1. In the latest draft, section14.1 onlydeals 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 isgeneral for both abstract and executable processes, I feel section 6.2is abetter place to address this general issue. > >2. The text > >Change the following section in 6.2 to add a paragraph (proposedchangesmarked with [[...]]) > >The top-level attributes are as follows: > >* queryLanguage. This attribute specifies the default XMLquerylanguage used for selection of nodes in assignment, propertydefinition, andother uses. The default value for this attribute is XPath 1.0,represented bythe URI of the XPath 1.0 specification: http://www.w3.org/TR/1999/REC-xpath-19991116. > >* expressionLanguage. This attribute specifies theexpression languageused in the process. The default for this attribute is XPath 1.0,represented bythe URI of the XPath 1.0 specification: http://www.w3.org/TR/1999/REC-xpath-19991116. > >* suppressJoinFailure. This attribute determines whether thejoinFailure fault will be suppressed for all activities in theprocess. Theeffect of the attribute at the process level can be overridden by anactivityusing a different value for the attribute. The default for thisattribute is"no" at the process level. When this attribute is not specified foranactivity, it inherits its value from its closest enclosing activity orfrom theprocess if no enclosing activity specifies this attribute. > >* abstractProcess. This attribute specifies whether theprocess beingdefined is abstract (rather than executable). The default for thisattribute is"no". > >[[ >The value of the querLanguage attribute and the value of the expressionLanguage attribute at the process level can be overridden byanactivity using a different value for that attribute. If the specifiedquery orexpression language is not supported by a processor which has to dealwith therelevant query or expression, the processor MUST stop processing theprocess.>]] > >... > ></new> > >Please note the term "processor" is already used in section 6.4, soI am notinventing a new term for this issue, though a separate issue might beopened fordefining what a "processor" is. > >Thoughts? > >Best Regards, >Kevin > > |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]