Thanks for the warm welcome and the amount of inputs and details that
everybody so fast provides.
I'm really impressed by this community.

Ok seems that delivering a language specification in EBNF has some
challenges that can hardly be addressed due to the nature of org-mode
design, but I read around that often EBNF is not the silver bullet to solve
a grammar representation although it is a de-facto standard.

So I will try to put some orders in my thoughts, when I look at
functionalities of org-mode I will split them in the following categories:

   - Grammar Specification
   - Metadata
      - TODO
      - Code Block

      - Tangling (or waving for the web people)
   - Properties of the file
      - Templating

      - Block Execution
   - Environment (Global variables such as PATH)
      - Language
      - Context for arguments

      - Publishing Functions
      - Target Format
      - Custom Parser

I share a lot with of your ideas and inputs, here some observations and
options that I noticed:

   - Indeed emacs is not that big and could run as a background process to
   deliver org-mode features to other systems.
   I do something very similar to *TEC* for my CI/CD and my static
   generated website, but I'm not sure I would run emacs as a web service.

   - LSP doesn't mention org-mode as available language, but it does for
   markdown
   https://microsoft.github.io/language-server-protocol/specifications/specification-current/#textDocumentItem
   maybe because org-mode is not a language?

   - I share the sentiment that some api are a bit obscure and most
   important there isn't for instance an official way to say "this is how you
   create extensions in org".

   - I found that multiple people are already converting org-mode into json
   by using org*-map-entries *which indeed is not very publicly shown (I
   miss something like "this is how you create extensions in org").

   - I relate a lot to the issues that *Tom Gillespie* discusses in his
   post (
   https://lists.gnu.org/archive/html/emacs-orgmode/2020-10/msg00244.html)
   about tangling and executions and I loved to see your efforts in trying to
   solving them.

   - Since gccemacs elisp could compile to C (not sure this is relevant,
   but can be investigated if there are opportunities to be capable to have
   org-mode embendable).


For my personal needs I think I would pragmatically start toying around
with a org-mode to json like here https://github.com/ludios/org-to-json
And once I gain some confidence on the output JSON, I think I will gain
more confidence about the grammar definition.

I think that converting org-mode to JSON could show org-mode as an Abstract
Syntax Tree, I think from there it should be easier to create a
specification and maybe is what already *orgajs
<https://github.com/orgapp/orgajs>* already did.
I believe creating functions like tangle and execution shouldn't be that
trivial from an AST.

Concluding,
there is overlap between the Interfaces of LSP and org-mode which makes a
lot of sense since both target the interaction for with a document eg:

   - Propose actions, these can be:
      - Execute
      - Tangle
      - Change state TODO
      - Insert date, tag, etc...
   - Go to definition (For linking sections)
   - Support multi language in the same document

This makes me think that creating an org-mode LSP is not that crazy idea
after all, what do you think?
If you would build an LSP for org-mode which setup would you choose? What
do you think would be hard to implement?

Again many thanks 🙏
Mauro.