Talk:TOML
This article is rated Start-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||
|
Notability
[edit]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)
Poor quality citation.
[edit]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)
- 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)
Bias in criticism against toml
[edit]The discussion below has been collapsed by NotEnoughWikiContributors due to its length. --RedPint (talk) 01:02, 17 October 2021 (UTC)
- 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.
See also PEP 0518
DGerman (talk) 16:31, 1 September 2022 (UTC)
Bias in criticism against toml?
|
---|
I'm super new to editing wikipedia articles and I'm not experienced or knowledgeable about language design, so I'm merely talking about a pattern I feel I noticed. Also I haven't done full-on fact checking yet so please correct me if I'm wrong. I feel that some criticisms against TOML in the "Criticism" section are somewhat biased and that the bias should be mentioned: See also PEP 518 StrictYAML's criticism on TOML seems to:
Libconfini seems to also criticize TOML for lack of INI compatibility, even though TOML was never meant to provide backwards-compatibility for INI files. Libconfini also seems denote verbose syntax and the necessity of using quotes for strings as "bad", which I disagree with, as verbose syntax can reduce unnecessary errors that come from not specifying a value as a string. For example in YAML: # Should be a string.
First Name: Christopher
Last Name: Null
Null would be interpreted as a null value instead of a string. If strings were wrapped around it, then it would have been clear to the parser that "Null" is a string. - NotEnoughWikiContributors (talk) 05:25, 11 October 2021 (UTC)
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.
The application could just treat it as lowercase. Is this a problem?
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.
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.
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.
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.
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.
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.
Point 18: Performance[edit]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 was meant to be easy-to-read, not easy-to-edit.
libconfini vaguely criticizes TOML's aesthetics with no basis for a sound and valid argument.
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)
|
Pronounciation of TOML.
[edit]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)
- 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)
Comparisons
[edit]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)
- 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)
- 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)
Criticism
[edit]@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)
- @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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)