The electronic version of the SEML specification is distributed under the terms of the GNU Free Document License 1.1. All rights reserved by Dennis Heuer.

SEML provides a small but efficient syntax for writing rules that connect events with actions. It comes without redundance and is targeted at supporting both handwriting and automated processing (reading needs quite a bit training though). SEML provides only a syntax; the list of event signals, subjects and objects and any extra rule not described in the specification is provided by the utilizing application or a third party tool.

Syntax

Six ways of writing event rules

Short syntax:	§ signal,... signal,...
Medium syntax:	§ (subject) signal,... (subject) signal,...
Extended syntax:	§ (subject) object:signal,... (subject) object:signal,...
Global event rule:	§ (keyword) ( § (subject) object:signal,... (subject) object:signal,... )
Event rule call:	§ (keyword)
SEML command:	§ command ( ... )

Explanation of terms and symbols

§	The introducing identifyer and divider of event rules
,	A divider of signals or »object:signal« pairs
» «	The whitespace divides the sequences of initiating and to be initiated signals. Signal names as well as object names must not include whitespaces. Subject names and keywords may include whitespaces. Trailing whitespaces for better reading are allowed and ignored while interpreting.
(...)	A general container element for keywords, subjects or independent sections
...	Another unit of the same sequence
subject	A signal sending or accepting resource like a mouse, a printer or a graphical unit
object	A component of a subject like the first button of a mouse
signal	A signal that is initiated or accepted by a subject
keyword	A reference to global event rules available at a central place
command	A global SEML command

SEML implements version 0.96 of the »Conditional Concatenation Language«. Read the CCL documentation for more about how using it.

Use

The short syntax

The short syntax is used if the element that provides the event rule is also the target of both the event-initiating signals and the afterwards immediately to be initiated signals. It defines very simple rules of the type »IF APPEARS, DO«.

After the paragraph symbol, the first comma-divided list specifies all signals that must occur to initiate the event. The next comma-divided list specifies the signals to be initiated, once and in the given order, immediately after the occurence of the event is recognized.

Example

A desktop application displays an animation that starts automatically if it gets the focus and stops automatically if it looses the focus. The SEML event rules could look like follows:

§ focus start § unfocus stop

The signal names are provided by the application and may vary. The focussing rules may be defined with SEML too. They may track the mouse pointer entering or leaving the animation area, for example.

The medium syntax

An element may track another element for event signals. In this case the identifyer of that element must be written before the to be tracked signals and in parentheses. For example, the above introduced animation may track a displayed button for being clicked:

§ (button) clicked start

Instead, the button may track itself for being clicked and send the animation the start signal immediately after the event was recognized:

§ clicked (animation) start

Otherwise, the application may have initialized event rules at startup that are tracking two buttons for starting and stopping the animation:

§ (button1) clicked (animation) start § (button2) clicked (animation) stop,rewind 

The extended syntax

Some subjects--mainly devices--may consist of multiple components that must be tracked or targeted at individually. SEML addresses them as »objects«. SEML only provides the syntax for referring to them. The references themselves are provided by the SEML utilizing product.

Example

A graphical application provides an info dialog. The dialog appears if the user clicks with the left mouse button on a label in the main menue. The label tracks itself for being clicked and sends the start signal to the info dialog:

§ (mouse) button1:clicked (info) start

Global event rules

Often used event rules may be registered in a central register of an application and referred to as needed. If and how global event rules are supported depends on the application. SEML only provides the syntax for defining them:

§ (quit) ( § (keyboard) ESC:pressed (exit dialog) start )

The keyword »quit« is the identifyer. It is defined in parentheses and before the event rules. In the next parentheses the event rule defines that pressing the ESC key on the keyboard starts an exit dialog. This global event rule may be practical for the application windows, for example. It is referred to as is described below.

Event rule calls

Global defined event rules may be called from any unit of an application. Any restrictions to this are defined by the application developer and not by SEML. Technically, calling a global event rule means inheriting and activating it as if it was provided by the calling unit itself:

§ (quit)

SEML commands

SEML provides a short syntax for defining global commands. A small number of pre-defined commands eases the most frequent tasks but the list is thought for being extended by the application developer:

transmit (...)	overgives the event rules in the parentheses to all other elements in the scope that is defined by the application--XML languages may restrict the transmission to subdivided elements, for example
inherit (...)	overtakes all event rules from the element that is identified in the parentheses
restrict (...)	restricts all following event rules to the element type that is specified in the parentheses--empty parentheses delete the previously defined restriction
track (...)	specifies a default subject for tracking event signals in the parentheses--empty parentheses delete a previous setting
target (...)	specifies a default subject for targeting event signals at in the parentheses--empty parentheses delete a previous setting
signals1 (...)	specifies a default sequence of event initiating signals--empty parentheses delete a previous setting
signals2 (...)	specifies a default sequence of to be initiated signals--empty parentheses delete a previous setting

Three examples

A more comfortable method for distributing event rules than described above in the section about global event rules is using the transmit command:

§ transmit ( § restrict (dialog) § (keyboard) ESC:pressed (exit dialog) start )

The above example defines an event rule that sends the start signal to an exit dialog if the ESC key was pressed on keyboard and transmits this event rule in one go to all elements of the type »dialog« as it was restricted with the restrict command. Consequently, all dialogs of that application support starting the exit dialog if the ESC key was pressed.

In the example, a dialog contacts a main dialog and inherits its event rules. This is similar to using keywords but targeting at all available rules instead of a specific event rule sequence:

§ inherit (main dialog)

The next example compares the standard method of definining a number of key events with a more simple, command-based method:

1.

§ (keyboard) ESC:pressed (exit dialog) start
§ (keyboard) ALT-F:pressed (menue) folder_file:open
§ (keyboard) F1:pressed (help dialog) index:start
§ (keyboard) ENTER:pressed (document) append:linefeed
§ (keyboard) CTRL-X:pressed (document) marked_area:cut

2.

§ track (keyboard)
§ signal1 (pressed)
§ ESC (exit dialog) start
§ ALT-F (menue) folder_file:open
§ F1 (help dialog) index:start
§ target (document)
§ ENTER append:linefeed
§ CTRL-X marked_area:cut

Implementing the Conditional Concatenation Language

SEML is used for defining very simple event rules that just connect signals without analysing the context in that they are initiated. CCL supports SEML with this »context sensitiveness«. It provides rules for defining a timeframe or an order in that signals must occur. Further, it provides rules for including missing information at the time of initiation and so forth.

Examples

The first example bases on the above discussed global event rule for starting an exit dialog:

»§ (quit) ( § (keyboard) ESC:pressed (exit dialog) start )«

It is assumed that the application allows the user to change the keyboard settings. The user decides to choose another key than the ESC key for starting the exit dialog. Consequently, the ESC key definition must be replaced with the new key definition. The application could re-create the event rule. It could also have substituted the key definition in the event rule with the CCL placeholder »[=]« which supports dynamic insertion of information of any kind:

§ (quit) ( § (keyboard) [=]:pressed (exit dialog) start )

The calling event rule must overgive the replacing value:

§ (quit) [CTRL-X]

Except the keyword all values of an event rule--even command names--can be substituted with placeholders. The decision lies in the hands of the application developer. He must wage out flexibility against usability and code lenght:

§ (mutator) ( § ([=]) [=]:[=] ([=]) [=] )

§ (mutator) [keyboard] [CTRL-X] [pressed] [exit dialog] [start]

See the CCL documentation for more.