Hacker News Reader

"key: function(){alert("Oh joy, someone used <em>eval!</em>");}"

That is not JSON. JSON is a rigidly specified serialization format as described at http://json.org , and exactly that. It is not merely "whatever some Javascript intepreter will accept", because that is a terrible data exchange format. Functions are not allowed in JSON.

Also you forgot to double-quote your key, which is required. In fact using single-quotes for keys in JSON is forbidden, even though Javascript permits it. But this is less important than claiming JSON can carry function definitions.

"XSLT can be modified to work on JSON, ..."

Anything can be made to work on anything. XML does have a large stack of standards that contains stuff that already is defined and exists, so you don't have to do the job of making the things that work; you just go grab a parser and an XSLT transformer, rather than writing it yourself. My personal favorite is namespaces, though nobody ever uses them correctly and consequently they're much less useful than I'd like. That's what it means to say XML does something when JSON does not; Turing complete languages can accomplish any task on either format, but you can't just go grab things for JSON as easily. You mention non-compliant libraries which absolutely is a big problem, but compliant libraries can be found.

This is correctable over time, certainly, but bear in mind that the very act of correcting JSON will turn it into the same monster that XML is, albeit perhaps a bit simpler. A JSON schema language will be the same pile of complicated stuff that the XML schema languages are. The problem is the complicated thing there, not the solution, and your solution may not be simpler than the problem. Some of the other "XML problems" are of the same nature; the problems with SOAP, for instance, have almost nothing to do with XML and everything to do with trying to be The Ultimate Solution to Everything Everywhere and consequently being a complicated pile of useless garbage.

Don't mistake me for an XML partisan. I say use JSON now unless you are actually dealing with marked-up text, in which case XML is superior. But if you're going to make good decisions about what to use, you need to understand both very well and the reasons behind that rule-of-thumb I give, not "XML bad, JSON good."

Agreed. But isn't a language defined largely by what people are willing to do with it? XML has some wonky specifications that ultimately mean parsing XML is entirely indeterminate - external, over-http schemas, for instance. If every JSON parser in the world accepted single-quotes for keys, wouldn't that imply JSON supports single-quotes for keys? Would every subsequent parser that supported single-quoted keys be wrong for doing so? Same thing for namespaces: because people have abused them so horribly, they're almost useless.

XML libraries have been around for a long time. As have problems with XML libraries. Apparently it's not correctable over time, there's too much legacy to fight against.

---

>I say use JSON now unless you are actually dealing with marked-up text, in which case XML is superior.

I've heard that argument before. How, precisely, is it superior? It's denser than would be doable in my example, but is denser better? A lot of the arguments around both languages revolve around human vs computer readability. Is <em>text</em> more computer-readable than {#:"em", $:"text"} ? A bit more human-readable, yes, but I'll take "text" over either as often as I can.

> But isn't a language defined largely by what people are willing to do with it?

This isn't true for a formalized language. Heck, it isn't even true for FRENCH where there is an official bureau that determines what is "proper" french, and any deviations from it are not part of the standard language.

> If every JSON parser in the world accepted single-quotes for keys, wouldn't that imply JSON supports single-quotes for keys?

It might in the absence of a formal spec, but not all JSON parsers accept single quotes.

For example, the official Python JSON parser does not.

>>> import json >>> json.loads("{'foo':'bar'}") ValueError: Expecting property name: line 1 column 1 (char 1)

I question how many other highly popular languages have JSON parsers built to the spec.

Tons of highly popular languages don't have XML parsers built to the spec. Very few of them can handle schemas at all, or recursive definitions in schemas, or external document types, or external entities or schemas (and the few that can are usually disabled intentionally, because they can make parsing a tiny XML file take minutes if the server of the schema doesn't serve it up fast enough). That the XML spec defines such things is irrelevant if they're wholly unreliable because enough parsers refuse to handle them. And there are more than enough horror stories out there to argue that a significant amount of systems don't handle to-spec XML.

There are plenty of RFCs out there that define things that no longer practically exist - should they be used, because the spec defines something that you need? Especially if it's meant to be used as an interchange format?

And if JSON did all of those things the libraries that implemented it would suck as well: the complexity comes from the semantics of what all of those things are and do (schema validation is a complex problem, and that has nothing to do with whether you are validating XML or JSON), not how to parse a silly file format.

Hell: a lot of highly popular languages, to be quite honest for a minute, probably don't even have compliant JSON parsers. The real problem here is cowboy developers who think "oh, JSON/XML/whatever is easy, I can throw one of those together in a few minutes" and then /don't even read the spec/ before committing their project into some poor language's standard library.

I once explored the topic of "xml is just verbose s-exps" with someone who had no lisp experience. His first response was that it would be impossible to just use lisp in place of xml because you would then have to implement a minimal lisp parser into any language that wanted to make use of data stored in s-exps. I then pointed out that you have to do the same thing for xml or json, it's just that we've become used to standard tools existing to do this.

That's actually where I find that XML is the most dangerous. People just take it as a fact of the universe that XML exists and make so many assumptions about how it solves a particular problem that they don't even stop to think "could there be a better way?"

I'll admit my ignorance about the existence of S-expressions (had to look them up here: http://en.wikipedia.org/wiki/S-expression )

I've used XML because .NET has a parser, and I'll probably use JSON because parsers are widespread... are there good standard parsers for S-expressions for .NET or other popular platforms?

A quick googling sends me here

http://stackoverflow.com/questions/3051254/parsing-lisp-s-ex...

which makes me believe.NET can't natively process s-expressions with ease, and that's a HUGE minus for me.

Few lines of code in the last answer is actually everything you need to parse (reasonable subset of) S-expressions. So there probably isn't any general purpose programming language that cannot handle S-expressions with ease.

That holds if you want to use S-expressions as data exchange format (or like network protocol as is done by Subversion). Parsing Common Lisp source is entirely different matter.

It does seem you can handle them, but we .NET people are lazy (as in, Larry Wall lazy http://en.wikipedia.org/wiki/Larry_Wall ).

I agree with the poster's reply to that: "Yes I agree that this is simple and fast, but.. What I really want is a 1-D list of my own object types." I get that when using XML web services with .NET (though mostly when consumed with other .NET or similar languages !!! which goes against it being an universal data transfer language )

Exactly. XML is a format, nothing more; it's the culture and everything around it that makes it a problem.

> That's actually where I find that XML is the most dangerous. People just take it as a fact of the universe that XML exists and make so many assumptions about how it solves a particular problem that they don't even stop to think "could there be a better way?"

Unfortunately, even when presented with numerous implementations of interesting algorithms like schema validators, tree transformation tools, etc. that /happen/ to use XML (for our purposes, a specific verbose dialect of s-expressions) as an interchange format, the entirely opposite problem occurs: people ask the question "could there be a better way?" needlessly, and then reinvent some subset of all of that tested and working code based on around something they made up, or even something people generally like (JSON), and throw away all of that existing ecosystem; and, in the end, the only way in which it is better is that it isn't XML.

    {
      "name":"Product",
      "properties":{
        "id":{
          "type":"number",
          "description":"Product identifier",
          "required":true
        },
      ...

Though the json representation of json-schema is nicer than XML, I think this approach to a schema language is just as bad as XML Schema. It even looks like they're trying to replicate the features of XS. Which might make sense from an adoption point of view, but ...

There isn't that much difference between hierarchical data formats. Even here, some people favour s-exps or YAML over JSON. So once one gets established it's difficult to dislodge due to standardization, network effects, tools, user familiarity etc. However, it can change when there is a new platform, which starts fresh with a different format.

JSON already owns browser communication (though note the pesky X in AJAX...), since browsers already use JavaScript, but it seems unlikely to usurp XML much further (exception: JS becomes prevalent on the server-side).

The better schema for JS - should be staticly typed classes/objects.

> though note the pesky X in AJAX... it also sometimes called AJAJ

Two comments:

1. You forgot namespaces. Gotta put SVG in your XHTML.

2. By the time you've done your translation, you've created json that is uglier and harder for a human to visually parse than the equivalent xml.

It turns out that json is useful when you don't want xml's features. Trying to shoehorn every one of xml's features into json creates another brand of hell.

1) Namespace complaints pop up every time JSON debates pop up. XML handles them two ways, and their equivalents, fully within what I already defined:

  ns:node => {#:"ns:node"}
  xmlns="http://www.w3.org/1999/xhtml" =>
    {"xmlns":"http://www.w3.org/1999/xhtml"}

ie, it's already handled. Namespaces are a parser's job for interpretation, the notation is simple.

2) The point wasn't to say JSON is better than XML - apparently you didn't read my second sentence. I said they're trivially identical - they're the same thing, with the same capabilities, but with minimally different ways of representing the same data. The point is that claiming XML can do X because it's XML and JSON can't because it's not XML is complete nonsense. All the schema / XSLT / etc tools are just that - external tools, algorithms to run against data, which have nothing to do with how the data is transmitted.

The key problem I have with your #2 is that it ignores what people actually mean when they say "can't". When I say I can't lift that rock over there, I don't mean that if I went and trained for a few years I wouldn't be able to do it: I mean that if I went over there right now and tried to lift it I would fail. When you realize that this is what normal people mean by "can't", suddenly concepts like "XML can do something JSON can't" make perfect sense: there exists a tool/library that makes that happen right now, and for JSON it is some theory that you have that would require sitting down and spending a bunch of time coding. (And no: those people don't "actually believe" that JSON could never be made to do those things ever: the more you interrogate them on this matter the more it will seem that way as they are going to keep saying "can't" and it is going to keep meaning something different from the way you are using it.)

I was more trying to say that XML is better for heterogenous trees because XML's default is a tree structure. XML parsers default to a tree representation of your data (we use python's ElementTree, for example), JSON parsers don't. XPath is designed to be a tree navigation language. CSS selectors are... also designed for navigating XML. No equivalent exists for JSON that I know of.

Obviously, we could use JSON or YAML or S-Expressions for representing something like a parse tree, but none of them have the same robust tool chain for tree manipulation that XML has.

>JSON parsers don't

How could they not? It's JavaScript Object Notation. Objects which refer to sub-objects form a tree.

As to CSS selectors for JSON: the same functionality can exist, because as per above they have literally identical capabilities for representing data. I'll readily admit though, I've not seen one (though one of my side-projects could probably be tweaked to do this; maybe I will).

I have nothing against XML. It's useful, widely supported, and has quite possibly more tools than any other interchange format. The problem isn't with XML, it's with the inconsistencies of (and between) those tools that make the whole interchange part of XML with specs (the only really useful part - it's a horribly wasteful storage format) almost a moot point. And due to legacy systems, it's unlikely to change any time soon, or perhaps ever.

So a clean break is likely necessary to really improve things.

FYI if you use elementree, try lxml. It hasx path support, which you'll wonder how you ever did without.

I find that one thing you can do in XML but not in JSON is comments. There isn't any equivalent of XML Comments in JSON. Frequently, my configuration files require comments to show what options are available, or to easily turn off an option temporarily by commenting it out. I don't see how to do that if my configuration files are in JSON.

I'd imagine it depends on your parser, and if non-browser JSON gets more prevalent it'll probably be addressed. JSON has no format specified that I'm aware of, but some browser-like parsers will handle things like this:

  {"key":"value" // comment
  or 
  {
    // comment
    "key":"value"

Which I find wholly acceptable (though poorly supported).

Wouldn't that only work if the json/javascript is pretty-printed and not minified?

I'd think this problem of comments in JSON requires a solution that is part of the JSON specifications rather than dependent on individual parsers implementations.

Or perhaps JSON only really shines as a data interchange format and not much else.

Sorry, on iPad and accidentally downmodded your useful comment.

>and XPath == CSS-like selectors with a different set of characters.

I also have a feeling, that jQuery reinvents XPath.

Not if you take jQuery and compare it to XML library X, because that's the actual comparison. XPath == Sizzle, not jQuery - jQuery adds functions to manipulate what the selector returned, which the selector really has no business doing.

What in jQuery is a chain of multiple selectors and filters, can be done using single query in XPath, i.e.

  "document()/html//div[class='title']//img[class='icon']/@src"

I gather you haven't done much jQuery coding. That's equivalent to:

  $("html div.title img.icon").attr("src")

The last .attr("src") is purely because jQuery always deals with a node / a collection of nodes.

You can also do arbitrary attribute searches:

  $("html div[class~='title'] img[src*='google']")
  // "~=" == "contains word" - space-delimited to match html classes
  // "*=" == "contains substring"

http://api.jquery.com/category/selectors/

You're right, but jquery doesn't handle XML namespaces. Alas I wish it did.