How do I couple a node glsp server with an existing language server to have a source model?

[neumaennl]

I want to create a VS Code extension that extends the existing XML extension by Red Hat (redhat.vscode-xml) and allows visual editing of XML schemas and possibly XML files bound to a schema (similar to Altova XML Spy). I hope that I can benefit from the XML language server integrated by the XML extension regarding things like what can be added at this point in the file and highlighting errors. How would I tackle this?

[planger]

I think there are two independent aspects: (a) how to get the data you need from redhat.vscode-xml and (b) how to make use of this data in GLSP.

The GLSP side of things (b) is rather straightforward. From the perspective of GLSP, you can do whatever you want in your source model storage implementation, whether you open a socket to another process (e.g. a language server) and query data, query a database, read a file... this is all up to you. In the source model storage, you eventually need to obtain the data that you need for generating a graphical model later in your implementation of the GModelFactory.

Thus in your case, your source model storage implementation would need to obtain the data you need from the language server, put it in the model state and then later process this in the GModelFactory to create a digaram.

How to obtain the data from the language server of redhat.vscode-xml (a) is rather outside of the scope of GLSP and depends on your intended architecture and the VS Code extension, or rather the language server implementation.

From the top of my head, I'd consider the following options:

One way could be to make your language server accept additional connections so that the GLSP server and the XML LSP can exchange messages.

If you can't easily control the language server, you could send a custom action to the client (i.e. your webview) and have a dedicated client action handler for this action type, which posts a message to VSCode (vscode.postMessage()), which in turn is then invoking a VS Code command that again is handled by redhad.vscode-xml querying the server (via a custom LSP message), and vice versa on response.
See https://code.visualstudio.com/api/extension-guides/webview#passing-messages-from-a-webview-to-an-extension and https://code.visualstudio.com/api/extension-guides/webview#passing-messages-from-an-extension-to-a-webview

The latter is also how sprotty-vscode does it:
https://github.com/eclipse/sprotty-vscode/blob/master/sprotty-vscode-webview/src/vscode-diagram-server.ts
and https://github.com/eclipse/sprotty-vscode/tree/master/examples for an example.

[neumaennl]

Okay, I thought that there maybe was a kind of best practice to interface a source model storage and a language server. I was under the impression that this might be a common use case. Since this is apparently not the case, I will probably try and write an extension for the XML language server (the VS Code XML extension by RedHat uses LemMinX) that communicates with Sprotty and a corresponding VS Code extension with a webview. I hope that this results in less implementation overhead compared to implementing a LemMinX extension that acts as a GLSP server and a VS Code extension that communicates with that.

[planger]

Well, as for a graphical representation you need information that is not part of the LSP, you'll likely need something custom anyway. This is, however, whether you use Sprotty or GLSP. I think with respect to the interfacing with the language server, it won't matter whether you use GLSP or Sprotty.
However, if you are mainly interested in visualizing and maybe trigger some code actions from the graphical view, Sprotty + LSP (like in this example) might indeed be the better choice for your use case.

[neumaennl]

Okay. I read the whole LSP spec since your last post. This got me to re-evaluate my whole approach. Looks like I need to create an AST for the XML schema myself. The language server will not help there.
I also wanted to port the necessary parts of Dgis XSD Diagram for the generation of the diagram. So with what I know right now, both glsp and Sprotty might be too complicated for what I want to do.
I can simply create a VS Code CustomTextEditor extension that parses the XML schema into an AST and since the AST already is 90% of what I need for a graphical model, I can then simply render the corresponding nodes is a webview with the code ported from Dgis.
For editing, I can then use vscode-languageclient to talk to the XML language server and integrate the code completion into the file and the diagram. I can even integrate the diagnostics from the language server into the rendering.

[planger]

Sure, that works too.. I guess there is imho just two considerations. If you assume that the XML LSP is active at the time your editor is active, you may save lots of resources if the LSP and your visualization would share the same AST from memory. Second, it depends on how interactive your view is going to be... if it supports editing and interactivity, Sprotty may still be useful for that purpose (if you focus on graphical interaction), and the LSP may still be useful if it provides code actions to make certain operations on the XML (the XML LSP could be enhanced with additional code extensions that are then usable not only in the graphical view but also in the textual editor).

But overall, imho, your design decision certainly makes sense too.

[neumaennl]

I definitely won't be able to share the AST.
I will take a look at the Dgis sources and at the Sprotty examples again to determine whether it makes sense to port only the SVG parts and use Sprotty, or if it seems like it would be less effort to also port the logic from Dgis and forgo Sprotty.
Thank you very much for the input.