about eTSM variables

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

There are two major ways to assign a value to an eTSM variable:

 

(1) the "embedded" way. This is illustrated in Chuck example (Use Case #1).

 

<etsm:var name="event">
        <etsm:catch>
        ....       

        </etsm:catch>
 </etsm:var>

or, for atomic values:

 

<etsm:var name="convId">100</etsm:var>

 

The result of the catch operation (i.e. a set of selected events) will be assigned to the var $event.

 

(2) the "expression" way. Here, an expression (usually XPath) is evaluated, the result of which is assigned to the variable:

 

<etsm:var name="totalamount" expr="(some XPath expression)" [ language="XPath20" ] />

E.g.:

<etsm:var name="POref" expr="'P1234'"/>

 

Both seem to be valuable, used in Use Case #1 proposal from Chuck, and easy to translate into XSLT.

So overall I am in favor of eTSM supporting both.

 

 

A few issues to discuss however:

 

======== issue A : assignment semantics

 

The problem with notation (1) is that it is expected that the embedded element  <etsm:catch> is evaluated before being assigned. In fact, it is just another form of (2), where <etsm:catch> is used instead of the "expression".

What if we want to assign an XML fragment to the variable, without executing it?

E.g.:

<etsm:var name="PO" >
        <myapp:PurchaseOrder ref="1234">
           <myapp:Item>abc</myapp:Item>

        </myapp:PurchaseOrder>
 </etsm:var>

Solution #A1: expect the eTSM engine to decide what to do based on the  namespace: an etsm-qualified element will always be executed first, while any other namespace will not.

Problem: what if we want to assign an <etsm:xyz> element to a variable without executing it? (e.g. for debugging, or tracing, or for a more detailed report, etc. and also for maybe some script generation capability)

 

Solution #A2: same as for #1 but an aditional @process attribute will override the default behavior.

In teh following, the <etsm:catch> element is NOT executed and is assigned as is as value for $event:

 

<etsm:var name="event" process="false">
        <etsm:catch>
        ....       

        </etsm:catch>
 </etsm:var>
  

Solution #A3: Use a single syntax (the "embedded")and get rid of the @expr in <etsm:var>, and control the execution with @process.

So instead of:

<etsm:var name="totalamount" expr="$myPO/purchaseOrder/total" language="XPath20"  />

We would write:

<etsm:var name="totalamount" process="true" language="XPath20">$myPO/purchaseOrder/total</etsm:var>

 

======== issue B : parameterization

 

Assuming that we can assign XML fragments to a var:

 

<etsm:var name="PO" >
        <myapp:PurchaseOrder ref="1234">
           <myapp:Item>abc</myapp:Item>

           <myapp:totalamount>10000</myapp:totalamount>

        </myapp:PurchaseOrder>
 </etsm:var>

A developer would expect to be able to parameterize this, e,g, the @ref value, or the <totalamount> value could vary.

 

Solution #B1: just use an <etsm:function name="myPO"> as in Chuck's use case #1 to generate and return the result of the parameterization, using parameters for @ref and <totalamount>:

 

<etsm:var name="PO"  expr="myPO(1234, 10000)"/>

or:

<etsm:var name="PO"  process="true">myPO(1234, 10000)</etsm:var>

 

Solution #B2: use a more direct parameterization of the XML fragment to be assigned to the var:

Assuming that two variables $myref and $mytotal are in scope, with values 1234 and 10000:

 

<etsm:var name="PO"  ref="$myref" total="$mytotal">
        <myapp:PurchaseOrder ref="$ref">
           <myapp:Item>abc</myapp:Item>

           <myapp:totalamount>$total</myapp:totalamount>

        </myapp:PurchaseOrder>
 </etsm:var>

would assign the fragment shown previoulsy. The interest here is that this is lighter than having to implement a <etsm:function> for doing this (while the function mechanism is still needed in general).

 

 Solution #B3: use a more general text-parameterization + serialization mechanism, analogous to the <xsl:text>, and usable everywhere (inside <etsm:var>, inside <etsm:function>....)

 

The <myapp:PurchaseOrder> fragment would be described using a sequence of elements such as:

 

<etsm:text disable-output-escaping="yes">&lt;myapp:PurchaseOrder  ref=&quot;$ref&quot;&gt;</etsm:text>

 

and the parameterization would be resolved by a wrapper of the form:

 

<etsm:eval ref="$myref" total="$mytotal">

<etsm:text >...$ref...</etsm:text>

<etsm:text >...$total...</etsm:text>

</etsm:eval>

 

Where the eval/@ref and eval/@total are used to map external in-scope variables to the vars names used in the fragment, for the substitution.

The advantage of this parameterization mechanism, is that any part of the fragment can be parameterized, including the tag names, etc.

So the <etsm:var> assignemnt would look like:

 

<etsm:var name="PO">

    <etsm:eval ref="$myref" total="$mytotal">

        <etsm:text >...$ref...</etsm:text>

        <etsm:text >...$total...</etsm:text>

    </etsm:eval>
 </etsm:var>

 

 

Jacques