Talk:YAML

message: Thanks to everyone that assembled this great summary of YAML. You guy's rock! Seriously, this is page looks perfect to me. As a casual Wikipedia browser, my only suggestion would be to remove the dust-brush from the design section. It may be technically correct, but dude! It's such a short section why nit pick? The big banner seems like an easy way to seem like you care about the content without really doing anything and at the same time makes the page look trashy.  — Preceding unsigned comment added by 58.174.104.151 (talk) 14:33, 7 November 2019 (UTC)
thread_title:  Nice page 

message: I created the page 'data-oriented design' r.e. the videgame programming methodology. A link to it appeared here, however I'd guess they really wanted dat-driven design or something.  
Any suggestions on a fix... should 'data oriented design' be a disambiguation page, and we rename the current page content 'data-oriented design (video games)'?
Fmadd (talk) 11:12, 9 September 2016 (UTC)
thread_title:  Link to 'data-oriented design', should it be 'data-driven'? 

message: The POD doc for JSON::XS states:
::You often hear that JSON is a subset of YAML. This is, however, a mass hysteria(*) and very far from the truth (as of the time of this writing), so let me state it clearly: in general, there is no way to configure JSON::XS to output a data structure as valid YAML that works in all cases.
And later on:
::I have been pressured multiple times by Brian Ingerson (one of the authors of the YAML specification) to remove this paragraph, despite her acknowledging that the actual incompatibilities exist. As I was personally bitten by this "JSON is YAML" lie, I refused and said I will continue to educate people about these issues, so others do not run into the same problem again and again. After this, Brian called me a (quote)complete and worthless idiot(unquote).
::In my opinion, instead of pressuring and insulting people who actually clarify issues with YAML and the wrong statements of some of its proponents, I would kindly suggest reading the JSON spec (which is not that difficult or long) and finally make YAML compatible to it, and educating users about the changes, instead of spreading lies about the real compatibility for many years and trying to silence people who point out that it isn't true.
::Addendum/2009: the YAML 1.2 spec is still incompatible with JSON, even though the incompatibilities have been documented (and are known to Brian) for many years and the spec makes explicit claims that YAML is a superset of JSON. It would be so easy to fix, but apparently, bullying people and corrupting userdata is so much easier.
This article currently states that "JSON syntax is a subset of YAML version 1.2," which may not be strictly true. Any opinions? — SamHathaway (talk) 20:28, 16 January 2013 (UTC)
replies: text: From a practical pov, the inability to accept unpaired surrogates is an incompatibility with JSON, or at least with the vast majority of JSON implementations that do accept them. As Windows filenames can contain unpaired surrogates this is a problem since you can no longer put Windows filenames into the "string" datatype.Spitzak (talk) 20:06, 7 February 2022 (UTC)

text: JSON explicitly allows the utilization of tabs as whitespace, which is not allowed in YAML. Any valid JSON file using tab indentation is thus not a valid YAML document. 178.27.112.87 (talk) 12:50, 27 October 2022 (UTC)
replies: text: In "JSON-style data" (ie surrounded by delimiters like {} and []) YAML treats all whitespace, including tabs, identically. It does not matter how it treats whitespace for non-JSON-style data where the indentation is part of the syntax, that part does not intersect the JSON-compatable part.Spitzak (talk) 20:51, 27 October 2022 (UTC)
replies: text: I guess I have to file a bug to pyyaml… 178.27.112.87 (talk) 19:49, 28 October 2022 (UTC)
thread_title:  JSON is still not a subset of YAML 1.2? 

message: :: First I'll repeat that you are proceeding from a flawed analogy.  Let me break this down by showing you the proper analogy.  In your analogy you are comparing an ordered array in XML to a YAML hash.  I realize you don't understand what I'm saying yet so please forgive my pedantic breakdown of the proper XML YAML analogs.  But I think this will clear up the error. 
  Similarly, arrays present a trade-off because arrays preserve declaration order, but are usually addressable only by a numeric index.
:: This last senstence embodies some to the root of the confusion here.  Namely the equivalent syntax you try to strike between XML and YAML are not choosen right.  Here's some better equivalences
 <XML>
      <foo> manchu </foo>
      <bar> car         </car>
      <foo>  to make this obvious I repeat the foo tag </foo>
  <\XML>
  %YAML
  - name: foo
     content: manchu
  - name: bar
     content: car
  - name: foo
     content:  See this is where your analogy goes wrong.  because you could not have two foo taks if you were storing this in a hash.
::  So now you can see that you were writing an ARRAY in XML and trying to compare it to a HASH in YAML.  You needed to compare it to an array like I showed.  Now lets construct the HASH comparison
 <XML>
    <foo  font = "helvetica", size = 7> </foo>
 %YAML
       name: foo
       attributes:
             font: helvetica
             size: 7
:: here we see that it's the attribute portion of XML, not the tag name portion, that is a proper key-value pair or hash.  And we have the same representation of the attributes in YAML as a hash. The premise of the whole section is hung on striking the wrong analogy.  The only point you might make on that score is that it is apparently easy for someone to mistunderstand what parts of XML are used for ARRAY forms and which part are apropos for HASH forms.  But that belongs on the XML page.
:: Look what you are saying here is simply mistaken and your own point of view on YAML, Both of those are reasons it does not belong in a wiki,  Additionally the purpose of a wiki is not to teach nuances of implementation, though perhaps some tips are helpful. In this case however it seems to be trying too hard to make a point that can be dispensed with.  Lets look at the meat to the section:
   Because the two source fragments look substantially similar, one might be tempted to assume that they are processed similarly when loaded into a target programming language. This is not necessarily the case, however, as the YAML instance is capable of translating key-value pairs directly to a hash,[1] whereas the XML instance does not expressly specify any addressing or storage scheme whatsoever.
:: That's a fictional distinction.  XML and YAML use different terms to describe what they represent.  In the XML world one here's people talk about Key-value pairs, named attributes.  In YAML the term Hash is used.  This does not mean that YAML targets a perl hash and XML does not.  IN JSON they call them collections.  Does this mean it's not a HASH?  No they all are expressing a key-value relationship.  But they don't specify the languages container.  
  This difference presents certain trade-offs that may have to be taken into consideration. For example, programming languages such as Perl and Python do not preserve the order of hash key-value pairs as they are originally specified in source code (at least not by default).[6] 
:: Perl and Python have order preserving "hashes" that are standard modules available in all distributions of the languange.  There's not particular reason one has to instantiate a simple hash to be a YAML entity container. 
  This includes those that are defined and loaded from YAML. Instead, nodes declared as hash keys may appear in any arbitrary order when processed and loaded in to the program. 
:: if one specifies order preservation YAML preserves the order.  If is not specified the user has control over how the YAML entities are stored in most yaml parsers.  e.g. event driven parsers play the events in the as-written order of the tokens in the YAML file.  If the user chooses to store the data out of order that's his problem. But the events come in the same order.  The same is true of most XML parsers.  The events happen int he order offered.  But if the user is storing the XML events in a simple non-order preserving hash then they may get out of order.  How for example would you store the named attributes in an XML tag?  Every parser I know uses a HASH. 
:: thus given that the entire section seems to be very misleading and I recommended it's deletion.  Cems2 18:15, 31 October 2007 (UTC)
thread_title:  Viewpoints and breakdown by cems2 

message: : the wiki section needs to be removed because it simply is your interpretation, it's clearly contestable as I have shown, and it's misleading or poorly worded.  Now to try to make this constructive, it would help if you could offer single sentence or two sentence statement of what the section is teaching the reader.  For example, a statement like "YAML contains syntaxes that have no expression in JSON, including relational structures, and extensible type declarations." could preface a discussion of those.  Or a statement like "XML has the notion of Valid in additon to well-formed, yaml only has the latter".   Then one could go on to explain this.  As it stands it raises a dubious strawman, and then...well it's not really clear what's being said.  it seems to rely on language specific implematation idiosyncacies that have nothing to do with the YAML spec.  On top of that the strawman is highly misleading as it is predicated on visual  similarities not actual equivalent data content.  So let's start there.  What's being taught here? and is this an implementation idiosyncrasy, a pitfall, what?
:If the goal was to expose the object model differences between YAML and XML then I might be temped to say something like this instead (please forgive any too-sweeping generalizations and colloquial syntax) .  
YAML and XML have different object models.  YAML's object model maps more closely to the entities found in higher level languages such as Hash's, arrays, and pointers.  To perceive this distinction consider the following. When representing XML in a higher level language one needs only two rules:
 
::1.   An XML object has exactly three attributes:
:::name: <string>
:::attributes: <hash of key values, where the values are scalars.>
:::content_array:  <array>
::2. An XML object may only be contained by the content array of another XML object.  The content array elements contains either a string or another XML object.
There! that's all one needs to represent any XML in a higher level language.
:Now there's multiple ways one could implement YAML objects.  But the most primitive and most analogous is , I beleive the following.
::1. A YAML object (called a node) has exactly two attributes
:::     type:  <one of a set of defined keywords for types>
:::     content:  < an object of the type defined above>
::2.  A YAML object can only be placed in the content of the array/hash value fields of another YAML object.
:Types here would most commonly be array,hash, pointers, or scalars (strings, ints, etc), though they could be any definable YAML type like ordered Hash, Binary, timestamp, set, or user defined class.
As can be seen a YAML object unbundles the fields of a higher order XML object such that it would take three YAML objects to represent the three fields of an XML object. <B>Moreover there is no notion of a general hash hierarchy in XML (the attribute hash storage may only contain scalers not other objects), thus a hash notion can only be exist by user defined semantics imposed on the XML content and has no direct syntactic representation.</b>"
:That's one thought. it never raises the red herring of how one might visually confuse  an order preserving array of XML objects (and as described, all XML objects are held in arrays)  with an non-order preserving Hash of YAML objects.  But that's just a visual issue, not a real one to anyone who understands that the containers are layed out differently: XML content is logically speaking always an array, and YAML is a flatter representation from which one can build the XML arrays.  It's not a workaround. The two look-alike syntaxes are constructively different. 
: If put this way we can dispense with the side topic of perl or python native hashes, which definitely don't belong here.  The <B>bold</b> section seems to capture the issue you were describing.
:So if possible tell me what the issue you are trying to teach is.  is it an idiosyncracy or pitfall?  is it a structural comparison like I laid out?  Then we can argue better.  My own feeling is that the structural comparison I just outlined would not belong either even if it were better written. It's just not a WIKI kind of thing as the decomposition while instructive is also arbitrary. Cems2 18:08, 31 October 2007 (UTC)
thread_title: reply

message: I think that the real underlying issue here may have a simple resolution. Basically, XML may have no syntax for a general hash construct.  Hashes arise from semantic idioms imposed by the user.  YAML has a direct syntax.  
So perhaps we do the following:  in XML comparison section we say something like, " YAML has direct syntax for HASHes whose keys can contain hierarchical content.  XML has no direct syntax but a user can of course store a HASH in XML by imposing an external semantic structure (there are many possible idioms).  "  Additionally we add a paragraph to the pitfalls section pointing out that XML users who are accutomed to hash idioms that are order preserving may find YAMLs direct (and higher level language inspired) hash representation has the pit fall that it is not order preserving. When Order preservation is required one can either use YAML's defined order preserving hash type, or, in analogy to XML, an ordered array of key-value pairs."
Does that capture the two points you want to make here? Cems2 19:28, 31 October 2007 (UTC)
thread_title: proposed resolution

message: I've begun to make already-planned enhancements to the section that was deleted, rendering most of the objections offered here irrelevant. Of course, if there are any future objections or concerns, they are more than welcome, but please: 1) substantiate all material assertions with direct references to cited sources so no one has to "guess" about anything; and 2) be prepared for simple "yes or no" questions if it becomes necessary to clarify any ambiguities. 
Please do not post deletions or objections unless you can honor these two very simple requests. Thanks. dr.ef.tymac 16:17, 4 November 2007 (UTC)
thread_title:  Moving forward 

message: Is there an editor/frontend for YAML?--129.69.36.89 (talk) 12:22, 21 May 2008 (UTC)
replies: text: you barely need one for hand editing, and of course most languages have yaml emitters. However if you really want one, then I'm told that Emacs has a YAML mode and that so does the GUI editor TextMate.  Have not tried either.  —Preceding unsigned comment added by 68.35.151.18 (talk) 22:04, 8 July 2008 (UTC)

text: see yaml.org  for links.  VIM for example has one.  But you really do not need one. That's the whole point of YAML.
Emacs? According to StackOverflow's 2019 Developer Survey Results, Visual Studio Code (a multi-platform FOSS tool) is 10 times more widely used as Emacs, twice as widely used as VIM, and 50 times more widely used than TextMate. I'm really confused why it's not listed first. It supports YAML folding, auto-indent, syntax coloring, supports TextMate .tmLanguage files for specific YAML applications, all without any extensions or plugins. It does a lot more with YAML-supporting extensions added, like helping to edit docker-compose.yml files, and so on. Alan (talk) 23:37, 21 February 2020 (UTC)
thread_title:  YAML application 

message: King of hearts I see you undid my revisions (cems2) and called them unconstructive.  Not sure why or what perturbs you.  There were two kinds of revisions.  First I made a change to the section ordering. Second I  revised several elements of the text, for the most part cutting not adding.  In the latter case essentially all of the text changed was my text I had originally written, so I was essentially editing myself to simplify the content.    So I'm not quite sure what about the changes you did not like.  I have reverted it back to the edited form.  —Preceding unsigned comment added by 128.165.108.189 (talk) 22:31, 27 May 2008 (UTC)
thread_title:  King of Hearts 

message: Could someone who understands how relational trees work in YAML please write a more understandable example? I'm not sure it's helpful to provide an example using a process most people don't know about. For an example like this, you should only have to work to understand the code, you shouldn't have to figure out what is going on in the example first before you can even understand the markup. I would suggest replacing it with a commonly understood process instead, maybe a recipe?  —Preceding unsigned comment added by 76.99.107.22 (talk) 15:27, 18 June 2009 (UTC)
thread_title:  Relational Trees 

message: In 2006, Brian Ingerson legally changed is name (in the state of Washington) to Ingy döt Net.  He prefers to be addressed using his new name.  This name change edit (on yaml.org/about and here) was done by Clark C. Evans on 10/25/2010.
===AsciiDoc  = serialization format??===
The article as it is right now mentions as alternative lightweigth markuplangauges among others asciidoc. Which is certainly not a serialization format as Yaml is (No types no structures etc... it's intended for text markup). Therefore i will remove that from the list of of  similar formats when there are no other opinions.
188.98.36.2 (talk) 21:30, 28 June 2011 (UTC)
thread_title:  Ingy döt Net 

message: The article as it is right now mentions as alternative lightweigth markuplangauges among others asciidoc. Which is certainly not a serialization format as Yaml is (No types no structures etc... it's intended for text markup). Therefore i will remove that from the list of of  similar formats when there are no other opinions.
188.98.36.2 (talk) 21:30, 28 June 2011 (UTC)
thread_title: AsciiDoc  = serialization format??

message: The LibYAML home page spells the word "LibYAML" with a capital "L".  However, on 15:03, 9 September 2011, Spitzak changed all occurrences of the term to "libYAML" with the comment that
Actually lower-case "lib" prefix is Unix standard. Other OS's do not use any "lib" prefix so they do not change this
I argue that "LibYAML" makes more sense in the context of the article, as it's referring to a project name as opposed to, say, a filename (e.g., libyaml.a).  However, I don't want to get into an edit-reverting war so I ask, What do other people think is most appropriate for the YAML article?  "libYAML" or "LibYAML"?
--Scott Pakin (talk) 04:23, 10 September 2011 (UTC)
replies: text: Wikipedia generally follows published sources; the name that the project calls itself is the most authoritative source.  In common usage, I see LibYAML and libyaml but not libYAML. -- Beland (talk) 18:17, 7 November 2016 (UTC)
replies: text: (Though it seems mention of LibYAML has since been removed from the article. -- Beland (talk) 18:19, 7 November 2016 (UTC)
thread_title:  Capitalization: libYAML vs. LibYAML 

message: The "Repeated nodes" section shows an example YAML document in which a node is repeated from an anchor but with one key redefined ("spotSize", in the example).
I cannot find a YAML parser or validator that accepts this syntax and it seems to be explicitly disallowed in the spec: http://www.yaml.org/spec/1.2/spec.html#id2786196
I'd be glad if someone could either clarify the example or correct any misunderstanding on my part.  — Preceding unsigned comment added by Blair1618 (talk • contribs) 17:03, 4 September 2015 (UTC)
thread_title:  Repeated nodes with modifications 

message: It says: "A major part of its accessibility comes from eschewing the use of enclosures such as quotation marks, brackets, braces, and open/close-tags, which can be hard for the human eye to balance in nested hierarchies".
Says who? That's the author's opinion, and of course the opinion of the designers of yaml, and is also the opinion of the designers of Python, but for every person who believes that, I can find a person who hates the lack of braces. For example, every C, C++, Pascal, Java, and other programmer using a C-style language. This sentence reads like a sales brochure. Just stick to the facts. If you want to risk getting tagged for "weasel words", you could reword this to say something like "which can be hard for some humans to balance in nested hierarchies", but it would be better to just say yaml, like python, uses whitespace indentation. But you say that later anyway. So why not drop this whole sentence?  — Preceding unsigned comment added by 199.16.140.27 (talk) 23:27, 9 September 2015 (UTC)
thread_title:  Section On Features Does Not Have Neutral Point Of View 

message: As this is not a tutorial and we need only present the information about YAML to the user as well as maybe some examples, would it be alright if I could remove the content under the Syntax sub-heading and add appropriate sub-headings for the points that are mentioned in the current Syntax heading (like charset). Also, would it be fine if I could take information about YAML from the specification and use the same to cite it as a source? This is to add a bit more information to the wiki if need be.--Dbzvishal (talk) 23:01, 5 September 2016 (UTC)
thread_title:  Is the syntax sub-heading necessary? 

message: I've just undone a series of edits which, while well-intentioned, pushed the article back in terms of being a general description of the subject from a non-implementational viewpoint. This is never going to be the ideal place for a tutorial on the subject. I'll see if I can cherry-pick appropriate edits from this series. Chris Cunningham (user:thumperward) (talk) 22:04, 11 September 2016 (UTC)
thread_title:  Syntax section revert 

message: "Notice that strings do not require enclosure in quotations."
That is about the 4th time that has been mentioned: can't we eliminate 1 or 2 of these? GeneCallahan (talk) 05:20, 13 November 2018 (UTC)
replies: text: Of course we can, please go ahead. Thank you, -- Nsda (talk) 14:52, 13 November 2018 (UTC)
thread_title:  Too much repetition 

message: Maybe I'm just tired, but not sure if the following snippet from this article should be "declaration" instead of "decoration", at the top of the section titled:
"Software (emitters and parsers):"
"For fixed data structures, YAML files can simply be generated using print commands that write both the data and the YAML specific decoration"
It could be correct as is, i.e decorations could be referring to categorically to the particular punctuation characters and other syntax formatting.  But, thought it wouldn't hurt to flag, just in case it isn't...
Sorry, I'm just passing through and busy researching other topics.  Hopefully, someone else who is well versed can correct or clarify with little trouble.  Thanks in advance to whomever that may be. ;-)  Tree4rest (talk) 22:39, 24 August 2019 (UTC)
thread_title:  Does YAML have "decorations", or should that be "declarations"? 

message: I am going to remove the last bullet point of the "Criticism" section for the following reasons:
* The linked citation does not support the claim. All of the presented YAML examples are readable by humans.
* Since when did we start citing StackOverflow answers? We might as well start citing other Wikipedia articles.
Ender and Peter 02:47, 9 April 2020 (UTC)
thread_title:  Removing last bullet point of "Criticism" section 

message: In the "Criticisms" section, four of the five bullet points cite Martin Tournoij's blog as their source. 
I suggest deleting these two criticisms
* Configuration files can execute commands or load contents without the users realizing it.
* Type autodetection is a source of errors.  E.g. unquoted Yes and NO are converted to booleans, software version numbers might be converted to floats.
On the grounds that these are criticisms of a particular YAML parser, rather than criticisms of YAML. Other parsers are available, which do not execute commands or load contents without the users realizing it, and do not implement type autodetection.  
Criticising the YAML language because the Python parser does some risky or unhelpful things with YAML is like criticising CSS because IE6 makes a mess of CSS.
Jinlye (talk) 13:11, 7 May 2020 (UTC)
thread_title:  Two of the "Criticism" section bullet points are criticism of a specific implementation of a particular YAML parser rather than criticism of the language; I suggest deleting them 

message: The first line of the article calls YAML a "data-serialization language". Is YAML really a language? I would say it's a file format just like JSON is, and the JSON article lists JSON as a file format too. I strongly believe we should change the first line to "YAML ... is a human-readable file format for data serialization". Anirudhgiri (talk) 02:37, 23 April 2021 (UTC)
thread_title:  Is YAML really a "language"?