Re: <catch> and @tryfor

[Marius Plavan <marius.edtf@gmail.com>]

In my previous mail: total time spent should have been = T0 + T1 + P3DT12H.

After putting more time on this, the catch/@tryfor description adheres to what one would expect (so my previous uncertainty about Step 2 and @tryfor is no longer there if one reads the below):
---Section 4.7.3
catch/@tryfor: a duration that indicates how long the catch operation may "try" to select an event
(or a combination of) that satisfies the defined pattern
---

So basically, in "deferred mode" and "live mode", the important thing is that the user specified @tryfor value is part of the "compound condition" (i.e. the XPath query which will be executed on all the events from the Event Board).

In "live mode", the "compound condition" stays the same, but additionally I need another (internal XSLT) variable (let's call it timeSpentWithCatching) to keep count on the overall time spent inside <catch>.
When timeSpentWithCatching > @tryfor, than the "event manager" running in the extension function will stop querying for events.

Merry Christmas,
Marius Plavan

On Wed, Dec 21, 2011 at 8:51 PM, Marius Plavan <marius.edtf@gmail.com> wrote:

Hi all,

Regarding the catch/@tryfor attribute, I would like to raise a few questions.
The "catch timeout" handling for XTemp / "Live mode" is about to be implemented in edtf, so I would like to clarify some uncertainties that I have.

Let's take a simple example:
---
<catch eb="POs" tryfor="P3DT12H" >
   <match event="PO"<condition>...</condition></match>
</catch>
---
In the above case, this means that <catch> will block for the specified duration. Crystal clear.

Now we take a more complex example (although the below is not currently supported by edtf), which contains more <match> elements:
---
<catch eb="POs" tryfor="P3DT12H" >
   <match event="PO"<condition>...</condition></match>
   <match event="POresponse" after="PO"<condition>...</condition></match>
   <match event="POreceipt" after="POresponse"<condition>...</condition></match>
</catch>
---
For the above <catch>, lets assume "PO" is catched at T0, Does this imply that POresponse should be catched in P3DT12H or (P3DT12H - T0) ?

In XTemp spec, section 4.7.3, Step 2, the answer seems to be pretty clear:  "the event occurs before the catch timeout (@tryfor)" (i.e. in the 2nd example, POresponse should be catched in P3DT12H).
This means that if POresponse will be catched at T1 and POreceipt will not be catched, the event pattern was not found (total time spent = P3DT12H + T1 + P3DT12H) and a new event pattern will be initiated with "PO".

But long time ago when I first saw a <catch> with @tryfor, it was in an XTemp script.
Only by looking at the <catch> (and without reading the spec), I had a (high) expectation that @tryfor applies for the entire <catch> (i.e. in the 2nd example, POresponse should be catched in P3DT12H - T0).
This expectation came from the fact that @tryfor was a <catch> attribute, not a <match> attribute.
So, if this feeling is shared by more of us, I would kindly ask if either one of the below can be an option for the future..
 - make @tryfor available only as part of the <match>, which would give the user extra flexibility in specifying timeouts inside a catch or
 - leave @tryfor where it is now and make it also available for <match>, which would make things backward compatible at a syntactic level but not on a semantic one (as catch/@tryfor timeout will apply to all <match> statements cumulatively) or
 - change @tryfor name to better reflect the fact that the timeout applies for each <match>

Thank you in advance for your answers.

Best regards,
Marius Plavan