if and only if /**/ comments are supported ;)

You’d need to support C-style comments when in “JSON mode”—and more importantly not accept malformed JSON either.

Given both of those, please do.

If all JSON is YAML , ipso facto.

All JSON notation is valid YAML : Strings, numbers, objects, arrays, true, false, null.

Why should I need to support the comments? The JSON site claims, “This feature can also be found in Python.” But Python doesn’t support C-style comments.

I should also be allowed to accept malformed JSON . Look at this recommendation from json.org, concerning using JavaScript to load JSON :

To convert a JSON string into an object, use the eval() function. eval() invokes the JavaScript compiler. Since JSON is a proper subset of JavaScript, the compiler will correctly parse the string and produce an object structure.

eval(“window.newJSONObject = ” + aJSONString);

This means that the JavaScript parser is allowed to accept any valid JavaScript as valid JSON . So, really. Why would I be held to more stringent guidelines?

Oh. Wow.

Go to it man.

Why, you realize with all the hubbub about JavaScript in the Rails community right now, if Syck and your Ruby frontend start offering a JSON output and input mode, Rails and JavaScript could share data structres!

That’s just wow. The implications for that are staggering. Ruby functions could call js functions when the page is rendered, serializing the data into JSON , which JS can respond to by serializing back to JSON in cookies which is also YAML .

When things like this happen, that’s when we know what sorta stuff needs to be the real standard.

Thank you! I’m one of those sky punchers. It’s one of the main reasons I chose Ruby over Python way-back-when.

I’m a sky puncher as well. I just can’t get past white-space having meaning.

Even with the inline collections I still don’t buy into YAML . Take a look at that last line in your example:

{"value": "Close", "onclick": "CloseDoc()"}]}}}

Exactly how many “}” and “]” characters is that and what order do they go in? I sure hope everybody has a decent text editor that matches opening symbols. Also hope your data structures don’t span more than one page. Occasionally I run into someone elses code that used deeply nested block of code that looks like:

if( foo > bar )
{
  while (i < 10)
  {
  if( cat > dog )
     {
       until( z < q )
       {
         for( n=0; n<5; n++ )
         {
            if( cow > grape )
            {
              while( z < q )
              {
                ...do something...
              }
              ...bunch of code...
            }
            ...more code...
          }
          ...several pages of code...
        }
        ...you think I'm joking...
      }
      ...I've really seen stuff...
    }
    ....about this bad...
  }
  ....seriously!.....
}

When I end up maintaining code that looks like this I almost always have to rewrite the logic to be reasonable otherwise I spend forever debugging stupid missing or extra “}” characters.

If I don’t want that in my code why would I want it in my data?

I’m not a XML fanatic but at least in xml the closing tags have obviously matching opening tags and ensuring you don’t have two few or two many closing tags is also obvious.

Just my 2 cents.

Eric, you cannot seriously be suggesting that problems like the above are unheard of in XML . You’ve obviously never written a JSP if you are. :-)

Oh, I haven’t tried loading XML into YAML !! Be right back!! (Fingers XROSSD !!)

I used JSON with Rails before Ajax came to it, and everything was good and easy. It was OrbJson implementation by James Britt. I’m even using it in one project, cause it’s better for it’s purposes than Ajax. I’ll be happy if it will find it’s way to Rails, but ….

Real men use s-expressions! :-)

[ot] Believe it or not, the Evolution email client includes an s-expression interpreter to handle queries (see evolution-data-server-1.0.2/libedataserver/e-sexp.c).

So you can give it a query like (contains ‘full_name’ ‘Guidry’) and it’ll give you back Ron Guidry, if he happens to be in your address book.

Eric, it’s funny you say you don’t like relevant whitespace, and then goes on to say how matching closing braces suck. You know, with meaningful indentation you don’t have to close anything.

In fact regarding xml/xhtml I even wrote my own yaml-ish withspace-sentitive no-closing-things notation language (which itself is not too different from pxsl, just simpler)

And then again, back in rails 0.6 or so it took me little time to add to_js methods to all base classes and be done with json. I don’t get what the fuzz is all about. (Except that maybe I could just have used yaml to generate json?)

(I also found a js yaml lib out there, but don’t know how good it is)

While I don’t like the “macho” attitude implied in Chris2’s statement (I’m certainly not a “real man”, nor do I think s-expressions is difficult or challenging at all – it’s way easier than XML or even JSON ), I’ve also been using s-expressions for a while and I’m not very fond of YAML at all. It uses a crazy mesh of { and [ characters instead of just parentheses, and (while I don’t have a knee-jerk reaction against whitespace sensitivity) I’ve been saved by the non-whitespace-sensitivity several times in my recent project since the lines have been edited sloppily (by me – yeah, I’m such a slob).

For me, the idea “easier for the lexer/reader/parser to parse = easier for the brain to parse” holds true.

Also, with s-expressions I can use the same notation for code and data, as long as I’m programming in a s-exp language (which is my preference) – JSON also has this property, if you’re programming in javascript.

YAML is reinventing what scheme/lisp programmers have had for years and years. While it’s a good thing that more people are discovering this, I think it’s a shame why you aren’t really improving on the ol’ s-expressions, just making a (unnecessarily) complex version that’s harder to generate and harder to parse.

(My current project is (currently) over six hundred lines of hand-written s-expressions, and that’s just the textual data. Not counting code (which is less – 328 lines of scheme, to generate (currently) over six thousand lines of XML from those six hundred lines of s-expressions.))

Same with Ruby. I don’t see what makes it so “easy” and Scheme so “difficult”. Macros can be tricky, but Ruby’s MOP is not kindergarten stuff either. (The Ruby interpreter is a remarkable piece of software, however, as is much software from the Ruby community.)

While I don’t like the “macho” attitude implied in Chris2’s statement

He was joking (lightly). There’s a meme in America from a book called “Real Men Don’t Eat Quiche” written (I think) in the 1970’s.

Did anyone notice that Sunnan’s post is mostly in parens??

So how do you tell YAML.dump() to output structures in this form? If I want to give people structured data to edit, I must create it in the first place, ideally automatically. Could you add some more recipies to the YAML cookbook for this flavour of data, please? Thank you.

So in response to the original question, Austin had the correct answer. As long as you accept all correct JSON texts, you have a JSON parser. If you want it to also handle non-JSON texts, that’s your business.

UnAmerican: I’ve seen the book; but the meme is so entrenched these days that I don’t always think of it as a joke.

Why: Thanks for noticing. (I like subtle little jokes like that. (I’ve been known to hand in anagram-filled essays that’s also one long acrostic. (The teacher didn’t notice anything.)))

I might’ve developed parenthesis synaesthesia.

For the curious, here’s one possible s-expression version of the JSON example (assuming we’re to use strings rather than a mix of symbols and strings). I can see some pros and cons here; I guess tastes can vary.

("glossary" 
 (("title" "example glossary")
  ("GlossDiv" 
   (("title" "S")
    ("GlossList" 
     (("ID" "SGML")
      ("SortAs" "SGML")
      ("GlossTerm" 
       "Standard Generalized Markup Language")
      ("Acronym" "SGML")
      ("Abbrev" "ISO 88791986")
      ("GlossDef" 
       "A meta-markup language used to create markup languages such as DocBook.")
      ("GlossSeeAlso" ("GML" "XML" "markup"))))))))

Seems the s-expression contains less information. In YAML /JSON, I’m told whether a list is an integer-indexed array or part of a hash; and I don’t see that info anywhere in the s-expressions.

I’ve been known to hand in anagram-filled essays that’s also one long acrostic.

Good to know I’m not the only one.

My favorite was one that spelled out “Don’t smoke pot”, complete with the apostrophe. It was a work of singular genius.

Hmm. So JSON = YAML + Comments? All I want is to be able to talk to more langauges. People keep waving JSON parsers in my face.