5 ms·

Even if my data looks like a document, I refuse to use XML. It's just too clumsy to traverse compared to JSON.

• catshirt 10y ago
  really? xpath is one of the more redeeming values of XML. i'm not sure i can call it clumsy. i refuse to use XML just like everyone else, but not because it's hard to parse data from.
  • rileymat2 10y ago
    One of the nicer experiences I had was using xpath to write some basic automated tests on a xhtml strict page. Everything just worked really well.
• jimbokun 10y ago
  XPath, XSLT and XQuery are pretty awesome, in their special way. Although stringly-typed XPath has the same problems as SQL, building complex queries through string concatenation. This is where JSON shines, because you usually just convert to a tree of your language's native data structures in one line and use your languages native facilities to traverse it from there.
  • andyjohnson0 10y ago
    Is there an equivalent of xpath for searching/traversing in-memory js object graphs?
    • Chyzwar 10y ago
      you can use chained map/reduce. object.listOfItems .reduce((item) => item.type === 'car') .map((item) => item.name)); This is way more powerful than xpath.
      • mhd 10y ago
        Sometimes all you need is printf, not direct memory access to the character byte array.
      • arethuza 10y ago
        What about things like axes in XPath?
      • AlbertoGP 10y ago
        Hi, I think that instead of "reduce((item) => item.type === 'car')" you actually meant "filter((item) => item.type === 'car')".
    • dschep 10y ago
      There's JMESPath: http://jmespath.org/ http://jmespath.org/
    • kisstheblade 10y ago
      Jsonpath, eg. https://github.com/jayway/JsonPath https://github.com/jayway/JsonPath
• nly 10y ago
  Devs who think JSON is wonderful to work with probably think so because they're using a dynamically typed language. The advantage of a schema is you can validate your data and move to static typing in only a few lines of code. It's for this reason that I think the best option these days is to just use something like protobufs v3, which has a stable JSON serialization and a sensible schema specification. But even for objecty data, rather than "documents", XML doesn't have to be clumsy. Checkout the code samples here for C++ http://www.codesynthesis.com/products/xsd/ http://www.codesynthesis.com/products/xsd/
• drdaeman 10y ago
  XML has its bad sides (hell, I won't ever forget hacking Perl's SOAP::Lite to make it be able to talk with some extremely enterprisey Java service), but its core isn't as bad as many try to picture it. The really good thing about XML, that it - unlike JSON - is extensible. And traversing both JSON and XML (without the weird parts) are no-brainers. Every (or about so) mainstream language has libraries that make either format really transparent to use.
  • gnaritas 10y ago
    > Every (or about so) mainstream language has libraries that make either format really transparent to use. That's really only true about XML, that is not the case with JSON. JSON is a pain to work with in C# for example compared to XML.
    • drdaeman 10y ago
      I have different experience. I did some toy project in C# and haven't found handling JSON any painful. Maybe I just haven't hit the bad cases, though. I don't exactly remember what I've used and what I wrote, but I think I had just installed some library (IIRC it was Json.NET), put some annotations on classes, and got my serialization. For deserialization I didn't wanted to write throwaway classes so I just made a JSONPath query and iterated over the result objects, looking at necessary properties. Nothing particularly different from how things are in, say, Python, except maybe for some extra type checking.
• MichaelGG 10y ago
  My biggest problem with using JSON, apart from the needless quotation marks on identifiers, is the lack of comments. Any human-editable format (like using .json for project config files or build files) should have comments.
  • tracker1 10y ago
    I'm in favor of using YAML [0] or INI [1] formats when a file is meant to be edited by a user. YAML is close enough to JSON, but does support comments, and the structure is a bit cleaner for user editing. [0] https://en.wikipedia.org/wiki/YAML https://en.wikipedia.org/wiki/YAML [1] https://en.wikipedia.org/wiki/INI_file https://en.wikipedia.org/wiki/INI_file
  • TMSZ 10y ago
    There are few ways of inserting comments: http://stackoverflow.com/questions/244777/can-i-use-comments-inside-a-json-file http://stackoverflow.com/questions/244777/can-i-use-comments... If you do not care too much about exchanging data with other apps then parser/generator supporting javascript style comments (e.g. json-cpp) would work. With each JSON value it can store "commentBefore" and "commentAfter". If you need you can strip these comments any time by parse + write cycle with "collectComments" option inactive.
    • MichaelGG 10y ago
      Adding data and calling it a comment isn't really a comment. And I find the whole "run minifiy/strip first" to be a hilarious suggestion from Douglas Crockford. It can be rephrased as "If you want comments in JSON, for a config file say, then don't use JSON." That, and XML requiring the tag name in the closing tag, are some of the obvious, silly, mistakes. XML in particular. Without the named closing tags, just using, say, <>, would reduce the apparent bloat and annoyance by a very large factor.
• gnaritas 10y ago
  In statically typed languages, JSON is awful and clumsy compared to XML which has a standard parser and query language. There's pretty much no case where JSON is easier to traverse than XML. I'd challenge you to back up that statement.