<p>Say I have a configuration file format that is very well defined; in say JSON format; with a <a href="https://en.wikipedia.org/wiki/JSON#Metadata_and_schema" rel="nofollow noreferrer">JSON-schema</a> defining what is allowed and how strict to be.</p>
<p>Would it be too generous to call this a <a href="https://en.wikipedia.org/wiki/Domain-specific_language" rel="nofollow noreferrer">Domain Specific Language (DSL)</a>? - If so what is a better term?</p>

<types><language-comparison><terminology><domain-specific-languages><documentation>
Is it valid to call a configuration-format—with associated JSON-schema—a language?
CC BY-SA 4.0
2024-04-28T15:32:14.467Z
JSON is a language, sure. It's not a programming language, though. Whether or not subsets of JSON should be considered different languages, or just considered as JSON, is a philosophical matter, but either way they are languages. Perhaps a better question is whether it is useful to consider them languages, given that JSON tooling already exists so there is no need to implement anything new to use them.
kaya3
CC BY-SA 4.0
2024-04-30T21:17:22.773Z
While not perfect, a reasonable rule of thumb is that a programming language should be Turing-complete. Configuration files generally lack features like variables or conditionals that are needed for this.
Barmar
CC BY-SA 4.0
2024-04-30T22:17:31.523Z
All sets of strings are languages, and this certainly seems to be specific to a domain. But you're asking for a "better" term without giving a metric for betterness. Who is the target audience for this jargon that you're considering, and what are you trying to communicate to them?
Eric Lippert
<p>A very well defined configuration file format is a domain specific language, according to the <a href="https://en.wikipedia.org/wiki/Domain-specific_language" rel="nofollow noreferrer">Wikipedia page that you have linked</a>. However, it is not a domain specific programming language, which is what people typically think of when they hear domain specific language.</p>
<p>JSON is typically considered a data interchange language, so a subset would likely be considered to be a dialect, instead of a language, unless it was being processed completely differently from regular JSON.</p>
<p>Your configuration file format would seem to be a domain specific dialect; however, for clarity, you might want to think about just calling it a domain specific configuration file format, or simply a configuration file format.</p>

CC BY-SA 4.0
2024-04-30T21:37:58.670Z
2024-04-30T21:37:58.670Z
ggZQX6YPvD
<p>What is &quot;valid&quot;? Who decides?</p>
<p>Any set of strings is, <a href="https://en.wikipedia.org/wiki/Formal_language" rel="nofollow noreferrer">formally speaking, a &quot;language&quot;</a>, whatever it looks like and however the rules for determining what is in it are defined. In this sense, RFC8259, JSON Schema, and your schema provide the rules, and the strings meeting those rules are the words of the language. It's certainly valid and accurate to say this is a language in that sense.</p>
<p>A configuration language may have some attached semantics as well, which aren't part of this particular definition of &quot;language&quot;. Those might make it more useful to refer to the whole package of permitted syntax and required semantics as a unit as a language, or they might be so decoupled that the serialisation format is irrelevant and it's less useful. You have more information to determine that with.</p>
<hr />
<p>A domain-specific language is a language made for mechanical processing intended for some specific area of application. Sometimes those are freestanding (external DSLs), sometimes they are created within the syntax of another language (internal DSLs), and sometimes they sit in some nether space. It's not an inherent property of the language, but one about its purpose and usage; we don't really have the information necessary to assess that here, but my evaluation wouldn't matter anyway.</p>
<p>There are a number of DSLs built out of JSON, such as the query languages used in databases like MongoDB, or out of similar data serialisation languages like YAML, such as Ansible playbooks. Some of these have evolved to reach fairly complex points where they amount to general-purpose imperative programming languages with terrible developer experience; I don't think there's much controversy over calling those DSLs even among more restrictive audiences.</p>
<p>Configuration languages more typically are largely declarative, and the line between data containing information about something and a declarative programming language defining what the shape of something should be is not clear. It's probably reasonable to say that defined JSON dialects intended to be written by humans are in most cases some sort of DSL, and others might be too. For the purposes of <em>this site</em>, questions about parsing, typechecking, error reporting, and usability design of JSON-embedded languages to the extent that they parallel typical programming language issues <a href="https://langdev.meta.stackexchange.com/q/30/133">are considered part of programming languge design and implementation</a>. There are also bona fide programming languages that are serialised to JSON, such as <a href="https://en.scratch-wiki.info/wiki/Scratch_File_Format_%282.0%29" rel="nofollow noreferrer">Scratch</a>, and that format doesn't change anything about the language itself.</p>
<hr />
<p>However, a more practical question lurking behind the scenes here is... why? Terms have meaning so far as they're understood by the audience, and so far as they're useful for communicating about the topic at hand. It's neither an achievement nor a condemnation for something to be a language or not, to be a DSL or not, and so on.</p>
<p>Is <em>this</em> a language? Defensibly, certainly. Is <em>this</em> a DSL? Sure, it could be. Are those terms useful for describing it? They could be, or they might mean nothing to the audience, or they might actively confuse matters. These are the most useful considerations, rather than generosity or validity according to some authority. I would probably feel comfortable referring to a firmly-constrained configuration language as a DSL in most cases, but I also probably wouldn't stretch to do so.</p>

CC BY-SA 4.0
2024-05-01T01:36:29.890Z
2024-05-01T01:36:29.890Z
Michael Homer
# Is it valid to call a configuration-format—with associated JSON-schema—a language?
Posted by: username_0 on 2024-04-28
Say I have a configuration file format that is very well defined; in say JSON format; with a [JSON-schema](https://en.wikipedia.org/wiki/JSON#Metadata_and_schema) defining what is allowed and how strict to be.

Would it be too generous to call this a [Domain Specific Language (DSL)](https://en.wikipedia.org/wiki/Domain-specific_language)? - If so what is a better term?
**Tags:** types language-comparison terminology domain-specific-languages documentation
> **Comments:**
> **username_1**: JSON is a language, sure. It's not a programming language, though. Whether or not subsets of JSON should be considered different languages, or just considered as JSON, is a philosophical matter, but either way they are languages. Perhaps a better question is whether it is useful to consider them languages, given that JSON tooling already exists so there is no need to implement anything new to use them.  
> **username_2**: While not perfect, a reasonable rule of thumb is that a programming language should be Turing-complete. Configuration files generally lack features like variables or conditionals that are needed for this.  
> **username_3**: All sets of strings are languages, and this certainly seems to be specific to a domain. But you're asking for a "better" term without giving a metric for betterness. Who is the target audience for this jargon that you're considering, and what are you trying to communicate to them?  
---
## 2 answers
### Answer by username_5 on 2024-05-01. Score: 2 | Accepted answer
What is "valid"? Who decides?

Any set of strings is, [formally speaking, a "language"](https://en.wikipedia.org/wiki/Formal_language), whatever it looks like and however the rules for determining what is in it are defined. In this sense, RFC8259, JSON Schema, and your schema provide the rules, and the strings meeting those rules are the words of the language. It's certainly valid and accurate to say this is a language in that sense.

A configuration language may have some attached semantics as well, which aren't part of this particular definition of "language". Those might make it more useful to refer to the whole package of permitted syntax and required semantics as a unit as a language, or they might be so decoupled that the serialisation format is irrelevant and it's less useful. You have more information to determine that with.

---

A domain-specific language is a language made for mechanical processing intended for some specific area of application. Sometimes those are freestanding (external DSLs), sometimes they are created within the syntax of another language (internal DSLs), and sometimes they sit in some nether space. It's not an inherent property of the language, but one about its purpose and usage; we don't really have the information necessary to assess that here, but my evaluation wouldn't matter anyway.

There are a number of DSLs built out of JSON, such as the query languages used in databases like MongoDB, or out of similar data serialisation languages like YAML, such as Ansible playbooks. Some of these have evolved to reach fairly complex points where they amount to general-purpose imperative programming languages with terrible developer experience; I don't think there's much controversy over calling those DSLs even among more restrictive audiences.

Configuration languages more typically are largely declarative, and the line between data containing information about something and a declarative programming language defining what the shape of something should be is not clear. It's probably reasonable to say that defined JSON dialects intended to be written by humans are in most cases some sort of DSL, and others might be too. For the purposes of *this site*, questions about parsing, typechecking, error reporting, and usability design of JSON-embedded languages to the extent that they parallel typical programming language issues [are considered part of programming languge design and implementation](https://langdev.meta.stackexchange.com/q/30/133). There are also bona fide programming languages that are serialised to JSON, such as [Scratch](https://en.scratch-wiki.info/wiki/Scratch_File_Format_%282.0%29), and that format doesn't change anything about the language itself.

---

However, a more practical question lurking behind the scenes here is... why? Terms have meaning so far as they're understood by the audience, and so far as they're useful for communicating about the topic at hand. It's neither an achievement nor a condemnation for something to be a language or not, to be a DSL or not, and so on.

Is *this* a language? Defensibly, certainly. Is *this* a DSL? Sure, it could be. Are those terms useful for describing it? They could be, or they might mean nothing to the audience, or they might actively confuse matters. These are the most useful considerations, rather than generosity or validity according to some authority. I would probably feel comfortable referring to a firmly-constrained configuration language as a DSL in most cases, but I also probably wouldn't stretch to do so.
---
### Answer by username_4 on 2024-04-30. Score: 0
A very well defined configuration file format is a domain specific language, according to the [Wikipedia page that you have linked](https://en.wikipedia.org/wiki/Domain-specific_language). However, it is not a domain specific programming language, which is what people typically think of when they hear domain specific language.

JSON is typically considered a data interchange language, so a subset would likely be considered to be a dialect, instead of a language, unless it was being processed completely differently from regular JSON.

Your configuration file format would seem to be a domain specific dialect; however, for clarity, you might want to think about just calling it a domain specific configuration file format, or simply a configuration file format.
---
