[zeveb]

If we're going to talk about replacing XML with better data formats, why not switch to S-expressions?

    (feed
     (version https://jsonfeed.org/version/1)
     (title "My Example Feed")
     (home-page-url https://example.org)
     (feed-url https://example.org/feed.json)
     (items
      (item (id 2)
            (content-text "This is a second item.")
            (url https://example.org/second-item))
      (item (id 1)
            (content-html "<p>Hello, world!</p>")
            (url https://example.org/initial-post))))

This looks much nicer IMHO than their first example:

    {
        "version": "https://jsonfeed.org/version/1",
        "title": "My Example Feed",
        "home_page_url": "https://example.org/",
        "feed_url": "https://example.org/feed.json",
        "items": [
            {
                "id": "2",
                "content_text": "This is a second item.",
                "url": "https://example.org/second-item"
            },
            {
                "id": "1",
                "content_html": "<p>Hello, world!</p>",
                "url": "https://example.org/initial-post"
            }
        ]
    }

[krapp]

It looks nicer if you happen to like s-expressions. But to me, it's just replacing one flavor of clutter for another. The best reason not to prefer s-expressions to JSON, though, would be simply that one is already natively supported in browsers and the other would need a parser written in a language that already parses JSON.

[JoelSanchez]

There's EDN, which is to Clojure what JSON is to JS: a format close to the language's way of representing data.

https://github.com/edn-format/edn

Example:

https://github.com/milikicn/activity-stream-example/blob/4db...

Not S-expression-based, though.

[draegtun]

JSON was influenced by Rebol, which i feel would provide an even nicer example:

    version: https://jsonfeed.org/version/1
    title: "My Example Feed"
    home-page-url: https://example.org
    feed-url: https://example.org/feed.json
    items: [
        [
            id: 2
            content-text: "This is a second item."
            url: https://example.org/second-item
        ]
        [
            id: 1
            content-html: "<p>Hello, world!</p>"
            url: https://example.org/initial-post
        ]
    ]

[hajile]

Those two aren't comparable because you cannot distinguish between key:val pairs and lists. You need dotted lists.

[zeveb]

Nope, one would normally write the code which parses such S-expressions such that the first atom in each list indicates the function to use to parse the rest of the list. So there'd be a FEED-FEED function which knows that a feed may have version, homepage URL &c., and there'd be a FEED-ITEMS function which expects the rest of its list to be items, a FEED-ITEMS-ITEM function which knows about the permissible components of an item &c.

If you really want to do a hash table, you could represent it as an alist:

    (things
      (key1 val1)
      (key2 val2))

This all works because — whether using JSON, S-expressions or XML — ultimately you need something which can make sense of the parsed data structure. Even using JSON, nothing prevents a client submitting a feed with, say, a homepage URL of {"this": "was a mistake"}; just parsing it as JSON is insufficient to determine if it's valid. Likewise, an S-expression parser can render the example, but it still needs to be validated. One nice advantage of the S-expression example is that there's an obvious place to put all the validation, and an obvious way to turn the parsed S-expression into a valid object.

[hajile]

In the absolute abstract, you are correct. In the absolute abstract, you could replace parens with significant whitespace and have zero visible syntax.

In practice, lisp adopted dotted lists 60 years ago and basically every lisp since has used it as one way to represent an associated list. Minimal syntax is better than zero syntax or loads of syntax.

[Johnny_Brahms]

There is of course sxml, which is more or less well-defined. But that would probably suffer from the same problems as xml, since it is just xml written as s-expressions.

There is one pretty damn solid SSAX parser by Kiselyov that has been ported to just about every scheme out there. It is interesting since it doesn't do the whole callback thing of most ssax parsers, but is implemented as a tree fold over the xml structure.

[foxhill]

beauty is in the eye of the beholder - i personally prefer the JSON.