update and summary of current technical issues to discuss on 0.81 draft

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

update and summary of current technical issues or unsettled tech points to discuss on 0.81 draft

-------------------------------------------------------------------------------------------------------------------------------------------

 

TP1: "X-effects" of various XTemp constructs:

- see Section 3.5: The "X-Effect" of various XTemp constructs.

- especially 3.5.4 (case of concurrent scriplets).

- see 3.4.1: the X-effect of a var declaration.

- see question#1 in 3.6 about X-effect of exiting scriplets.

 

TP2: Exiting semantics: see Section 3.6.

- See the three questions #2, #3, #4 about Exit semantics (search for "Question#" in the doc).

- See 3.6.2 proposal (exiting inside a var).

- See 3.6.3 proposal (exiting inside a conditional statement).

 

TP3: Execution Semantics of "catch", Section 3.8.

- VP-time dependency (3.8.2)

- catch execution semantics (3.8.3)

 

TP4: <execution-context>: Section 3.9:

- See 3.9.2: about namespaces: do we need <nms-binding> since we have anyway to declare

these in the <script-package> top element?

- See the Event Board declaration (3.9.3)

 

TP5: Section 3.4: <var> typing:

- In 3.4.1: exact meaning of @type="xml"? It allows for embedded XTemp statements

(xtemp:eval) and more. Should it just be untyped in that case?

(could have any xtemp statement at top level, the added xml being just in-line effect)

 

TP6: Prototype: use @indent="true" to add a line break at the end of each line of

generated effect (when executing the generated xsl).

 

TP7: <var>, <loop-var>, <next-val> definitions:

- should we align them all in the way they compute a variable value?

E.g. when using an [XPath] expression, shold we enforce the use of xtemp:eval for

all of them, or add @expr to all of them?

- should we rename: <loop-var> --> <lvar>, <next-val> --> <lvar-next>

 

TP8: How controllable is the notion of VP-time:

- issue with start/@async, e.g. when capturing the result of an async scriplet:

<var><start async="true">...></start></var> needs to wait for completion before

executing next statement (so not really async with the invoking scriplet).

- Proposal #1: redefine the notion of "concurrency" as just a VP-time setting mode:

Replace the notions of synchronous/asynchronous, with "VP-affecting" / "VP-resetting"

as all boils down to how VP-time is manipulated.

- <start scriplet="S1" vptaffect="false"> means the VP-time will be reset to its

pre-S1 value when completing S1 (replace @async="true")

- <start scriplet="S1" vptaffect="true"> (default) means the VP-time will be

updated to its latest S1 value, when resuming invoking scriplet (replace @async="false")

- do the same for <catch>: add a @vptaffect attribute.

- also, when searching for some combination of events, one may want to do a

"catch" over past events (before current VP-time). So allow for setting VP-time

before executing a <catch> as well as for a <start>:

- Proposal #2:

- <start scriplet="S1" vptset="(date/time)"> and <catch vptset="(date/time)">

- same for <start-with>

- VP-time can then be manipulated to not be "monotonic" during overall execution thread:

it is only local to a scriplet or catch execution.

(can be incremented in a sub-scriplet, then reset to its original value when

resuming the invoking scriplet.)

- Proposal #3: add a new instruction: <vptset dateTime="..." jump="(duration)"/>

and define a builtin variable $vptime that can be used at all time to give the

current VP-time (but not modified explicitly).

 

TP9: - <post> syntax ?

- should it allow any XML statement with any XTemp embedded statements?

(e.g. like a var def.) Or just a previously defined var?

 

 

-jacques