presentation of several KIELER textual modeling language proposals by oba

• informal talk, presenting different proposals shown by means of the same use case example

• initially presented: SCXML
  seems to be used broadly (used by several groups interested in KIEL's textual modeling features) -> maybe an import/export interface!

• problems of KIT classic:
  • not possible to press state's final attribute into a transition definition A->B - extra deklarataion of B needed
    • comments: in bigger state charts state attributes might crawl around
  • different types of parenthesis
  • mandatory quotes actually needed?
  • how to declare pragmas / meta infos -> don't enforce them!
    • problem: provide information for interpreting specialties like input/output
      -> distinct core language and annotations clearly !
  • a -> b[type = final] replace by a -> final stop

• proposal JITTY:
  • flat declaration of states; hierarchy by sub state references within super state declaration
  • pro:
    • clever notation of transition type!
      even better: >--> dest_state [: label] whereas transition is declared in src context
  • con:
    • destination state after label -> inconvenient in case of long labels (newlines in label?)
    • newline is sequence operator -> merging of secondary notation and semantics
    • symbolic notation might look cryptically quickly:
      other variant: strong src -> dest

• proposal KITEX .... funny but actually not convenient
  • interesting aspect: replacement of >-> by a font symbol / graphical symbol (green triangle)

• TASK oba: broadcast pointer on the slides !! done, see below

some notes about the presentation

• As mentioned above, the presentation below is not a formal one but rather some informal notes about different syntax ideas
• This is how it is structured:
  • Actual state: Overview of existing languages and critic about our current language, KIT.
  • Different proposals
    • Idea of the proposal
    • Examples
    • Critic
  • Summary, open questions and a few no gos, discovered

holding the concept and the concrete syntax separately

Describing a StateChart(SC) textually brings some typical problems with it. Most of the syntax proposals were thought to attack one/some of those problem(s). So the logic behind a particular syntax proposal can vary highly from the logic of another one while they seem alike according to the concrete symbols and the concrete syntax. So in each syntax, we should see a StateChart from another point of view. But this does not always has to do with the way, how we express individual SC elements concretely. Mostly the concrete syntax for each SC element can be choosen from a bunch of possibilities and used within one or another syntax proposal. We can have a Java-like concept or a TeX-like one but still use keywords instead of symbols for state types.

So, how we describe each SC element concretely can and maybe should be held separated from the concept behind the syntax, we choose. Therefore we have a list (see SyncChartElements.odt below) with most of the very basic elements of SCs in KIEL where you can come up with your own proposals for each. We then can use for example your symbol/keyword for a particular element in a syntax(concept) of our choice.