4 ms·

JSON can't express ordering or duplicate fields in a consistent way. Consider how you'd write these 2 bits of XML in JSON: <A><B>foo</B><C>bar</C></A> vs. <

• picometer 5y ago
  { "a": [ { "b": "foo" }, { "c": "bar" } ] } vs. { "a": [ { "b": "too" }, { "c": "bar" }, { "b": "uh oh" } ] }
  • nly 5y ago
    Yes, so in essence: - Only ever have a single key in each JSON object (treating them as tuples) - Make all object values arrays. It makes for some very unnatural looking JSON.
    • 8note 5y ago
      The only thing that doesn't look natural to me is that it's all on one line. Otherwise it's very clear about the data's format and when there's ordering required
    • dragonwriter 5y ago
      > It makes for some very unnatural looking JSON. Not to me; its a fairly standard and natural JSON pattern. It’s tue that it use is usually quite limited in any given representation, but usually the thing you are modelling in JSON isn’t general XML with no further knowledge of application domain or logical schema.
  • enriquto 5y ago
    > { "a": [ { "b": "foo" }, { "c": "bar" } ] } This looks like line noise to me. All that punctuation and quoting looks ridiculous. What is the problem with straightforward and trivial to parse things like [a] b = foo c = bar or even a.b = foo a.c = bar
• dnautics 5y ago
  So this is exactly a symptom of unclarity of the roles that xml causes in the first place. It seems like You're trying using the tags as keys instead of as information categories. In json you might encode these sorts of data as something like (pardon my lack of quotes, I'm on mobile): {a_list:[{text: too, type: b}, {text: bar, type: c}, {text: uh_oh, type: b}]}} But generally you shouldn't have a mixed type list in json unless it's a deliberate choice, the "limitations" of json are exactly what devs want because it corresponds to a clarity of thought and purpose that simply isn't there in XML.
  • nly 5y ago
    In my case the parse tree had nodes that corresponded with grammar rules (mapped to XML elements) and nodes that corresponded to the preserved but otherwise uninteresting fluff that surrounded them (mapped to XML PCDATA). We wanted a parse tree that could be serialized out to produce the original document byte for byte, but still reflected the grammar. Things get uglier for JSON in the real world case: "5+7 #comment" becomes: <sum><integer>5</integer><operation>+</operation><integer>7</integer> #comment</sum> The XML output is essentially the original input + grammar markup. Your solution also works but is a data structure representation with a lot more line noise for humans to read.
    • dnautics 5y ago
      It just looks bad because I made it one line; by comparison if I hadn't seen the pre-parsed form 5+7 I would not be able to immediately grok what is going on in your parsed one-line XML, either; there's a lot of "line noise" there too. Moreover it feels like the XML you have has lost the structure of the meaning, by having the tokens 5, +, and 7 be linearized. You probably want a tree with + at the root and 5 and 7 as leaves. That XML encourages these sorts of "oddly flat" representations is one of its weaknesses.
      • nly 5y ago
        + at the root would indicate an abstract syntax tree rather than a concrete or "full" syntax tree (terminology varies slightly) This was primarily a mechanism to load parsed documents in to code that didn't have access to the recursive descent parser that parsed the document, for either security or performance reasons. Loading the XML with the appropriate parse flags, doing a pre-order traversal on all the leaf PCDATA, and then printing it out, would regenerate the original document byte for byte. Perhaps I should go back and implement JSON output and see how I feel about it... thought I'm pretty sure once you introduce a bunch of "text" and "type" fields to the JSON tree it's going to look a lot less readable than XML markup. There are other fields as well like line and column numbers (output as XML attributes)
• dragonwriter 5y ago
  > Without a schema, in the first case, how do you determine whether B should be "foo" or ["foo"]? In the second how do you preserve the relative ordering of B #1, C and B #2? Well, if you are literally developing a model for recasting general XML in JSON, then you know the children of an entity should be a list because duplication os possible and order is signifcant. (Given the close relationships between XML and HTML and between JS and JSON, the obvious starting point for a general solution is to copy the HTML DOM, using only the properties.) If you are trying not to reserialize XML generally but to solve the same problem as the original XML, then you probably aren’t doing it without a (logical) schema—you know what the object model is that you are trying to stuff into JSON, and you decide based on that.