More interestingly: What would it mean? What is actually specified? For instance, when I specify a messaging protocol I could use a FSM but would this implicit

More interestingly: What would it mean? What is actually specified? For instance, when I specify a messaging protocol I could use a FSM but would this implicitly assume that there is some form of "connection" between client and server that consists of a state in each of them. So whenever I specify something, I need to start with a declaration of the entities and the list of possible events (and these events would carry data). This way, the spec has an unintended effect on the implementation. Let's assume that I have some universal way to represent this data in all target languages (complicated but doable). If I then want to compile this FSM spec into test cases, I must offer some interface that mirrors the entities and events, essentially forcing me to explicitly program a FSM. This is suboptimal because my implementation might not actually need this level of abstraction. A simple embedded C program might be described as a FSM but it could be implemented as a sequence of instructions. Of course, we could also switch to integration testing, passing messages over sockets, etc. but then we would have to program the scaffolding around our mock client/server component and to benefit from the automatic test case generation we would have to either parse and interpret these automatic test cases or program our mock in a form that is defined by the specification output. What I am trying to say is that there probably won't be a universal spec language. Instead, it should fit into the implementation eco system.