5 ms·

Large data sets should be published in XML. Small transactional exchanges (already contextual) should be JSONP.

rb2k_ 15y ago
I agree, another way of phrasing this would be: - XML is for documents - JSON is for data-structures Both of them do a great job in their domain, but you shouldn't try to mix them up and store data-strctures in XML or Documents in JSON
MatthewPhillips 15y ago
If we had a JSON query language as powerful as XPath would you feel the same way? I can't think of any other reason for agreeing with you (thought XPath is reason enough). Edit: While underscore.js is wonderful, I doubt it performs nearly as well as XPath.
- masklinn 15y ago
  > I can't think of any other reason for agreeing with you (thought XPath is reason enough). Streaming JSON API/parsers are not wide-spread (and definitely not as widespread as SAX-style streaming XML parsers), which makes JSON unusable for datasets which don't fit in memory. And generally spreaking, I think most people would be satisfied with a CSS-type query language, I'm always surprised by the dislike my colleagues have for xpath and their lack of knowledge of it, even though xpath is one of the very few things I like in the XML infosphere (the other one being RelaxNG)
  - Xurinos 15y ago
    Is the real pro-XML argument, then, that it currently has support? As far as I know, there is nothing inherent to JSON to prevent anyone from writing a streaming parser.
    - deleted 15y ago
      [deleted]
    - masklinn 15y ago
      > Is the real pro-XML argument, then, that it currently has support? That's the only one I can find which would be relevant to milweed's assertion that: > Large data sets should be published in XML. Apart from the rarely used ability to mix data formats into a single semi-coherent document and some sort of backwards compatibility, I don't see much in the way of reason. > As far as I know, there is nothing inherent to JSON to prevent anyone from writing a streaming parser. Of course there is not, and there are several such parsers, hence my writing that they are not widespread. Were they impossible (or non-existent) or at the very least unknown to me I'd have written that they don't exist instead.
  - xtian 15y ago
    JSONSelect (http://jsonselect.org http://jsonselect.org) provides a CSS-like query syntax for JSON. I haven't used it much yet, though, so I don't know how it performs.
  - lloydhilaiel 15y ago
    As for streaming JSON parsers: https://github.com/lloyd/yajl https://github.com/lloyd/yajl Around for four years. Stable. Language bindings for all major languages.
epistasis 15y ago
I guess it depends on your definition of "large," but I would say that large is where XML is at its very worst. When data can't fit in main memory, then the XML overhead provides no benefit and incurs a great cost. I would argue that data in general does not fit well to XML. Documents do fit well as it's absolutely fantastic at markup, i.e. where there isn't repeated structure. As soon as you have repeated structure (i.e. data as opposed to datum) then XML becomes a terrible format. CSV, tab-delimited, gzipped and separated by pipe characters, RDF triples, N3, give me almost •anything* other than XML and I'll be much happier. In fact, XML is the reason that RDF is dead in the water. RDF could have been a useful concept, but it's so encumbered by a terrible formats and tools that it will almost never be useful; it can not escape the existing body of XML-RDF. And such a waste in the name cargo-cult mimicking of HTML.

rb2k_ 15y ago

I agree, another way of phrasing this would be: - XML is for documents - JSON is for data-structures Both of them do a great job in their domain, but you shouldn't try to mix them up and store data-strctures in XML or Documents in JSON

MatthewPhillips 15y ago

If we had a JSON query language as powerful as XPath would you feel the same way? I can't think of any other reason for agreeing with you (thought XPath is reason enough). Edit: While underscore.js is wonderful, I doubt it performs nearly as well as XPath.

masklinn 15y ago
> I can't think of any other reason for agreeing with you (thought XPath is reason enough). Streaming JSON API/parsers are not wide-spread (and definitely not as widespread as SAX-style streaming XML parsers), which makes JSON unusable for datasets which don't fit in memory. And generally spreaking, I think most people would be satisfied with a CSS-type query language, I'm always surprised by the dislike my colleagues have for xpath and their lack of knowledge of it, even though xpath is one of the very few things I like in the XML infosphere (the other one being RelaxNG)
- Xurinos 15y ago
  Is the real pro-XML argument, then, that it currently has support? As far as I know, there is nothing inherent to JSON to prevent anyone from writing a streaming parser.
  - deleted 15y ago
    [deleted]
  - masklinn 15y ago
    > Is the real pro-XML argument, then, that it currently has support? That's the only one I can find which would be relevant to milweed's assertion that: > Large data sets should be published in XML. Apart from the rarely used ability to mix data formats into a single semi-coherent document and some sort of backwards compatibility, I don't see much in the way of reason. > As far as I know, there is nothing inherent to JSON to prevent anyone from writing a streaming parser. Of course there is not, and there are several such parsers, hence my writing that they are not widespread. Were they impossible (or non-existent) or at the very least unknown to me I'd have written that they don't exist instead.
- xtian 15y ago
  JSONSelect (http://jsonselect.org http://jsonselect.org) provides a CSS-like query syntax for JSON. I haven't used it much yet, though, so I don't know how it performs.
- lloydhilaiel 15y ago
  As for streaming JSON parsers: https://github.com/lloyd/yajl https://github.com/lloyd/yajl Around for four years. Stable. Language bindings for all major languages.

epistasis 15y ago

I guess it depends on your definition of "large," but I would say that large is where XML is at its very worst. When data can't fit in main memory, then the XML overhead provides no benefit and incurs a great cost. I would argue that data in general does not fit well to XML. Documents do fit well as it's absolutely fantastic at markup, i.e. where there isn't repeated structure. As soon as you have repeated structure (i.e. data as opposed to datum) then XML becomes a terrible format. CSV, tab-delimited, gzipped and separated by pipe characters, RDF triples, N3, give me almost •anything* other than XML and I'll be much happier. In fact, XML is the reason that RDF is dead in the water. RDF could have been a useful concept, but it's so encumbered by a terrible formats and tools that it will almost never be useful; it can not escape the existing body of XML-RDF. And such a waste in the name cargo-cult mimicking of HTML.