RE: [tamie] about eTSM variables

I had envisioned variables working essentially the same way as they do in XSLT. That is, whatever the <etsm:var> element encloses is always processed, but how it is processed depends on what it is. Processing a text node doesn't change its value - it is still a text node. When elements in the etsm namespace are processed, they may produce other nodes (ie text or elements). For other elements, the outer element and its attributes are copied, but whatever content it encloses is processed further. For example, the totalamount in the purchase order could be "parameterized" by including an <etsm:eval> element in the totalamount element.

<etsm:var name="PO">

<myapp:PurchaseOrder ref="1234">
<myapp:Item>abc</myapp:Item>

<myapp:totalamount>

<etsm:eval expr="$total"/>

</myapp:totalamount>

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

But the elements inside the purchase order wouldn't have to be limited to literal XML elements and <etsm:eval>. You could also use other instructions such as <etsm:if>:

<etsm:var name="PO">

<myapp:PurchaseOrder ref="1234">
<myapp:Item>abc</myapp:Item>

<myapp:totalamount>

<etsm:eval expr="$total"/>

</myapp:totalamount>

<etsm:if condition="$physicalItem">

<myapp:weight>

<etsm:eval expr="$weight"/>

</myapp:weight>

</etsm:if>

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

I like this arrangement because it gives you more flexibility than merely "parameterizing" variable assignments.

<JD> That looks great indeed. Reminds me of other embedded scripting approaches for HTML pages.

However, we still need to address how to deal with dynamic attribute values, so the parameterization issue Jacques raised does still apply. There are several ways we could deal with this:

1) Allow variable references in attribute values (as in solution B2)

<myapp:PurchaseOrder ref="$ref">

2) Use an etsm:attribute instruction to create the attribute

<myapp:PurchaseOrder>

<etsm:attribute name="ref">

<etsm:eval expr="$ref"/>

</etsm:attribute>

...

</myapp:PurchaseOrder>

<JD> Indeed if we want to also parameterize metadata (e.g. element / attribute names), the meta-level processing XSLT-style seems to be the most flexible as in (2). But that does not preclude (1) either I believe.

The name attribute could also be a variable reference to allow creating attributes with dynamic names, and there could be a similar etsm:element instruction for creating an element with a dynamic name.

3) Use a serialization scheme (as in solution B3). The syntax I would suggest would be something like:

<etsm:var name="PO">

<etsm:serialize>

<![CDATA[

<myapp:PurchaseOrder ref="${ref}">
<myapp:Item>abc</myapp:Item>

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

</myapp:PurchaseOrder>
]]>

</etsm:serialize>

</etsm:var>

<JD> Interesting - that allows for "flat" parameterization of everythig inside - though no etsm computations (could be done outside the var assignment?).

Each of these solutions have there strengths and weaknesses, so I wouldn't be opposed to supporting all three.

- Chuck

From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com]
Sent: Thursday, October 30, 2008 7:17 PM
To: tamie@lists.oasis-open.org
Subject: [tamie] about eTSM variables

<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"><myapp:PurchaseOrder ref="$ref"></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>

tamie message