Talk:TOML

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Software (assessed as Low-importance).

Notability

TOML is in an awkward place regarding notability. I cannot find any reliable secondary sources which refer to it, but there are many secondary sources available which are not considered reliable, and it is mentioned in the documentation for the pieces of software which use TOML. The format is only semi-formally specified since it changes so frequently, therefore there are no RFCs or standards documents to cite.

On the other hand, TOML is used as a configuration file format for the package management tools pip (Python) and Cargo (Rust), which are the de facto standards for their respective programming languages.

Especially given the growing popularity of TOML, I don't think it is beneficial to remove this page. Alternatively, it could be merged with the Configuration file page after restructuring it.

There was a maintenance template suggesting WP:PRODUCT was relevant, but TOML is more or less a community project, and I'm not sure TOML belongs on the page for Tom Preston-Werner, though it did make me consider the possibility of merging with Configuration file. I have changed the use of the maintenance template so that it refers to the general notability guidelines.

DpEpsilon ( talk | contribs ) 05:22, 23 September 2018 (UTC)[reply]

Poor quality citation.

One of the state citations is just some random person saying it's hard on y-combinator. I'm gonna add poor quality source to it. — Preceding unsigned comment added by Sugarfrosted (talk • contribs) 09:02, 12 January 2021 (UTC)[reply]

Shouldn't that row from the table be removed entirely? "Easy implementation" seems like a completely arbitrary standard. While you could use something like spec length to compare different formats, including such a measure as a legitimate comparison point seems unfounded in evidence or even discussion by anyone other than the editor who added that row in Rdelfin (talk) 21:01, 30 May 2021 (UTC)[reply]

Bias in criticism against toml

The discussion below has been collapsed by NotEnoughWikiContributors due to its length. --RedPint (talk) 01:02, 17 October 2021 (UTC)[reply]

User NotEnoughWikiContributors collapsed this section (according to RedPint) stating "due to its length" without providing a summary. Neither has. user page. This is a talk page not an article. Many the ideas mentioned in the article show significant bias! One persons 'right' is another's "not-left" i.e. some negative comments can be considered positive features.

JSON human readable?? Talk about TOML as "syntactically noisy"

TOML too many features??

" square brackets for arrays even though square brackets are already reserved for table names; "

If this section is collapsed a summary should be included. Better yet bias in the article should be removed.

Point 1, 2, 5, 6, and 12

libconfini argues that since the application will just decide the data types and there are multiple data types in TOML, it is unnecessary to have multiple data types. However TOML was designed to be have values easily parsed to various data structures, so verbose syntax is naturally going to accomplish this goal the best, due to the reduction of ambiguity. If the only data types were tables, strings, and arrays, it would be more difficult to easily parse TOML files.

For example: If an application were to use an INI format, since INI files only use the string data type, the application would need to manually parse each individual value to convert the data, which would make parsing values to data structures, even if they were to use an INI parser.

I don't understand this objection. A TOML parser will parse strings too (a plain text file contains only strings), but will have to deal with the additional task of having to deduce a type from the syntax and check if this matches with what the application requires, while an INI parser will go straight to the type requested by the application. How is TOML easier to parse? As for the ambiguity, I would need an example where INI is ambiguous. --RedPint (talk) 08:24, 13 October 2021 (UTC)[reply]

Point 3: Case Sensitivity

The application could just treat it as lowercase. Is this a problem?

Yes. A TOML parser is not designed to do that. For example, a TOML parser will likely have a lookup() function for searching for a key. If you are looking for a key named TOML and you use toml it will just not find it. --RedPint (talk) 08:24, 13 October 2021 (UTC)[reply]

Point 4: Unicode key names

I don't really understand libconfini's argument here, as they seem to imply that requiring enclosed quotes for keys in Unicode is bad (because it introduces unnecessary complexity), without specifying the reason as to why.

A TOML parser could potentially interpret an unquoted unicode key as if it had ASCII characters (say a unicode character producing an ASCII space or tab), which would result in having to parse the whole TOML file as if it was full Unicode.

Requiring keys to be quoted to have unicode reduces ambiguities that the application would have to deal with.

You keep using the word "ambiguity" without explaining it. What kind of ambiguity can an application deal with because of Unicode characters? --RedPint (talk) 08:24, 13 October 2021 (UTC)[reply]

What I mean is that a TOML parser (that only parses ASCII) could potentially misinterpret a Unicode character as a different character (like a newline or space). Sure TOML parsers could add unicode support to parse unquoted unicode key names, but that unneccessarily increases the complexity of TOML parsers. - NotEnoughWikiContributors (talk) 23:25, 13 October 2021 (UTC)[reply]

A TOML parser needs to support non-ASCII characters (UTF-8), the TOML specification requires it. But after being able to read Unicode characters, a TOML parser is also required to throw an error if Unicode characters and spaces are out of quotes in key names. The reason? Unknown. --RedPint (talk) 00:51, 14 October 2021 (UTC)[reply]

Also some programs would want spaces to be in keys. - NotEnoughWikiContributors (talk) 23:25, 13 October 2021 (UTC)[reply]

Generally INI parser have no problems with spaces in keys. --RedPint (talk) 00:51, 14 October 2021 (UTC)[reply]

9. Dates

There are valid use cases for having time data types in TOML. Not only do date, time, and date-times data types make parsing date/time values easier, they also make the value clear to the reader that it is a value describing date or time, which also accomplishes TOML's goal of being obvious.

Sure. As libconfini says, "why not doing that for a path? Or a username? Or an email address? Or a regular expression? …Or a continent name? These have all a more constraining semantics than dates". Most applications need those more often than dates – OK, maybe not continent names... So, why exactly dates? --RedPint (talk) 08:24, 13 October 2021 (UTC)[reply]

I can't find Tom's reason for having date/times in TOML, so I'm going to try and derive the reason.

I think date times are in TOML for mostly readability reasons (as TOML is meant to be easily readable). After all to a reader TOML date(times) are expressed without quotes, so it would (ideally) express to the reader that date(times) are a numerical value, not a string value.

Side note: I think the expression of TOML's design goal of being "easy to read due to obvious semantics" is vague. TOML could be trying to be easily readable for applications instead of humans, or it could be attempting to be easily readable by only humans or both. I think that goal should be elaborated upon as to not stir confusion. - NotEnoughWikiContributors (talk) 20:21, 13 October 2021 (UTC)[reply]

You can ask them. The way I read it is "easy for humans". The easiest thing to read for machines are binary files that map exactly the applications' memory (often these files are called .dat files).

There's no reason to make a custom data type for (file) paths, usernames, email addresses, regular expression, or continent names, because they can easily be expressed as strings. - NotEnoughWikiContributors (talk) 20:21, 13 October 2021 (UTC)[reply]

Same goes for dates. If you want arguments in support, TOML never explained why dates, and no configuration format ever felt the necessity to create a "date type". Honestly it looks like the date type is just randomly there. --RedPint (talk) 21:20, 13 October 2021 (UTC)[reply]

@eddelbuettel brought up a good reason for date times.

> Strings are a problem for the same reason we prefer strongly typed `int64_t`, `double`, `bool` in the rest of the TOML spec: Typing adds value. If I wanted to mess around with strings and the "can only parse later but not when reading the file" approach I could stick with JSON or a dozen other (inferior) config formats. That TOML can parse (and hence _validate_) datetime objects is a core strength of TOML. Removing datetimes would greatly reduce the usefulness of TOML.

> [I already did 20+ minutes ago. So let me repeat more explicitly:] We have (large, complex) parameter estimation configurations which change through time and have before/after/during date(time) boundaries. Certain setups are valid, then change into other setups. I turned to TOML (and currently work on R support for it) because date(times) are native for TOML. - NotEnoughWikiContributors (talk) 19:32, 15 October 2021 (UTC)[reply]

Thanks for the research! My comments:

"Typing adds value" Unless you use something similar to XML Schema (W3C), which does add value – and TOML does not use anything similar to that – typing adds a further obstacle and discourages using comments as sorts of schema substitutes (things like "Please use a number between 51 and 109 for this key", and so on, which is what I really love about INI files – P.S. How does TOML deal with numbers that must remain between 51 and 109?).

"Unless you use something similar to XML Schema (W3C)"

I beg to differ. XML is pretty complicated and hard to read, so it isn't really good for smallconfiguration files. - NotEnoughWikiContributors (talk) 03:30, 16 October 2021 (UTC)[reply]

I agree that XML is not human-friendly. I wasn't proposing using XML, I was saying that the only way to ensure proper validation is to schematize things (it doesn't have to be via XML, it just needs to be a schema; even an INI file can have a schema written in INI, and in that case INI will properly support data types, but still avoiding syntax typing – e.g. where a number is expected you can write indifferently 15 or "15", but not "Wikipedia"; INI data types will always be content-based and not syntax-bases, more or less like what happens in Bash) --RedPint (talk) 05:10, 16 October 2021 (UTC)[reply]

"P.S. How does TOML deal with numbers that must remain between 51 and 109?"

It doesn't as there's no need for the language to deal with min-maxes; just save it as an inline table with two integers (one as the minimum, the other as the maximum), and let the application handle that. Same also goes for INI files, except there is no explicit type, so the application has to manually translate . - NotEnoughWikiContributors (talk) 03:30, 16 October 2021 (UTC)[reply]

I made a very specific example on purpose, but I could have made the example of unsigned numbers, which are a common data type in programming languages. How does TOML force a number to be non-negative? What I am saying is that the language that is truly able to express data types is INI, because the application is truly allowed to establish its data types freely. With TOML instead data types need to be filtered by the official TOML syntax, which becomes counter-intuitive in front of custom data types, small sets of enumeration labels, continent names, and so on. --RedPint (talk) 05:10, 16 October 2021 (UTC)[reply]

"TOML can parse (and hence _validate_) datetime objects is a core strength" That is crazy. Validating email addresses must be the next revolution in configuration files then. But when we will reach the point of validating continent names as primitive data types it will be the ultimate configuration format.

There is no need t

Something missing here? --RedPint (talk) 05:10, 16 October 2021 (UTC)[reply]

Yes I forgot to finish the sentence. Anyway how is that crazy? - NotEnoughWikiContributors (talk) 23:43, 16 October 2021 (UTC)[reply]

It is crazy to define something as trivial as dates as "a core strength of TOML". That makes the language look rather poor. Validating email addresses is more sophisticated than validating dates; I suppose that if I create a configuration format that validates email addresses I easily beat TOML. Plus, email addresses are way way more often necessary than dates. Also treating dates differently makes the fact that all other custom data types must be represented by quoted strings look even uglier. --RedPint (talk) 01:02, 17 October 2021 (UTC)[reply]

"Certain setups are valid, then change into other setups. I turned to TOML (and currently work on R support for it) because date(times) are native for TOML" The guy talks about a very specific problem. I am sure somewhere in the world there is a person who would love continent names to be native data types so that they can validate their configuration files without having to write code. Validating dates is a trivial task for every application, it literally requires two-three lines of code using standard tools. --RedPint (talk) 21:09, 15 October 2021 (UTC)[reply]

I think they are talking about having to between time formats, which I agree with. When there is no one preexisting data type for time, developers just make their own format, similar to how people will make their own ideal standard format, which can result in difficulty translating time formats between multiple programs (just look at a bunch of foreign JSON, YAML, and XML files that store time as an example). It is not easy at all to maintain compatibility for most proprietary formats, and it is practically impossible to maintain full compatibility with each time format. I can easily imagine INI files having compatibility issues, since INI dialects can vary widely across lots of programs.

e.g 1 program stores date-time as DD/MM/YYYY-SS:MM:HH, a second stores date-times as YYYY/MM/DD:HH:MM:SS, and another stores MM/YYYY/DD:SS:HH:MM. If 1 of these program were to use an INI parser, the application would have to manually translate a value into it's used time format, potentially with the program failing due to the correct time value being stored as the incorrect format. Granted these time standards are nonsensical, but they are to convey my point: it is not easy to translate times.

Developers also had this issue when it came to counting time back in the 70s. Overall it can be potentially difficult to support multiple programs at once. - NotEnoughWikiContributors (talk) 03:30, 16 October 2021 (UTC)[reply]

There is no standard way of writing dates (or better, there are several standard ways), so the best possible choice is to leave freedom (after all, why should a configuration format prefer a format above another? what is the gain?). The strptime() Unix function can deal with the most common formats (Unix is the standard here, so that function is findable under other names also on MS Windows). --RedPint (talk) 05:10, 16 October 2021 (UTC)[reply]

This discussion is getting long; is there a template for collapsible boxes? - NotEnoughWikiContributors (talk) 03:30, 16 October 2021 (UTC)[reply]

See Help:Collapsing (but I am not sure we should). --RedPint (talk) 05:10, 16 October 2021 (UTC)[reply]

This discussion takes a lot of space, so I'm going to collapse it. Since this discussion is getting pretty long, if you want to converse with me any further on this topic, bring it to my talk page. - NotEnoughWikiContributors (talk) 23:37, 16 October 2021 (UTC)[reply]

I added a note at the beginning of the section. I think we can leave it like this. It was a nice discussion, thank you. --RedPint (talk) 01:02, 17 October 2021 (UTC)[reply]

10. Empty key names

This is the only point that I agree with. Empty key names should be illegal, because there is no reason for a config file to have empty key names, since it is harder to identify information in empty keys.

Good, at last. --RedPint (talk) 08:24, 13 October 2021 (UTC)[reply]

14. Incompatibility

TOML was not designed/meant to be compatible with INI. Even if it was, there are a large amount of various INI dialects, so it would be difficult to make a TOML language that is also compatible with INI files.

It did not even try. Such a critique makes perfect sense from the point of view of an INI parser written to deal with different dialects. --RedPint (talk) 08:24, 13 October 2021 (UTC)[reply]

TOML was never meant to be compatible with INI files, so no Tom did not try to make TOML compatible with INI. I disagree with the critique because as @BurnSushi puts on github: Trying to be compatible with the majority of INI dialects would make the specification more complicated, which goes against TOML's design goal of being easy to read. - NotEnoughWikiContributors (talk) 19:32, 13 October 2021 (UTC)[reply]

Exactly, so it did not even try. That would not be a sin if only TOML was not so similar to INI, almost a copy. As for the "more complicated specification", reading the documentation of libconfini does not look more complicated to me than reading that of TOML (and with the exception of arrays of tables/sections, libconfini supports in INI all the hierarchy and data types that are supported by TOML – while the latter does not support many features that libconfini supports, like disabled nodes, implicit keys, relative section paths, and so on). --RedPint (talk) 21:20, 13 October 2021 (UTC)[reply]

15. Immediacy

libconfini assumes that configuration files are meant to be able to be human-editable. This is not always the case, as there are configuration files that are not meant to be easily edited by humans.

...And when they are not, they are not "immediate". Wasn't "Obvious" part of the TOML acronym? --RedPint (talk) 08:24, 13 October 2021 (UTC)[reply]

Immediate and obvious are two different terms. Obvious is to be easily discovered, while Immediate is in a short time. It is impossible for a language to be immediately understood upon reading due to the nature of learning an unknown language, but if the language is obvious in it's syntax and easily readable (which is what TOML aims to be), the reader could potentially understand easier.

I will answer your other responses when I get enough energy. - NotEnoughWikiContributors (talk) 19:14, 13 October 2021 (UTC)[reply]

I get your point of view and it is OK, we don't have to fight at all costs. We can also just agree to disagree. --RedPint (talk) 21:20, 13 October 2021 (UTC)[reply]

Yeah. I don't want to go in a rabbit hole debate to try to "win", so I'll end my arguments here. Honestly you gave me some new points that I have never thought about so thanks. - NotEnoughWikiContributors (talk) 23:22, 13 October 2021 (UTC)[reply]

I am glad if I did that. You are very welcome. --RedPint (talk) 00:51, 14 October 2021 (UTC)[reply]

16. Genesis

libconfini gives a fallacious emotional argument that TOML is worse than INI because TOML was made out of Tom Preston-Werner's (hereby shortenable to Tom) dislike for INI's unquoted strings.

Also libconfini fallaciously misquotes Tom's reason for not including unquoted strings.

Libconfini criticizes that fact that disliking something aesthetically is not enough of a reason for creating a language that makes life more complicated. As for the fallacy, I don't understand where you see it. --RedPint (talk) 08:24, 13 October 2021 (UTC)[reply]

That is not what Tom did though. He created the TOML format due to a lack of a standard configuration file format. Sure making another file format standard could make parsing files more complicated, but was that ever a problem when other file formats arose (like JSON and YAML)? - NotEnoughWikiContributors (talk) 19:25, 13 October 2021 (UTC)[reply]

This sounds exactly like this illustration. --RedPint (talk) 21:20, 13 October 2021 (UTC)[reply]

Yeah. It's a general pattern. These days I think of standards as general handlers that people can reliably use. - NotEnoughWikiContributors (talk) 23:22, 13 October 2021 (UTC)[reply]

The fallacy is in where libconfini misquotes Tom's reasoning for the birth of TOML. Tom made TOML because he hated how unquoted strings were allowed because they are unambiguous and can be confusing for readers. However Libconfini fallaciously simplifies the quote as if Tom didn't like the aesthetic unquoted strings looked.

"I hate how unquoted strings look, so I'll make a language!"
"I hate unquoted strings because they are inherently ambiguous and they go against TOML's design goals."

The two statements above have different meanings. The former states that the person made a language because of an aesthetic they didn't like, but the latter states that the person made a language because there was no configuration file format standard and that unquoted strings go against TOML's design goals. That is why I consider libconfini's quote to be fallacious - NotEnoughWikiContributors (talk) 19:25, 13 October 2021 (UTC)[reply]

Tom Preston-Werner literally says "TOML came about precisely because I can't stand unquoted strings in things like YAML and INI.". So a fallacy would be reporting the opposite. After saying that he created TOML because he "can't stand" unquoted strings, he adds that unquoted strings are ambiguous. On the other hand libconfini illustrates how quoting things instead can create ambiguity, showing the example of continent = Europe, where quoting "Europe" will make you believe that it is a free string, while according to it it is a sort of enumeration label out of only five possible continents, and in configuration files most "strings" are actually like Europe. --RedPint (talk) 21:20, 13 October 2021 (UTC)[reply]

I looked over the quote and realized that I conflated Tom's reasoning for creating TOML (disliking unquoted strings) with how unquoted strings are ambiguous, so sorry about that. Even still I don't really think that the birth place of a standard matters all that much when criticizing TOML. - NotEnoughWikiContributors (talk) 23:22, 13 October 2021 (UTC)[reply]

It is not the birth place, it is the birth motivation. That yes, may have an impact on the result. --RedPint (talk) 00:51, 14 October 2021 (UTC)[reply]

With the content = Europe example, while programs will technically parse that value in as an enumeration label, the program will still take the value as a string, so it should be denoted that the value is a string; otherwise someone could erroneously think that Europe is a custom data type, when it is in practice a string that is parsed by the program as a custom data type. - NotEnoughWikiContributors (talk) 23:22, 13 October 2021 (UTC)[reply]

While in the file, everything is a string – this is simply the definition of plain text files. When both an INI parser and a TOML parser read either Europe or 1999 they simply tokenize these two strings, but they are still strings. At this point though an INI parser simply waits the application before assigning any data type. In the case of 1999 the INI parser will likely have a number parser included, so it can pass it to the application directly as a number (if that is what the application asks for); in the case of Europe instead, being a custom data type (yes, it is a data type), it will pass it verbatim (as the original string) to the application, and the application will have its own "continent data type parser". As for the TOML parser instead, it will automatically convert the 1999 string into a number and pass it to the application as such no matter what, while Europe will generate an error no matter what (unknown data type). --RedPint (talk) 00:51, 14 October 2021 (UTC)[reply]

Point 18: Performance

Sure TOML would be typically slower to parse to due to the complexity of the language, but in practice this point is moot because:

TOML is meant to be a minimal configuration file format (as in it is for small configuration files). If a TOML file is large enough to take a long time to parse, then at that point TOML would be misused here, because it is not designed for large configuration formats.
Configuration files rarely need to be large enough to cause slowdowns with the parser.

As a language, TOML is not minimal (of the four formats listed in § Comparison to other formats it is probably the most bloated one). If a bloated language is designed for small files something is probably not right (you would normally want a bloated language for a bloated file, not the other way around – and even there, you will probably try to avoid bloated languages at all). As for the size, configuration files of large projects can be really huge. --RedPint (talk) 08:24, 13 October 2021 (UTC)[reply]

The homepage's description of how TOML was meant to be minimal is vague, due to the grammar. Tom could have meant minimal as in small configuration files, minimal as in small language-bloat, or minimal as in quick to parse. However I wouldn't blame you if it turns out that TOML was designed with a different meaning of 'minimal' than first implied, or if I misinterpreted the goal. I currently interpret 'minimal configuration file format' to be small configuration files.

TOML is not meant or designed for large configuration files; only minimal configuration files, so trying to use TOML for large configuration files is like trying to use a hammer to insert a screw; Sure you could technically insert a screw with a hammer, but it would be more effective to use a screwdriver.

Not all bloat is neccessarily bad though. Sometimes enough people need a bloated feature to be useful to keep it in, even if the feature is not used by the majority of people. - NotEnoughWikiContributors (talk) 20:21, 13 October 2021 (UTC)[reply]

You show quite some confidence in interpreting what TOML's goal is supposed to be. How about documenting your beliefs? --RedPint (talk) 21:20, 13 October 2021 (UTC)[reply]

19. Human-friendly vs. human-readable

TOML was meant to be easy-to-read, not easy-to-edit.

Ah OK, if that is on purpose nothing to say. --RedPint (talk) 08:24, 13 October 2021 (UTC)[reply]

20. Aesthetics

libconfini vaguely criticizes TOML's aesthetics with no basis for a sound and valid argument.

I will give you that. --RedPint (talk) 08:24, 13 October 2021 (UTC)[reply]

> You might wish you had a way to force Null to be parsed as null instead of "Null", but it is not up to you to decide what data type Last Name is, and the application will anyway have the last word. As libconfini says, a mismatching data type in TOML is either sanitized (and in this case TOML behaves like INI), or discarded (and so your wish to force Null to be parsed as null instead of "Null" is not met). In configuration files you have no ways to force anything. Unless you have any concrete example where INI risks to be ambiguous, libconfini does have a point.

If TOML was designed/meant to be human-editable, you would have point. However TOML is only meant to be an easy-to-read and easy-to-parse format for minimal configuration files; it was never meant to be easily editable, because configuration files generally do not need/are not intended for manual edits. - NotEnoughWikiContributors (talk) 06:52, 13 October 2021 (UTC)[reply]

You repeat that TOML was not designed to be human-editable, although such a statement would require a source. The reason of having a configuration file is only that of letting it be editable by a human. If you don't need your configuration to be editable you would use a binary format, which does not need parsing at all and maps directly into the program's memory.

Last but not least, this discussion cannot be about the configuration languages that some Wikipedia editors like the most. It should be about the TOML article. As it is now, it only contains a § Criticism section in the end. Since critiques of TOML exist, it seems fair to me. --RedPint (talk) 08:24, 13 October 2021 (UTC)[reply]

The TOML homepage does not describe TOML as being a 'easy to edit by a human' format.

I brought the idea that "the flaws in critiques against TOML should be mentioned" up because the Effects of pornography wikipedia page brings up that there are a fair amount of issues with the current research on the effects of pornography (bias, lack of substantial sample size, and narrow sample types which does not account for other types of romantic relationships). So I got the idea that I think these points should at least be mentioned in the wikipedia page, so as to not be biased. - NotEnoughWikiContributors (talk) 20:21, 13 October 2021 (UTC)[reply]

If you can document the opposite points of view, yes, why not? You cannot amend a critique, but you can show opposite points of views. Consider though that this page in particular suffers the fact that it relies too much on primary sources, as the banner in the lead shows. So, secondary sources would be needed. --RedPint (talk) 21:20, 13 October 2021 (UTC)[reply]

Yeah. I guess it would be ok to do so. - NotEnoughWikiContributors (talk) 23:22, 13 October 2021 (UTC)[reply]

Pronounciation of TOML.

Are there general pronunciations for 'TOML'? The only pronunciations I can think of are tom-el and t-AH-mel. - NotEnoughWikiContributors (talk) 20:27, 23 November 2021 (UTC)[reply]

The full name is "Tom's Obvious Minimal Language". So tom-el is the natural choice. 148.64.20.31 (talk) 01:53, 23 September 2022 (UTC)[reply]

Comparisons

I think the comparison section is heavily biased against TOML. It doesn't mention aspects that are important to configuration files that happen to be in TOML's favor such as support for date, time, and date/time values (an issue with JSON) and the ability to safely load external data (an issue with XML and YAML, as they both load other documents by default).

The "Human Readable" section should be removed completely. The term "human readable" just means that you don't need to decode some binary representation in order to understand it. That includes all of those languages. (Also, singling out XML is just plain weird.)

In the "Syntax Typing" column, YAML is problematic. It decides if something is a string or boolean based on a magic list of words, not the syntax, sometimes.

In "Allows Comments", it should be noted that while JSON doesn't formally support them, many parsers do.

CUE isn't even popular enough to have a page of its own. So why is it in the chart?

In short, the whole comparison is a mess and probably should be deleted. If a comparison is desired, it should be started over from scratch on its own dedicated page. — Preceding unsigned comment added by 148.64.20.31 (talk) 02:06, 23 September 2022 (UTC)[reply]

How about something like the percentage of "noise" characters (where keywords and values are considered length =1)

For example:

JSON:

{

"firstName": "John",

"lastName": "Smith",

"isAlive": true,

"age": 27,

"address": {

"streetAddress": "21 2nd Street",

"city": "New York",

"state": "NY",

"postalCode": "10021-3100"

},

Evaluation :

{

"f": "J", "l": "S",

"i": t,

"a": 27,

"a": {

"s": "2",

"c": "N",

"s": "N",

"p": "1"

},

text: 17

quotes in keywords: 18.

quotes in value strings:12

quotes in numeric entries :0

commas separating entries where spaces would do: 8

(18+12+8)/(18+12+8+17) = 69%

++++++

TOML:

firstName= "John"

lastName= "Smith"

isAlive= true

age= 27

address= [ streetAddress= "21 2nd Street" city= "New York" state= "NY" postalCode= "10021-3100" ]

Evaluation:

f= "J"

l= "S"

i= t

a= 7

a= [ s= "2" c= "N" s= "N" p= "1" ]

text : 17. good thing it's the same as JSON

quotes in keywords: 0

quotes in value strings:12

quotes in numeric entries :0

commas separating entries where spaces would do: 0

12/(17+12)= 41%

DGerman (talk) 17:51, 6 October 2022 (UTC)[reply]

INI wins easily against both:

firstName=John

lastName=Smith

isAlive=yes

age=27,

[address]

streetAddress=21 2nd Street

city=New York

state=NY

postalCode=10021-3100

Evaluation:

f=J

l=S

i=y

[a]

s=N

c=N

p=1

--93.146.169.112 (talk) 03:55, 1 January 2023 (UTC)[reply]

Criticism

@RedPint Your earlier edits made almost two-thirds of the article "criticism", a rather ridiculous ratio and no file format has anything near that length for its criticism section (in absolute terms).

Both references are self-published sources from competing formats. "Coca-cola says Pepsi is bad". They're not even particularly good references. e.g. when that libconfini came up on HN last month it was not especially well received. You added that HN link yourself as a reference earlier (which is not really appropriate by the way), so surely you're aware of that?

Your entire edit history is about this topic (INI files and TOML), and it seems you're the author of that article(?)

Now you keep adding a separate paragraph for your article again and again, because People Really Need To Know This™? It's already cited in reference 11 (at the time of writing), and that's enough. And TOML is not "problematic"; you subjectively don't like it. That's completely fine, but something different.

Quite frankly the only reason I haven't just removed it outright as "biased self-published esoteric opinion few people seem to agree with that seems to have been added here by the author themselves" is because I maintain some things in the TOML ecosystem and aren't entirely neutral myself either, so I only did what seems like a complete no-brainer that no (neutral) editor could really disagree with, IMHO.

Wikipedia is not the venue to demonstrate that "people are Wrong!"

So I reverted your edit again. Arp242 (talk) 02:18, 1 November 2023 (UTC)[reply]

@Arp242: I will try to be synthetic:

Yes, I contributed to this section of Wikipedia, which means that I did not discover yesterday the topic of configuration files
No, I have not created the INI file page, although I have contributed to it in the past, exactly like I have contributed to this page
Yes, I follow these pages, which means that when they get changed I receive a notification
Yes, I prefer INI files to TOML, which allows me to bring value to Wikipedia exactly like who prefers TOML to INI files
One of the things I tolerate the least is insincerity. You have first removed a critique of TOML saying that "half of the article being "criticism" is disproportionate". Therefore I followed your suggestion and reintroduced only a reference to it. But then you removed it again, saying that "It's already referenced". Knowing that it was not referenced anywhere reintroduced it pointing out your mistake. Finally you have removed it again simply saying "Revert again – see". But see where? And what?

Your inconsistent behaviour would be already enough to be considered disruptive. But I would still like to know why according to you one of the few sources that addresses some critical aspects of TOML must be removed. The only explanation I can find, after you wasted several reverts, is the following (and honestly it is a horrible explanation, which can be more or less summarized as "I like TOML, so I will remove both critiques and praises"):

Quite frankly the only reason I haven't just removed it outright as "biased self-published esoteric opinion few people seem to agree with that seems to have been added here by the author themselves" is because I maintain some things in the TOML ecosystem and aren't entirely neutral myself either, so I only did what seems like a complete no-brainer that no (neutral) editor could really disagree with, IMHO.

--RedPint (talk) 07:15, 1 November 2023 (UTC)[reply]

Correction. There was indeed still a footnote after you removed my sentence, so I was wrong in saying that it was not already referenced. But then frankly it sounds extremely non-NPOV having a reference but discouraging the explanation of the reference in the text. What you like or not like might not be the same thing that other people like or not like. --RedPint (talk) 07:23, 1 November 2023 (UTC)[reply]

The bullet-point list *is* "the explanation of the reference". Most items on that libconfini list are uncommonly held views, so it includes just the items that both references share. If you want to add more then a good first step would be to find more appropriate references (as I mentioned, the two existing only barely qualify as "appropriate references", IMHO). Arp242 (talk) 16:04, 1 November 2023 (UTC)[reply]

This makes little sense. I was the one that added the reference to "An INI Critique of TOML", and when I did that the bullet points were already there, exactly as you see them now. So you are basically saying "Add as many references you want, as long as you don't touch this sacred list". The obvious question that will follow is "Why is that?". The "INI Critique of TOML" adds its own points to that list (you might want to read this discussion), and even if a reader is in love with TOML, the various critiques that we present in the article might make them reflect about something they might not have thought about. But what is more important, I wasn't even quoting the specific points, I was only mentioning that they exist. You keep referring to that critique with words like "esoteric", "uncommonly held views", etc., but did it ever cross your mind that maybe for some people TOML might be the esoteric/illogical/inconsistent/add-here-your-adjective thing? I understand that we live in an era in which people create their own social bubbles and hang out just with their tribes, but damn! This is still Wikipedia. --RedPint (talk) 04:15, 2 November 2023 (UTC)[reply]

You don't need to "mention it exists" because it's already referenced. I am not here to discuss TOML's merit or lack thereof and I don't care what people think of it one way or the other. If you want to add to that list then find additional appropriate references. Arp242 (talk) 10:40, 2 November 2023 (UTC)[reply]