Some encouraging tests with Chuck's prototype

["Jacques R. Durand" <JDurand@us.fujitsu.com>]

 

I tried some usage variations on Chuck's prototype:

 

- using the "catch2.etsm" script, which is a simplified version of our "application Use Case #2" http://wiki.oasis-open.org/tamie/UseCaseItems

 

The case consists of iterating over a sequence of POs in the log, and for each one of these, "catching" their ConfirmPO event. These ConfirmPO could be logged much later, in  any order, be missing, etc.

 

The script demonstrates well:

 

- a simple implementation of CATCH operator, within a var declaration and within a loop.

- asynchronous start of a sub-scriplet inside a loop (tracking the ConfirmPO of a single PO). That is impressive !!

- time duration checking using powerful XPath date functions library. That is very encouraging: these libs are very useful for monitoring events !

- output on standard output using the "message" statement.

 

I could verify that the script behaves well when modifying the log of events: reordering the ConfirmPO , changing the dates...

For example:

 

An initial run of "catch2.xsl" gives on your standard output:

 

>Confirmation received for PO Name1
>No conf event for Name2 recieved within 10 minutes of the PO
>Confirmation received for PO Name3

 

NOTE: to do this, I used my little SaxonB "xslt.bat" here attached, that you can customize to your own installation of Saxon.

 

Using my own script I did:

 

>xslt etsm_translator.xsl  catch2.etsm catch2.xsl

>xslt catch2.xsl events.xml

 

Then in events.xml, just change the timing of the last event

<emam:event id="5" post-time="2007-06-13T13:33:53-07:00"> instead of:

 <emam:event id="5" post-time="2007-06-13T13:13:53-07:00">

(meaning confirmation event received 20mn later after the PO)

 

You should get:

 

>Confirmation received for PO Name1
>No conf event for Name2 recieved within 10 minutes of the PO
>No conf event for Name3 recieved within 10 minutes of the PO

Works well !

 

Also, instead of generating output on the standard output: I replaced the <message> statements with ad-hoc markup to be "effected" this time in a result file (results.xml):

 

>xslt etsm_translator.xsl  catch2.etsm catch2.xsl

>xslt catch2.xsl events.xml results.xml

 

------------- content:

 

<abc:results xmlns:abc="abcabc" xmlns:myns="myns" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xyz="xyz" xmlns:translator="translator" xmlns:emam="http://docs.oasis-open.org/tamie/emam/draft/20090909" xmlns:etsm="http://docs.oasis-open.org/tamie/etsm/draft/20090909" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://docs.oasis-open.org/tamie/etsm/draft/20090909">
<abc:messg>Confirmation received for PO Name1</abc:messg>
<abc:messg>Confirmation received for PO Name2</abc:messg>
<abc:messg>No conf event for Name3 recieved within 10 minutes of the PO</abc:messg>
</abc:results>

 

The beauty of it, is that the outermost element <abc:results> is effected in the main scriplet and contains the loop.

The inner elements <abc:messg> are effected inside the sub-scriplet (meaning inside the loop) at each iteration.

 

Superb !

 

-jacques

ScanMail detected and removed a file that violated policy from the original mail entity. You can safely save or delete this replacement attachment.