5 ms·

Can you explain what you mean by JSON being an edge labeled tree in more detail? I don't understand and would really like to.

• zachrose 10y ago
  Taking a stab at this... Let's say we have a dog who has four paws. In XML: <dog> <paw health="ok"> <paw health="ok"> <paw health="ok"> <paw health="ok"> </dog> In JSON: { "paws": [ { "health": "ok" }, { "health": "ok" }, { "health": "ok" }, { "health": "ok" }, ] } I think what the GP is getting at is that JSON is always describing the relationships between a thing and another thing, rarely the things themselves. In the JSON version, for example, it can be assumed that an object in the "paws" array is a paw. This example is sort of a straw man. The JSON version could be wrapped with { "dog": {...} } and the individual XML paws could be wrapped in a <paws> element. But in any case, JSON doesn't need you to give an explicitly label the type of each paw, just what they belong to and what's known about them.
  • qwertyuiop924 10y ago
    I'll step up to the plate to give a more technical answer. JSON is an edge labelled tree, XML is node labelled tree. Let's see what that means, but first, let's talk about what nodes, edges, trees, and labels. You may already know, but I don't want to make no assumptions. First, a tree: A tree is a datastructure with nodes, which reference other nodes, and each node is only referred to by one other node. Now, XML is obviously a tree, with each tag being a node: <dog> /| |\ / | | \ / | | \ <paw> | | <paw> / \ / \ / \ <paw> <paw> However JSON is also a tree: however, instead of tags, we have arrays and objects: Well, actually, I'm not going to draw that. I'm typing on a phone, and it was hard enough making that last one. So, you know, just imagine it. And if you imagine hard enough, you just might notice that this graph is edge labelled, rather than node labelled. A node, as you may recall, is just a thing on the tree, like a tag, or an object or an array. Queue the music! TO THE TUNE OF "NOUNS" FROM SCHOOLHOUSE ROCK: Oh any list through which you can go (like a array, a linked list, or an arraylist), And any structure that you can show (like a hashmap, or a struct), If they have pointers you can follow (from an object in a tree), You know they're nodes, you know they're nodes Aaaanyway, an edge is the link between two nodes, and labels are just names. JSON labels edges: "I want the first value in the array you got at key "foo" from the root object." XML labels nodes: "I want the paragraph tag with the id of 'foo' inside the body tag inside the html tag." You see, with the JSON, the nodes themselves didn't have labels, just the links between them: With XML, it was the opposite: There was no name for the links, instead there were names for the objects. GGP reminds us that most programming languages do it the same way JSON does (when was the last time referred to the Foo object in the Bar object in the head Baz object when coding?), and so JSON maps better to the kind of datastructures we use most of the time.
  • MichaelMoser123 10y ago
    I don't quite see why you can't do the same with xml; maybe it needs some more typing, but it is expressing the same thing. <paws> <health status="ok"/> <health status="ok"/> <health status="ok"/> <health status="ok"/> </paws> i thought that the main advantage of json was that it can be used as is (code as data) in javascript, but the problem here of course is that without a parser/validator one can inject tons of malicious code. If you are not on javascript then you can't do without a parser / in memory tree structure - and that's the same DOM model once again. Json needs a bit less typing, now is that really such a significant difference? i think that adoption in matters of markup is more like a fashion - once people got the hang of it then it seems natural and goes without explanation. i would say that there is one major difference - binary or text; as long as its text then it doesn't quite matter how you structure your markup; if you need your data to be of small size then you will have to compress it; however the parsing of a text tree will usually take more time than the serialization of a binary structure (by several factors); Therefore you will use text markup where application speed is not very important, or where speed of development is more important than application performance, or you will use it for complicated configuration data (and your users will hate you because a name value format like ini files is easier to handle - well, mostly)
    • lmm 10y ago
      > I don't quite see why you can't do the same with xml; maybe it needs some more typing, but it is expressing the same thing. It's not idiomatic though - the dog's paws aren't "healths". The point is that in XML each tag is expected to have a label and be an entity in its own right, whereas in JSON you expect each field to be an attribute.
• barrkel 10y ago
  Graph theory terminology: nodes are connected by edges. When drawn, the edges are the lines, the nodes are the blobs that are connected by lines. All trees are graphs. Not all graphs are trees; there could be cycles, or children with multiple parents in an arbitrary graph. In JSON, the nodes are literals: numbers, strings, booleans, arrays, hashes (object constructors). The edges are hash keys (object field names in the constructors). In XML, the nodes themselves have the names. The edges are implicit in the syntax via containment, and are unlabeled. In programming languages, generally our values don't have names. Instead, our variables have names, and refer to values; variables can be assigned different values, but the name doesn't change. More physically, if the values are stored on the heap, variables are pointers to values on the heap, and fields of heap objects are further pointers to more values on the heap. Here, variables and fields are edges, and the values are the nodes. Looked at from a graph theory perspective, the in-memory model is an edge labeled graph.