[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 242 - Allow/require onEvent's variable to bedeclared in <variables>? (Also, issue 241)
When I started 242, I was only intending to coalesce syntax, and leave
all semantics alone. But as I look at 241, I realize that 242 gives us
a great opportunity to actually fix some stuff that is unclear at best,
and most likely broken. Currently, an onEvent looks like (for clarity, only relevant portions are included): <onEvent partnerLink="ncname" messageType="qname" variable="ncname" messageExchange="ncname"? >* <correlationSets>? <correlationSet name="ncname" properties="qname-list"/>+ </correlationSets> <correlations>? <correlation set="ncname" initiate="yes|join|no"?/>+ </correlations> scope-activity </onEvent> Resolution/declaration occurs as follows: partnerLink - reference - resolved to parent scope - no ability to declare on onEvent correlation - reference resolved to onEvent/correlationSets - (note that this doesn't mean that the correlationSet be actually defined there, just that that's the resolution scope) correlationSets - declaration - may be used by correlation, or nested activities variable - reference AND declaration - variable and messageType/element constitute a declaration; variable alone constitutes a reference (to itself). messageExchange - I'm not sure - Alex's interpretation (in 241) conflicts with mine. I'll try to present them both, and apologies to Alex if I don't present his side well. Alex: "messageExchange: resolved to the associated scope only." What Alex seems to me to be saying here is that the messageExchange is both a declaration and a reference. This would be true for both the presence of a messageExchange, as well as the absence of one, due to our Default Message Exchange (DME) provided by onEvent. Thus an IMA has no possibility of crossing eventHander boundaries (in either direction). Danny: the messageExchange attribute is only a reference. As such, technically it resolves to the associated scope, since the associated scope has a DME. In reality, it resolves to a parent scope, if specified; and if not specified, it resolves to the associated scope. In 242, I propose that an eventHandler look like this (again, only including the relevant parts for clarity): <onEvent partnerLink="ncname" messageType="qname"? variable="ncname" messageExchange="ncname"?>* <correlationSets>? <correlationSet name="ncname" properties="qname-list"/>+ </correlationSets> <correlations>? <correlation set="ncname" initiate="yes|join|no"?/>+ </correlations> <partnerLinks>? </partnerLinks> <variables>? </variables> <messageExchange>? </messageExchanges> activity Option 1: We can keep the exact same resolution semantics. Option 2: Make all attributes be references only, with resolution on the onEvent scope (the messageType attribute would be removed): Resolution/declaration occurs as follows: partnerLink - reference - resolved to onEvent's <partnerLinks> element. This is a change, since there was no ability to have a <partnerLinks> element. partnerLinks - declaration - may be used by correlation, or nested activities - no change correlation - reference resolved to onEvent/correlationSets - (note that this doesn't mean that the correlationSet be actually defined there, just that that's the resolution scope) - No change correlationSets - declaration - may be used by correlation, or nested activities - no change variable - reference ONLY. variable resolves to onEvent's <variables> element. If no variable is declared there, then resolves to parent, as would be natural. This is a semantic change. variables - declaration - may be used by variable attribute, or nested activities - The use by the variable attribute is a semantic change messageExchange - reference ONLY. resolves to onEvent's messageExchanges. If no variable is declared there, then resolves to parent, as would be natural. This may or may not be a semantic change, depending on your previous interpretation. Option 3: Option 2 with backward compatibility of messageType/element attribute: variable - if messageType/element present, then variable is a reference AND a declaration as before. If messageType/element are not present, then use Option 2 resolution rules. ws-bpel issues list editor wrote:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]