LionWeb

LionWeb – Language Interfaces on the Web

Mission

To create an ecosystem of interoperable components for building language-oriented modeling tools on the web.

We believe that a lively ecosystem will facilitate the adoption of language engineering and modeling solutions by reducing vendor lock-in. Development of advanced solutions will be accelerated by mixing and matching components, potentially sourced from different vendors or open source initiatives. It will also foster innovation, as incremental improvements can be defined on top of the existing libraries and components.

Documentation

Please find a documentation overview on our website.

We also gave talks:

Activities

  1. The main focus is the definition of protocols for the communication between participating software components such as repositories and clients. To make this feasible, we also define a meta-metamodel as well as a reference architecture.

  2. Where appropriate, in order to support the protocols, LionWeb defines programming language-level APIs to access models and metamodels and to encapsulate the protocols.

  3. A third activity is to create a collaboration hub for the developers of such components, to empower other software developers to develop web-based modeling solutions, and to educate the public about the benefits of this approach.

Reference Architecture

Reference Architecture Diagram

A model is a graph structure with nodes and edges and one primary containment hierarchy [B]. Nodes are typed by a reference to a concept (a node in the metamodel of the language) and edges are named and typed (with a primitive type or a concept). Nodes also have properties which have names and primitive types. Nodes are identified by unique IDs. A LionWeb language – or its metamodel – is an instance of the LionWeb meta-metamodel.

A repository [A] stores models and provides clients [C,D,E,F,G] access to the nodes in a model. Conceptually, it is the center of a LionWeb system, with clients connected to it in a star topology (although the technical architecture may be different).

Original models are models that cannot be (re-)computed from other models. They are CRUDed by users (mediated by tools). Typically, they are what we’d call (a collection of) ASTs. They have to be persisted in the repository because they cannot be recomputed. Derived models are calculated from other (original or derived) models without direct human interaction. They are usually some form of analysis result, such as one related to a type system. Nodes in derived models are typically associated with an original node – e.g., the type computed for an AST node. The repository manages this association. Derived models may be persisted or be recalculated on the fly.

A client is any program that works with models and nodes in the repository. We identify two kinds of clients, although there might be more: editors [F,G] and processors [C,D,E]. An editor CRUDs original models based on its direct interactions with users. A processor is a client that CRUDs models without direct user interaction. Processors can CRUD original models (e.g., importers [D] or generators [E]) or derived models [C] (e.g., compute type systems, desugar models, or interpret models).

One important design guideline for LionWeb is that we treat original and derived models similarly in terms of how they are transported to and from clients and/or how they are updated.

Clients can communicate with the repository in two ways: bulk and delta. Bulk communication means that a client requests a set of nodes from the repository, processes those in isolation (e.g., import or otherwise create new nodes, modifies existing nodes, or generates output) and then writes the changed set of nodes. Delta communication means that, after receiving an initial snapshot similar to the bulk case, the client continues to receive changes (aka deltas) from the repo; it also writes back changes continuously. Delta communication is also the basis for multi-client realtime collaboration.

Work Products

We aim to create the following work products (in order of descending priority):

In terms of how we work, we aim for a collegial atmosphere and effective technical discussions. All our specifications will be backed by working code (OMG, this is really nice!).

This project will not provide production-quality implementations for the repositories or clients; we expect this to be done by the community, for example, based on the tools mentioned in the History section.

Participation

Currently, LionWeb consists of ten developers, all with a long history in language engineering and modeling tools (listed in alphabetical order)

During the first half of 2023, we slowly grew the set of participants based on invitation of existing participants.

Join us on Slack for interesting discussions.

All our specifications and code is released as open source under the Apache 2.0. It explicitly allows commercial use. LionWeb is currently not its own legal entity, it’s just a voluntary collaboration of people.

History

All of the initial participants have a history of working with or on Jetbrains MPS, and we all appreciate its revolutionary approach of projectional editing. Most of us have also worked with EMF and tools on top of it, in particular, Xtext. However, over the last few years, the need to run “something like MPS” in the browser has increased, and many of the LionWeb founders have started developing ideas and tools around web-based language workbenches:

These tools are independent and do not provide out-of-the-box interoperability. This is unfortunate because

The lack of interoperability discourages others from developing additional components. It is also hard to explain to potential users, customers, contributors, and funders why this small community hasn’t been able to coordinate better. We have started LionWeb to fix these problem: The LionWeb initiative aims to facilitate the community-based development of language engineering and modeling tools on the web.

This site is open source. Improve this page.