Skip to main content

CIMLangServer (Language Server)

cimvocabcheck-lsp — branded CIMLangServer — is a standalone LSP 3.17 server that wraps the cimvocabcheck-core engine. It communicates over stdio and can be integrated into any LSP-capable editor. The CIMNotebook VS Code extension and IntelliJ plugin are thin clients around it.

How it fits​

Capabilities​

The server provides, for .rq / .sparql (SPARQL) and .ttl / .shacl (SHACL/Turtle) documents:

  • Diagnostics — the full validation check set, debounced and re-run on change.
  • Hover — IRI, label, comment, domain/range, and declaring profile for any CIM term (including enumeration members).
  • Completion — CIM-aware suggestions after a declared prefix (cim:, rdf:, …). In object position after an enumeration-ranged property, the enumeration's members are offered (e.g. cim:WindGenUnitKind.offshore).
  • Go-to-definition — jump to a term's declaration in the source RDFS file (classes, properties, and enumeration members).
  • Workspace symbols — find any schema class, property, or enumeration member by (partial, case-insensitive) name.
  • Commands — cimvocabcheck.explainQuery (explain) and cimvocabcheck.createConfig (generate opencgmes.jsonc).

Configuration discovery​

The server discovers the nearest opencgmes.jsonc (walking up from each document), loads the configured RDFS profiles, and reloads them whenever an opencgmes.jsonc changes — all open documents are revalidated after a reload. When no config is found, or it declares no schemas, documents are validated syntax-only (there is no bundled default schema). See Configuration.

Build​

mvn -pl cimvocabcheck/lsp package -DskipTests
# Output: cimvocabcheck/lsp/target/cimvocabcheck-lsp.jar

Run​

java -jar cimvocabcheck/lsp/target/cimvocabcheck-lsp.jar
# Speaks LSP over stdin/stdout.

Launch it directly only for integration testing — normally an editor client starts it. Requires Java 21+.

Integrating another editor​

Any LSP client can drive CIMLangServer. Point it at the launch command above, associate the SPARQL/SHACL file types, and (optionally) wire the two executeCommand ids. For a worked example of a client, see how CIMNotebook does it for VS Code and IntelliJ.

Command id vs. UI id

The wire-level executeCommand ids are always cimvocabcheck.* (e.g. cimvocabcheck.explainQuery), even though the editors expose their own cimnotebook.* UI command ids. When integrating a new client, send the cimvocabcheck.* ids to the server.