LAL – Little Activity Language

lal is a lightweight Service composition and execution language that is tailored towards the requirements of mobile infrastructures. lal has a considerable small set of abstractions that are easy to understand for people – in comparison with workflow languages like BPEL or YAWL. The latter are used to specify each step that is necessary towards the completion the workflow. In contrast, we strive for the support simple, adhoc workflows which are descriptions of activities (e.g., service requests) that are required for the completion of a task and can be even constructed on the fly.

lal Syntax Considerations

lal is build around several concepts which we discuss in this section. First and foremost, lal is presented in a notation that is referred as human understandable text notation. With lal, we strived for a reuse of structural and syntactic features of existing languages. We identified this approach as a promising way to enhance the learnability of lal and to ensure that the expectations of endusers are met. Generally speaking, languages, represent information in a rather similar way. A document in a language is a recursive composition of concepts, until the concepts become  pieces of atomic data. This can be observed in both (artificial) programming languages, as well as in natural languages like English. For example a piece of source code of a programming language can be considered of a series of import statements, class definitions that contain variables and methods descriptions, which in turn consists of sequences of statements. Programming languages contain class definitions that require method names, parameter lists, return types and visibility modifiers. It is worth noticing that these concepts provide the template for the insertion of atomic values, such as sentences within paragraphs or statements into method definitions.

At the same time, templates provide for the necessary separation of contained concepts by introducing meta information into the language. For example, programming languages use commas to separate method parameters, braces to denote the beginning and the end of methods or semicolons to terminate statements; natural languages use full stops to denote the termination of sentences. With lal we minimize the amount of meta information, i.e., separator characters like braces or full stops, parenthesis. Our goal is to align lal as close as possible to natural language, in particular to English, and use a subset of the meta symbols that is used in the English language as meta symbols. However, in order to support concepts like composition, lal use a set of keywords to denote these concepts. Again, this is similar to natural languages, where keywords are used as structural element. Our assumptions concerning the lal syntax and are based on works on teaching users how to program. In order to write a lal program, users must understand several topics, like knowing how to express their intentions with instructions and to how to organize these instructions. Most general purpose-languages require users to learn the syntax of the language and users often have problems to translate their intentions into syntactically correct statements. In the following subsections, we discuss the concepts of lal in bottom-up manner. We start with an atomic level and discuss lal commands and their structural elements. Then, we show how to organise lal commands with lal cards, enabling for structuring activities and conclude wit lal decks.

lal commands are the atomic building block of our proposed language. Structurally, the lal command notation is inspired by the root of verbs in semitic languages that provide a template that is used to construct different grammatical constructs for time or case. The lal command template offers several slots that are filled by (1) modal verbs that indicate tense and express necessity, uncertainty, ability, or permission, (2) resources (either as external links or directly URL encoded), (3) indirect objects that describe that indicates to whom or for whom the action of a verb is performed. Thus, a lal command is built on atop a very basic natural language construction, called independent clause. An independent clause describes a who-does-what by using a subject-verb-object-indirect object (SVO) construction and is present in almost every natural language, although the actual ordering depends on the given language (e.g., SOV in Japanese).

Starting with this structure, we can derive commands that are easy to parse for software (because of their regularity), yet still easy to write and understand for individuals. We the following set of modal verbs:

can: ability to perform activity/action
did: finished activity/action
will: about to start with activity/action

lal Cards

lal Cards are the means to structure activities into blocks that can be reused, shared with others and organised on the mobile device of the individual. With lal cards we aim at providing a useful metaphor for individuals to create lal processes. The inspiration for lal cards comes from two main sources, from teaching children how to program and HyperCard. The former investigated the card metaphor as abstraction that was thought particular useful for young people, because of the familiarity of using cards in games and thus making it easy for children to create programs that are based on cards. HyperCard, on the other hand, is an application program and programming tool for Apple Macintosh and Apple IIGS computers. In HyperCard, cards hold data and contain interactive elements like text fields, buttons and other GUI elements. Users of HyperCard have access to a virtual card stack which allow them to navigate from card to card, using built-in navigation features or scripts. Basically, lal cards contain sequences of lal commands that are tied together with meta symbols like first, finally, then, and or whenever (see Listing below for an example).

 

first select.Picture http://www.ikangai.com/localfile
then upload.Picture http://www.ikangai.com/
then modify.Picture http://www.ikangai.com
then upload.Picture http://www.ikangai.com
then on didSend.Picture make.Frame
and on receive.Picture create.invoice http://invoice.com for:
finally on receive.Picture

 

Transitions are used to describe permissible orders of interactions of an activity without describing the condition under which a certain interaction sequence is selected. In lal, we describe basic sequences using a set of keywords like then. For example, the process of qonnecting describes several interactions that are required by the user, beginning with downloading the available options, displaying them on the device and uploading the selection again.

 

download.Options https://app.qonnect.to/ikangai
then display.Options urn:screen
then upload.Options http://app.qonnect.to/ikangai

 

An important issue concerning the possible ordering of interactions is the specification of the first and last interaction. In lal, the first interaction of a card begins with the reserved keyword first, followed by a lal command. In the same manner, the last interaction begins with the keyword finally followed by a lal command.

lal Decks

lal cards can be extended with references to their name in their code. The name is given by the creator and published to a lal registry with a lal command. The corresponding command is

define.card PictureManipulation as
download.Options https://app.qonnect.to/ikangai
then display.Options urn:screen
then upload.Options http://app.qonnect.to/ikangai

 

la decks represent lal cards that are linked together by invoking each other. This provides for an additional layer of organisation for individuals.

first execute.PictureManipulation http://someurl.com
then execute.PictureManipulation http://someurl.com
and execute.PictureManipulation http://someurl.com

Visual lal

We introduced also a graphical notation for lal (see below). It is intended as design document that is used to describe scenarios and it’s stakeholders along with the context of the execution of lal. To that end, we include for example actuators/sensors (touchpoints), describe triggers, rules that contextualize the interaction and the microinteractions themselves.

Photo by Akil Mazumder from Pexels
Scroll to top