New scripting proposal Use Case #1, + next meeting Tuesday 6th, US, 2pm PT

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

New scripting proposal for use case #1 in wiki, based on the scripting design we came up with at the F2F:

 

http://wiki.oasis-open.org/tamie/better-UC1-Proposal1

 

Below are related language design issues that came up when scripting this, and that we need to discuss at next meeting (Tuesday 6th, US, 2pm PT) :

 

-------------------------- design issues on agenda of next meeting(s):

 

1- Scoping of scriplets (or whatever we call them):

Should scriplets contain scriplets?

(as opposed to the world of scriplets being "flat"?)

The only reason to do that would be to control scope of visibility,

and modularity (avoid name conflicts).

I would be in favor of that, if XSLT supports it (which I think it does).

In use case #1 new scripting, a scriplet can embed another scriplet,

making the embedded scriplet only usable within the first one.

 

2- the control of the "bubbling" of exit statements seems more appropriate

to do on the invoking statement (<start>) than on the defn of the scriplet itself,

as it depends on the usage of this scriplet. See how done in use case #1 new script.

Analogous to catching exceptions generated by a returning function...

 

3- I believe a loop should automatically have visibility of the variables declared

in the embedding scriplet (though not being able to alter them).

I think we can achieve that in XSLT (automatically passing these as parameters

to the named xsl template that will implement the loop).

When scripting use case #1 I started by explicitly "passing" these outside vars

in the <onstart> section, and that looked quite contrived and unatural.

So I simply assumed the vars of the embedding scriplet were "in-scope" for the loop.

(See in maincase_opt2 scriplet, the parameter $activationDate)

 

4- eTSM functions: what eTSM operations do we expect them to do?

On one extreme: exactly the same as scriplets, and plus.

\(that includes catching events, invoking sub-scriplets, etc, possibly concurrently...)

On the other extreme: no eTSM operations at all except for etsm:eval, just computations

or spitting out xml fragments.

An approach:

- functions can't invoke scriplets. Just other functions.

- functions can't catch events.

- functions can however use all flow control ops: conditional, loops.

(need to define smantics of <return> in these contexts)

 

5- Semantics of concurrent scriplet execution: for a cleaner execution semantics

I suggest that a scriplet terminates only after all its child scriplets (i.e.

scriplets of which it is root of an invocation closure) terminate.

Thus, if S1 invokes S2 and S3 with @concurrent="true", there is an implicit "join"

at the end of S1 that waits for S2 and S3 to complete (except if an <exit> is

executed in any of these.) This way, the "effect" of S1 is clearer: when

S1 invocation is assigned to a variable, its clear that the effect of S1 includes

the effect of all its sub-invocations.

 

6- "Effect" of scriplets: so far the idea is similar as in xslt: any xml fragment

with namespace other than etsm, that appears inside a scriplet is supposed to be

automatically output as part of the effect of the scriplet.

This assumes the fragment and whatever etsm operation (e.g. eval) it contains

is well-formed xml, and is contained within the same scriplet.

E.g. both a start tag and an end tag (say: <myapp:PO> and </myapp:PO>) must be found

in the same scriplet.

If one needs more fine-grain control on what is to be generated,

e.g. parameterize the name of attributes, or has the fragment spread over different

scriplets or constructs, some meta-level operator like in xsl could be used.

It seems that this approach lends itself both to XSLT and Java implementations.