The development of modern IDEs is still a challenging and time-consuming task, which requires implementing the support for language-specific features such as syntax highlighting or validation. When the IDE targets a graphical language, its development becomes even more complex due to the rendering and manipulation of the graphical notation symbols. To simplify the development of IDEs, the Language Server Protocol (LSP) proposes a decoupled approach based on language-agnostic clients and language-specific servers. LSP clients communicate changes to LSP servers, which validate and store language instances. However, LSP only addresses textual languages (i.e., character as atomic unit) and neglects the support for graphical ones (i.e., nodes/edges as atomic units). In this paper, we present our vision to decouple graphical language IDEs discussing the alternatives for integrating LSP's ideas in their development. Moreover, we propose a novel LSP infrastructure to simplify the development of new graphical modeling tools, in which Web technologies may be used for editor front-ends while leveraging existing modeling frameworks to build language servers.

1. Towards a Language Server Protocol
Infrastructure for Graphical Modeling
Roberto Rodriguez-Echeverria, Javier L. Cánovas, Manuel Wimmer and Jordi Cabot

2. Context
Complex addition of new languages
Complex migration to Web/Mobile
The development of full-fledge
graphical modeling editors is a
challenging and complex task.

3. Context
User experience Language support
Complex addition of new languages
Complex migration to Web/Mobile
The development of full-fledge
graphical modeling editors is a
challenging and complex task.
Two main concerns to consider separately (?)

4. LSP
Language Server Protocol
IDE Language servers
MxN problem (3x9) to M+N problem (3+9)
https://langserver.org/

5. Problem
No scientific assessment or tool provider position on:
LSP provides
enough
expressiveness
for graphical
manipulations
LSP should be
extended to
support specific
features of
graphical
edition
It would be best
to ignore LSP in
graphical
modeling

6. Background: graphical modeling editors
Its development is more complex than textual modeling editors development:
- Atomic unit: char vs node-edge
- Processing: from top-left to bottom-right vs node relationships
- Serialization: raw text vs specific format (e.g. XMI)

7. Background: graphical modeling editors
Editor & Views
Semantic Operations
Diagrammatic
Operations
Auxiliary Operations
Graphical modeling editor Selection (type)
Hover (completion)
Completion (pop-up)
CRUD (elements)
CRUD (properties)
Auto-layout
Validation
...
Selection (free)
Hover (information)
Zoom
Align
Filter
Group
Hide
Storage
Initialization
Shutdown
Main operations in model editing categorized

8. Background: Language Server Protocol 3.0
https://microsoft.github.io/language-server-protocol/overview

9. Background: Language Server Protocol 3.0
Main issue: designed for textual
programming languages
● Text ranges are a basic type
=> making easy for clients to
connect to different LS in a seamless
way, because the protocol is
completely language-agnostic
NotificationMessage {
method : "textDocument/didChange",
params : {
textDocument : {
version : 2
},
contentChanges : [
{ range : {
start : {
line : 21,
character : 6
},
end : {
line : 33,
character : 6
}
}
text : ""
}]}}

10. Challenges
Reducing development and
maintenance costs for
graphical modeling editors
Using the Web as the platform
for modeling editors
deployment while reusing
modeling frameworks for
language servers
Managing different
languages developed with
different modeling platforms
from a single editor
Providing a single user
experience of modeling
editors so users can easily
deal with different languages

11. Vision: decoupled architecture
Editor & Views
Semantic Operations
Diagramatic Operations
Auxiliary Operations
Graphical modeling editor
11
Modeling framework
(platform specific)

12. Vision: decoupled architecture
Editor & Views
Diagramatic
Operations
Graphical modeling client
Semantic
Operations
Diagramatic
Operations
Auxiliary Operations
Graphical language serverPartial decoupling
Reduced client-server
bandwidth
Specialized UX
Simpler language server
Hybrid representations
Complex client/UX plat.
Poor extensibility (other
languages)
-
+
Semantic
Operations
12
Modeling framework
(platform specific)
UX platform
(modeling framework ported)

13. Vision: decoupled architecture
Editor & Views
Diagramatic
Operations
Graphical modeling client
Semantic Operations
Diagramatic
Operations
Auxiliary Operations
Graphical language serverFull decoupling
Reusing MFs
Platform-agnostic editor
Multi-language editor
Complex server
High bandwidth
consumption
-
+
13
Modeling framework
(platform specific)
UX platform

14. Vision: communication protocol
Using LSP
Standard
Reuse LSP tools
Future features
For textual langs.
No hybrid
representations
Extending LSP
Standard
Reuse LSP tools
Future features
Hybrid
representations
Concrete syntax
support at client
Textual rep. req.
New protocol
Element ids
Optimized for gme
operations
Standard (?)
LSP overlapping
LSP compatibility
-
+ +
-
+
-

15. Vision: communication protocol
Although the pros of defining a new protocol or
extending LSP may be substantial, we argue that
using LSP itself plus a textual representation is
expressive enough for graphical languages, and
most of its drawbacks may be properly addressed by
providing the needed LSP infrastructure.
LSP provides
enough
expressiveness
for graphical
manipulations

16. LSP infrastructure for graphical modeling

17. Intermediate Representation Format
A JSON-based format:
● abstract,
● concrete
● and diagrammatic properties
Design driven for two main forces:
● encompassing abstract and concrete
syntaxes in a single resource
● provision of the necessary
information to the client
“Node-edge” representation

18. Intermediate Representation Format

19. Mapping GME operations into LSP
Identification of operations
Reviewed three MDE
graphical editing tools:
● Papyrus,
● Sirius
● and GMF
Study of operations
Defined a comprehensive set
of use cases to illustrate how
we can map user operations
into LSP messages by
leveraging on IRF
1 2

20. Mapping GME operations into LSP
Identification of operations
Reviewed three MDE
graphical editing tools:
● Papyrus,
● Sirius
● and GMF
1

21. Mapping GME operations into LSP
Study of operations
Defined a comprehensive set
of use cases to illustrate how
we can map user operations
into LSP messages by
leveraging on IRF
2https://som-research.github.io/lsp4gml/cases.html

22. Mapping GME operations into LSP
P1
C1
01 {
02 "elements" : [
03 "node" : {
04 "id" : "c1",
05 "type" : "class",
06 "abstract" : {
07 name : "C1",
08 qualifiedName : "P1::C1",
09 ...
10 },
11 "concrete" : {
12 width : 20,
13 Height : 20
14 },
15 "diagram" : {
16 x : 15,
17 y : 15
18 },
19 ...
20 },
21 "node" : {
22 "id" : "p1",
23 "type" : "package",
24 "abstract" : {
25 name : "P1", ... }
26 "concrete" : {
27 width : 100,
28 Height : 100 },
29 "diagram" : {
30 x : 0,
31 y : 0 },
32 ...
33 },
34 "edge" : {
35 "id" : "e1",
36 "type" : "ownedClasses",
37 "group" : "true",
38 "origin" : "p1",
39 "target" : "c1",
40 "abstract" : {
...
Maybe, I don’t need it

23. Mapping GME operations into LSP
01 {
02 "elements" : [
03 "node" : {
04 "id" : "c1",
05 "type" : "class",
06 "abstract" : {
07 name : "C1",
08 qualifiedName : "P1::C1",
09 ...
10 },
11 "concrete" : {
12 width : 20,
13 Height : 20
14 },
15 "diagram" : {
16 x : 15,
17 y : 15
18 },
19 ...
20 },
21 "node" : {
22 "id" : "p1",
23 "type" : "package",
24 "abstract" : {
25 name : "P1", ... }
26 "concrete" : {
27 width : 100,
28 Height : 100 },
29 "diagram" : {
30 x : 0,
31 y : 0 },
32 ...
33 },
34 "edge" : {
35 "id" : "e1",
36 "type" : "ownedClasses",
37 "group" : "true",
38 "origin" : "p1",
39 "target" : "c1",
40 "abstract" : {
...
P1
C1
Let’s delete P1

24. Mapping GME operations into LSP
NotificationMessage {
method :
"textDocument/didChange",
params : {
textDocument : {
version : 2
},
contentChanges : [
{ range : {
start : {
line : 21,
character : 6
},
end : {
line : 33,
character : 6
}
}
text : ""
}]}}
RequestMessage {
jsonrpc : "2.0",
id : "0001",
method: "workspace/ApplyEdit",
params : {
edit : {
documentChanges : [
{
textDocument : { version: 2 },
edits : [
{ range : {
start : {
line : 03,
character : 00 },
end : {
line : 35,
character : 00 }
},
newtext: ""
}]]}}}
ResponseMessage{
jsonrpc : "2.0",
id : "0001",
result : { applied : true }
}
Client => Server Server => Client Client => Server

25. Mapping GME operations into LSP
01 {
02 "elements" : []
03 }
D’oh!

26. Proof of Concept
MDETools 2018
“An LSP infrastructure to build
EMF language servers for
Web-deployable model editors”
https://github.com/SOM-Research/lsp4gml

27. Conclusions and Future Work
We discussed different alternatives of clients, servers and the LSP usages for
decoupling graphical language editors.
We described an approach relying on standard LSP and a text-based model
representation shared between clients and servers.
Roadmap:
● Automatic generation of graphical language servers
○ To what extent is feasible?
● Performance assessment
○ bandwidth optimization and server-side enhancements.

28. Decoupling GME dev into a client-server architecture
using a convenient protocol is a key approach.
Let’s use an open common protocol to share
our graphical language servers
Final
Remark

29. Thank you

30. Towards a Language Server Protocol
Infrastructure for Graphical Modeling
Roberto Rodriguez-Echeverria, Javier L. Cánovas, Manuel Wimmer and Jordi Cabot