111–120 of 120 posts
He nailed it: XML should be used for markup, JSON or YAML for structured data.
Isn't YAML a subset of JSON? or vice versa?
The "XML requires you to build your own parse tree" argument isn't valid; XML libraries are fully capable of handing you a DOM-style tree, and of allowing you to pull things out of the tree without writing your own traversal code. JSON just assumes messages are going to trivially fit into naive data structures, and so provides fewer options.
What is the advantage of XML over JSON for nontrivial, non-naive data structures? Do you mean things like XLink/XPointer? (Or where can I go to read more about this?) I've gotten the informal impression that incidental complexity (you know, complexity arising not from the problem but the solution) is a factor behind the hugeness of the XML ecosystem, but I'd be happy to learn otherwise...
You are absolutely correct.
As Phil Wadler put it: "The essence of XML is this: the problem it solves is not hard, and it does not solve the problem well."
It makes a trivial issue into a byzantine enterprise.
But, it has created a whole industry of 'experts', standard committees and other busybodies, so it must be good for the economy at least!
Earlier quoted context omitted.
You know, I know we're just geeking out here so please don't read too much into me taking the devil's advocate position, but: yes, XML is harder to parse , but the underlying data that gets encoded in JSON and XML isn't substantially different. In both cases --- and let's take the C implementation case --- you're still building a poorly specified buggy implementation of Tcl to actually hold the data and answer questi…
Dunno why you got downmodded there.. Anyways, if they're equivalent, and JSON is both easier to parse and has a far higher data density.. why would anyone ever use XML for anything?
I ask myself that every day.
XML is a huge scam perpetrated on the software industry, but now it is too late because a huge parasitic 'industry' has built around it, and too many people (specially too many PHBs) have invested their reputations on XML being the ultimate standard for representing data.
Earlier quoted context omitted.
You know I never quite got that comma thing. For instance in python, the only reason it is necessary is because {"foo": "bar" "baz", 'k2':'v2'} is the same as {'foo':'barbaz', 'k2':'v2'}. Getting rid of auto-concatination allows for {'foo':'barbaz' 'k2':'v2'} which is pretty easy to parse base on tokens and ':'. It also eliminates a pretty common bug, in which there is kv pair per line, and the line ends with ',', ex…
Python lets you put the commas before the items, like so: { 'foo':'barbaz' , 'k2':'v2' } Ruby doesn't like that though. Both Python and Ruby will ignore an extra trailing comma on the last item, which gives you another way of avoiding the common bug you describe.
On a similar token, I'm so happy REST won over WSDL.
Earlier quoted context omitted.
I'm not sure if you are complaining about this aspect, but I would observe that "fewer options" is actually the feature here, not the bug. A generic XML DOM is still complicated to deal with. Even if you do the "right thing" and use XPath, you still have to deal with XPath because you can't get around the fact that you have an underlying representation that has at least two dimensions (attributes vs. CDATA). That is,…
The only thing I miss when using json are the css selectors when trying to find data in a nested structure. With json I have to resort to imperative means and care about the middle layers. That means refactorings are more likely to break software. Fundamentally there is no reason why json cannot have it's own selector which traverses the tree. There just isn't one that I know of though.
As one of the earlier commenters pointed out, lisp welcomes you to the 1960s.
Yeah, sure. S-expresssions are literals in Lisp, and can be "parsed" calling eval. But I think that misses the larger point made by the OP. JSON is really useful even in languages other than Javascript. JSON wins over XML because XML is too complex and thus ambiguous. But JSON wins over s-expressions too, because s-expressions are too simple. How do you represent John Smith as an s-expression? Sure, it can be done. B…
No on both counts.
(1) S-expressions aren't literals.
(2) s-expressions are not "parsed" by calling lisp eval. Lisp eval's argument is an s-expression - it doesn't parse anything. (It also doesn't read anything.) Lisp read turns character sequences into s-expressions.
> But JSON wins over s-expressions too, because s-expressions are too simple. How do you represent John Smith as an s-expression?
If you'd like, exactly the same way you'd represent it in JSON, because lisp's read handles a superset of the JSON datatypes.
> software that consumes s-expressions has to know how to interpret their structure
As does JSON.
Take your example John Smith. What JSON datatype do you expect to get? (JSON just has numbers, strings, arrays, booleans, and hashes, where the keys have a restricted format.)
Earlier quoted context omitted.
NO. Sorry but you're doing it wrong. Relying on the editor to highlight parentheses is a highly inefficient and error-prone way to work. It's distracting, it wastes mental cycles and inhibits flow. The correct way is to configure emacs so that when you press a certain key (in my case, right shift because I configured my keyboard so I can activate left shift with my thumb), emacs inserts "()" and puts the cursor in th…
If there's backing to the assertion that I'm doing it wrong in there, I didn't find it. Incidentally, I use emacs and Lisp every day.
Earlier quoted context omitted.
> Not enough data types in CL [reader] Huh? CL's reader handles structs, hashes, and vectors in addition to strings, lists, atoms (with packages), lots of number formats (including Roman), and the ability to express AGs, not just trees (yes, cyclic too). Plus some other things that I forget. (Arrays?) What else do you want to read? No matter - CL's reader is programmable....
You can do hashes in the CL reader? How? I don't recall being able to, from back when I was trying out CL. It's probably bad you can express cyclic graphs. That means you'll have to watch for denial-of-service attacks phrased as cyclic data. Programmable reader isn't the point. That gets you back into defining your own syntax. The point is to have a standard.
You can turn it off. However, if cyclic graphs (or general DAGs) are important, supporting them means that you don't have to roll your own.
> Programmable reader isn't the point. That gets you back into defining your own syntax. The point is to have a standard.
The writer and reader have to agree no matter what you do. A programmable reader means that you don't have to roll your own in more cases. And, it makes it easier to test the third-party writers. (The reader folks can just publish the read-table.)