The description of YAML in the README is inaccurate

[ingydotnet]

The YAML project started in the Spring of 2001. We were unaware of JSON until at least 2005, possibly 2006. By that time, there were YAML frameworks in many languages and the Ruby language was already shipping with YAML included.

The first draft spec of YAML came out in 2001. The early origins of YAML were a reaction to XML, not JSON. The YAML 1.0 and 1.1 specs make no mention of JSON. Sometime after 1.1 spec came out we realized that YAML was very nearly a superset of JSON (a complete coincidence). The YAML 1.2 spec was mostly about making 3 or 4 very minor adjustments so that YAML would in fact be a complete superset of JSON.

Feel free to ask clarifying questions if you want, but I'd ask you change your documentation to not imply that YAML's design decisions had anything to do with JSON's (or vice versa).

Cheers!

[KenKundert]

I apologize. I assumed without checking. That was a mistake. I have changed the documentation to avoid any implication that YAML was in any way a reaction to JSON. I will check in the change in the next day or so. Please feel free to request any other changes to that section. My goal is to simply distinguish NestedText from YAML. I do not wish to create any hard feelings.

[ingydotnet]

Thanks. No hard feelings taken.

I will mention something else. The section about the "Norway problem" is not quite accurate. Some YAML loaders do in fact load no as false. These are usually YAML 1.1 loaders. YAML 1.2's default schema is the same as JSON's (only true, false, 'null and numbers are non-strings).

Any YAML loader is free to use any schema it wants. That is, no loader is required to to load no as false. Good loaders should support multiple schemas and custom schemas. The Norway problem isn't technically a YAML problem but a schema problem.

imho, YAML's biggest failing to date is not making things like this clear enough to the community.

Note: PyYAML has a BaseLoader schema that loads all scalar values as strings.

YAML is primarily a cross-programming-language data serialization language. It only happened to gain popularity as a configuration format; that was never the intent.

It's worth mentioning that YAML is still under active development and the next version of the language is expected to come out in the next 6-12 months. We are well aware of the problems that the language has and hopefully will make many of them go away.

I wish you luck in your endeavors. Creating languages is fun. I've created several and continue to do so. :slightly_smiling_face:

[KenKundert]

Thanks, both for the good wishes and the information about YAML. I was unaware of the role of the loader in the implementation of implicit typing. Had I known I might not have developed NestedText at all.

Sounds like you are involved in the YAML language update. May I suggest that you take a look at NestedText's multiline string. I was really stuck trying to come up with a clean way to accept multiline strings with a leading indents. I tried many things, and this approach was the cleanest. I think it is nicer than the approach provided by YAML; no need for the user to count spaces.

[ingydotnet]

If I follow you correctly, you are referring to the YAML "literal" scalar form:

letter B: |
  ######  
  #     # 
  #     # 
  ######  
  #     # 
  #     # 
  ######  

where the indentation is detected by the first non-blank line. That causes problems when the first indentation is not what you want. YAML has the ugly solution of using a number:

letter A: |2
     #    
    # #   
   #   #  
  #     # 
  ####### 
  #     # 
  #     # 

Your solution appears to be:

letter A:
  >    #    
  >   # #   
  >  #   #  
  > #     # 
  > ####### 
  > #     # 
  > #     # 

That is certainly one way to do it. It doesn't look too bad. It does require the author to do extra work though. The YAML idea was that any plain text could be encoded simply by indenting it.

This is one of the topics YAML has also been discussing for improvement.

One solution is:

letter A:
  |   #    
     # #   
    #   #  
   #     # 
   ####### 
   #     # 
   #     # 

You only need to indicate the indentation once, not on every line. We had never considered a solution requiring syntax on every line.

I can see both the appeal and the misgivings of your solution. On the good side it is obvious and unambiguous. On the bad side it is extra clutter and requires more attention/work when editing.

[KenKundert]

Yes, you understand perfectly.

[perlpunk]

Another advantage of the NestedText solution is trailing empty lines. In YAML, when you have a scalar with trailing empty lines:

block: |+
  a
  b

something: else

one has to be careful to not add or remove an empty line there. OTOH that's a rare use case.

[KenKundert]

It is on my to-do list to configure Vim to automatically add the '> ' on each line once the first is seen.

There are a few things that I like about the NestedText approach.

1. It makes it easy to visually distinguish the indent from the text.
2. It makes it easy to add and see leading and trailing blank lines.
3. It feels familiar as many email tools use leading '> ' on each line to delimit a block of text when forwarding.

It also makes it possible to add comments in the middle of the text block:

letter A:
# the ascender 
    >    #    
    >   # #   
    >  #   #  

# the body
    > #     # 
    > ####### 
    > #     # 
    > #     # 

At first it seems like a weird feature, but it can come in handy. For example, if the text block is used to hold a paragraph or two of text that will be inserted into a form letter, one can use the comments for editing instructions or to point out the incomplete sections and give reminders as to what remains to be said.