4 ms·

> Simple structure, a little too verbose The "too verbose" bit is overly broad cargo-cultism. XML has valid, efficient applications. A prominent one: it's a m

> Simple structure, a little too verbose The "too verbose" bit is overly broad cargo-cultism. XML has valid, efficient applications. A prominent one: it's a more concise serialization format than JSON (the supposed alternative) for describing self-similar typed hierarchies, e.g. scene graphs or other UI trees. (see HTML, XAML, VRML, kind-of JSX.) consider: <div> <span>Hello world</span> <div> vs: { nodeType: "div", children: [ { nodeType: "span", children: [ { nodeType: "text", value: "Hello world" } ] } ] } It's hard to take the rest of the article seriously when it starts with that unnecessary (and imprecise) jab at the technology it purports to be educating about.

skybrian 9y ago
There are more concise ways to use JSON. For example: ["div", ["span", "Hello world"]] You can also add attributes: ["div", {"id": 123}, ["span", "Hello world"]] Parsing is a bit trickier and the format is less obviously extensible, but in general, JSON arrays are more concise than JSON objects since you can leave out the field names.
- beagle3 9y ago
  Just wanted to add that this use might not be common in JSON but is extremely common in S-Expressions, which predate XML by 40 years or so, and are probably a better XML replacement than JSON (if you only regard technical details and ignore popularity and library/language support)
  - skybrian 9y ago
    When people say this I wonder how much lisp readers are really standardized. (Consider reader macros.) It's not clear I could find an s-expression parser in two different arbitrary languages and be sure they interoperate, even if they're both lisp variants.
    - ajanuary 9y ago
      I guess that's the problem edn [0] was trying to solve, but it doesn't have wide enough adoption. [0] https://github.com/edn-format/edn https://github.com/edn-format/edn
    - beagle3 9y ago
      Common Lisp is reasonably standardized -- that's the whole point of Common Lisp, though it is hardly dominant. Among general Lisps and Schemes, readers are not standardized enough to say "kill XML, we'll just have S-Expr" (though I'm not sure what percentage of XML parsers out there follow the XML spec to the letter either).
    - shakna 9y ago
      > It's not clear I could find an s-expression parser in two different arbitrary languages and be sure they interoperate, even if they're both lisp variants. Scheme has a decent, albeit small, standard [0]. SXML [1] is also standardized, as part of that process, which makes writing it nice and predictable. So, for the most part, SXML should work the same between implementations, but, if it doesn't, all you need to construct an SXML object is: quote or quasiquote and unquote. SXML feels far more like a template language than a serialization format. --- But the wider question: > It's not clear I could find an s-expression parser in two different arbitrary languages and be sure they interoperate For the most part, they should be. But! S-Expressions are a terribly inefficient structure in memory, or rather, can be. How you optimise that can have some impact on what the reader accepts or rejects, or how it compiles into memory. Singly and doubly linked lists, vectors, arrays. S-Expressions can be all under the hood, or a mix. Some parsers reject variadic s-expressions, others accept them happily, but others have a limited recursion depth, so technically valid s-expressions get rejected. However, for the most part they're equal. --- [0] http://www.schemers.org/Documents/Standards/ http://www.schemers.org/Documents/Standards/ [1] http://okmij.org/ftp/Scheme/SXML.html http://okmij.org/ftp/Scheme/SXML.html
- jraph 9y ago
  A bit off topic but I wrote a very small JS library that uses this exact format 6-7 years ago. It transforms such an object to a DOM tree. This is nice to see somebody mention this format, this kind of validates it. So, thank you! It also accepts things like ["div#123.class-name-1 class-name-2", ["span", "Hello world"]]. You can keep a reference of a node in a Javascript object if needed: let refs = {}; let div = jso2dom( ["div", ["span", {"#":"sp"}, "Hello world"] ], refs ); console.log(refs.sp); // <span> Hello World </span> I've found it very convenient so far and still use it today. This is simple, prodigiously stupid and works in vanilla JS, so this works for me for the time being. Parsing may be complex but in my case, this is done by the Javascript engine, so I'm not affected by this complexity.

skybrian 9y ago

There are more concise ways to use JSON. For example: ["div", ["span", "Hello world"]] You can also add attributes: ["div", {"id": 123}, ["span", "Hello world"]] Parsing is a bit trickier and the format is less obviously extensible, but in general, JSON arrays are more concise than JSON objects since you can leave out the field names.

beagle3 9y ago
Just wanted to add that this use might not be common in JSON but is extremely common in S-Expressions, which predate XML by 40 years or so, and are probably a better XML replacement than JSON (if you only regard technical details and ignore popularity and library/language support)
- skybrian 9y ago
  When people say this I wonder how much lisp readers are really standardized. (Consider reader macros.) It's not clear I could find an s-expression parser in two different arbitrary languages and be sure they interoperate, even if they're both lisp variants.
  - ajanuary 9y ago
    I guess that's the problem edn [0] was trying to solve, but it doesn't have wide enough adoption. [0] https://github.com/edn-format/edn https://github.com/edn-format/edn
  - beagle3 9y ago
    Common Lisp is reasonably standardized -- that's the whole point of Common Lisp, though it is hardly dominant. Among general Lisps and Schemes, readers are not standardized enough to say "kill XML, we'll just have S-Expr" (though I'm not sure what percentage of XML parsers out there follow the XML spec to the letter either).
  - shakna 9y ago
    > It's not clear I could find an s-expression parser in two different arbitrary languages and be sure they interoperate, even if they're both lisp variants. Scheme has a decent, albeit small, standard [0]. SXML [1] is also standardized, as part of that process, which makes writing it nice and predictable. So, for the most part, SXML should work the same between implementations, but, if it doesn't, all you need to construct an SXML object is: quote or quasiquote and unquote. SXML feels far more like a template language than a serialization format. --- But the wider question: > It's not clear I could find an s-expression parser in two different arbitrary languages and be sure they interoperate For the most part, they should be. But! S-Expressions are a terribly inefficient structure in memory, or rather, can be. How you optimise that can have some impact on what the reader accepts or rejects, or how it compiles into memory. Singly and doubly linked lists, vectors, arrays. S-Expressions can be all under the hood, or a mix. Some parsers reject variadic s-expressions, others accept them happily, but others have a limited recursion depth, so technically valid s-expressions get rejected. However, for the most part they're equal. --- [0] http://www.schemers.org/Documents/Standards/ http://www.schemers.org/Documents/Standards/ [1] http://okmij.org/ftp/Scheme/SXML.html http://okmij.org/ftp/Scheme/SXML.html
jraph 9y ago
A bit off topic but I wrote a very small JS library that uses this exact format 6-7 years ago. It transforms such an object to a DOM tree. This is nice to see somebody mention this format, this kind of validates it. So, thank you! It also accepts things like ["div#123.class-name-1 class-name-2", ["span", "Hello world"]]. You can keep a reference of a node in a Javascript object if needed: let refs = {}; let div = jso2dom( ["div", ["span", {"#":"sp"}, "Hello world"] ], refs ); console.log(refs.sp); // <span> Hello World </span> I've found it very convenient so far and still use it today. This is simple, prodigiously stupid and works in vanilla JS, so this works for me for the time being. Parsing may be complex but in my case, this is done by the Javascript engine, so I'm not affected by this complexity.