Deprecating XML | Hacker News Reader

Deprecating XML

norman.walsh.name

106 pointsadambyrtek91 comments

After three years working in Big Freaking Java Web Applications which needed to frequently talk to other Big Freaking Legacy Applications, which is pretty XML's core use case, I struggle to think of a concrete example of a time where XML was a clear win over JSON. I spent a lot more time fighting XML (and, more importantly, libraries built on libraries built on libraries which parsed XML which failed to interact with libraries built on libraries built on libraries which parsed XML in a subtly different and incompatible way) than I spent enjoying the richness of my namespaced mixed content.

We were once, no lie, forced into JSON-over-XML because of technical and organizational imperatives that had to be reconciled with the need to ship functional code sometime this year. ("The web services parser is breaking again!? Screw it. We only need three fields. JSON grab bag, serialize as string, read string and interpret as JSON on other side.")

"After three years working in Big Freaking Java Web Applications which needed to frequently talk to other Big Freaking Legacy Applications, which is pretty XML's core use case"

This is absolutely, positively, NOT XML's core use case. This is yet another case of Big Freaking Java Web Application developers finding a way to add gratuitous complexity, along with their dependency injected, aspect oriented, AbstractDataSourceFactoryFactoryImpls.

By the way, a quick Google brought up this, which is evidently not a parody but actual code:

http://www.docjar.org/docs/api/org/outerj/pollo/xmleditor/Fa...

The mixed content case does not occur in the vast majority of Big Freaking Java Web Applications.

There are sometimes when the closest route to the goal, given that you are building a Java web application, runs through very small voice a factory factory. They're a possibly degenerate consequence of the interaction of a few things which, separately, defensible ideas.

One of these things is that you want to be able to pass objects over the wire without having to reduplicate all the code on both sides. For example, if you have Student objects in the student management system and also have Student objects in the university SNS, and those systems need to periodically pass data between each other, somebody might say "It would be great if they could do that without us having to custom-write data massaging routines. After all, we already have student code on both systems." and another guy might say "True, true, but we don't want to keep the Student class in sync on both systems neessarily." and then a choice gets made and someone forgets that one of the Students contains a graduation date implemented by a long-forgotten contractor as a wrapper class with some utility functionality which contains a Locale which cannot be serialized and then all of a sudden you are in the sixth layer of XML Hell.

Not that I'm arguing with you -- God willing, I will never, ever have to work with Java architecture astronomy again.

HTML is pretty much XML, should it be JSON?

No, but it's much nicer to use Markdown and friends for a lot of it.

Really, HTML is needlessly verbose and annoying - we're just used to it. If you take a look at something like HAML (not that I agree with all of their choices), you can see how much nicer it could be.

"Really, HTML is needlessly verbose and annoying"

That "needless" verbosity makes error correction much more robust. Haml has a shit fit over the slightest of irregularities. The XHTML experience should be proof enough that trying to enforce picky parsing rules or highly context-dependent syntax leads to breakage.

Try saving a marked up document as JSON.

You make a good point yet outside of XHTML and perhaps XSLT, I've never seen a document marked up as XML. I have, however, worked on hundreds of projects that used XML as a structured data exchange format, for remote procedure calls, or for configuration.

I routinely save HTML markup as S-expressions (S-XML) which is almost as readable (and slightly easier to parse) as JSON, yet markup in it does not look as weird and ugly.

"XML deals remarkably well with the full richness of unstructured data."

What? No, it doesn't. XML has even more structure than JSON does. Unless you're using it improperly, and the you're negating all the advantages that XML was supposed to bring.

It wasn't for 'mixed content'. It was for system interoperability.

The advantage that XML brings over JSON is that you can have an external document that you can use to validate any XML you're sending or receiving. You can guarantee it's formatted correctly. JSON provides no such guarantee.

Not that that's necessarily a bad thing.

Think what the author meant is that XML allows documents where the structure is less predefined. It can be the markup that drives the interpretation. With a JSON payload, you need to know how the whole is structured to know how to use it, or build additional mechanisms over it.

Also XML brings other useful features like data types.

Is there a reason JSON fields can't be an object (of sorts) which defines data type, parsing rules, depth to read, circular structures, etc?

You can convert, losslessly, between XML and JSON. Doesn't that mean they have identical capabilities, though one may be easier in certain circumstances? There's no "need" in any one which the other doesn't also need.

"You can convert losslessly" – that's not the whole truth. It's an issue that there's no obvious or agreed upon way to render an XML format like ATOM into JSON, because everyone makes up their own transformation rules. Here are two distinct attempts: * http://www.ibm.com/developerworks/library/x-atom2json.html * http://code.google.com/apis/gdata/docs/json.html

Obvious or agreed-upon does not mean cannot. Google's, for instance, looks nigh-identical to what I'd have aimed for; nodes = fields, node-attributes = fields in the object on a field, node-text-content = specially-named field. It's a naive, 1-1 transformation between the two. Simple enough that I'd actually consider it the "obvious" way to do so.

IBM's, on the other hand, has a number of nonsensical statements like this:

>Because JSON is incapable of preserving any notion of a Base URI, it is unlikely that an application using the JSON serialization is capable of properly rendering markup containing relative URI paths. It is therefore important that such paths be resolved automatically during the conversion process as shown ...

Bull. Base URI is just a field, or inferred by the document's source. ie: the same as XML. Their technique is incapable of translating a Base URI, it has nothing to do with JSON. Theirs also cannot handle namespacing, while Google's is simple, and almost identical to how XML does it: namespace$field: value.

Well... as far as I know, json by itself is just objects with fields, these fields are either objects or string values. Of course you can do all you mention but you'll have to build a convention on top of json. So reading these json payload would require more than just knowledge of json, it would also require knowledge of what are these fields or objects that carry special interpretation meaning and what to do about it.

A lot of these conventions are available the XML standards. Of course if they had started with something like json the result would be less verbose but maybe not that simple either.

There's json-schema[1] if you feel like validating your json payload

[1] : http://tools.ietf.org/html/draft-zyp-json-schema-02

It only provides that guarantee because the parsers have agreed to do so (and not all do, nor do they do so identically). It's a guarantee by communal agreement, nothing more.

There's no reason a JSON format can't do the exact same thing. JSON-RPC, for instance, defines its own rules on top of JSON which anything using it must conform to. How hard would it be to make a set of JSON interchange rules which specify external schema documents?

edit: answer:

  {json_strict_version:1, schema:{external:[url,url], internal:[{schema},{schema}]}}

If I'm reading you right, you're saying that XML only provides a guarantee because of an abstract agreement between parsers? Nonsense. XML has a specification for what constitutes a well-formed document and an XML Schema defines rules that assure validity. XML may be verbose and the libraries may be a pain to work with (though there are some well-written ones out there) and there may be other flaws you want to bring up, but this is not a defensible point.

XML spec: http://www.w3.org/TR/REC-xml/#sec-conformance

>Conforming XML processors fall into two classes: validating and non-validating.

Yup, that's a guarantee alright. A guarantee consisting of the people who wrote the parser agreeing to write DTD-parsing code. Or not. Depends on your parser.

It has a specification for validation because a specification for validating it has been written, based on agreement of the specification and implementation by the parsers, not because XML has some inherent, magical validatability quality.

edit: this is all on top of that a spec is just a spec until someone implements it. Plenty of specs have been chucked because others did something else, or have attributes which nobody implements (how many email forms accept the full RFC-compliant email set?). A spec is an abstract agreement.

I have never seen anything that implements validating XML parser as intended by specification and is actually used in production code. Half of XML consumers I've seen in production implement namespaces in various broken ways (like depend on exact values of prefixes)

Well-formedness is a separate issue from validation. All XML parsers are required by the spec to reject documents that aren't well formed. You can think of it as the lexical analysis rules for XML, whereas validation is the parsing (if that helps).

I don't see the grandparent as pointing out a flaw in XML so much as pointing out that this isn't something that JSON can't be made to do. The only thing stopping you from having a "JSON schema" is that such a thing hasn't been blessed by a standards committee. There's nothing stopping you from writing a library that will validate JSON based on a JSON schema of some type.

Sure, and you can write JSON editors and namespace extensions and query languages and libraries with extensions for those query languages and then you find out that the JSON schema language isn't very good; so you make a new one and editors for that new schema language, and then you write a language to translate one JSON document into another one, with a schema for that new language of course, in all 5 of the flavors of schema languages.

And then we're 10 years into the future and we're seeing this exact same article again, except with s/JSON/some simple JSON replacement/g and we're back to square one.

JSON has its uses, it's quite nifty in its ease of use for doing ajax stuff, but imo the point of the article was to point out that xml vs json is a nonsense comparison much like 'sql' vs 'nosql' databases.

You mean, like they did with DTDs, RelaxNG, and XSD (and probably half a dozen ill-conceived solution that died a well-deserved death)?

Different XSD implementations do have slightly different ideas on interpreting the schema. (e.g., if your data has a bunch of A tags, then a B tag, then another bunch of A tags, do you include two occurs:unlimited statements for the A's or just one?)

By the way, Javascript works just fine as a "query" language for JSON. Not as good as XPath or XQuery work for XML, but definitely better than any XML DOM manipulation in Java or another language would.

Yes those are what I meant - my point was that this whole evolution needn't be repeated with JSON. Let's keep JSON for the things it's good at, and keep it simple, and keep XML for the things it's good, with all the complicated things we have for it now anyway.

An XML document is mixed content in the sense that it can be validated, signed, partially encrypted (perhaps by multiple actors), can be wrapped by a header, and augmented for application level routing. [edit: where each of these actions may mix-in content with the original document.] And all of this can be done in a standards compliant way.

Now the standards can totally suck - they can be improperly implemented - and they can be difficult to make performant... But those are largely issues of implementation unrelated to the core XML and XML namespace specifications.

It seems unlikely to me that JSON could reasonably be purposed to those use cases...

> It seems unlikely to me that JSON could reasonably be purposed to those use cases...

Since any XML document can in theory be converted into a complete JSON representation I do believe that nothing is keeping people from doing exactly those use cases. You're right in asserting that this isn't happening in practice with JSON. I allege the reason for this is that XML isn't really used for these kinds of operations either. Sure, the XML working group put out a stunning amount of "standards" that prescribe these conventions, but in practice NONE of it actually works across vendors without heavy intervention and some pretty shocking compromises in application code. Most complex XML products are not actually that interoperable, they mostly just work because one or more communication endpoints are basically faking compliance of their interfaces.

"Since any XML document can in theory be converted into a complete JSON representation"

How? (apart from a char array...)

A DOM is just a tree of nodes, each of which has a fixed set of fields based on its type. That makes it automatically doable if you throw enough collections of key-value pairs at it:

  # <a href="http://example.com">hello world</a>

  {
    "node-type":"element",
    "namespace":"http://www.w3.org/1999/xhtml",
    "name":"a",
    "attributes":[
      {
        "namespace":null,
        "name":"href",
        "value":"http://example.com"
      }
    ],
    "children":[
      {
        "node-type":"text",
        "value":"hello world"
      }
    ]
  }

Oh ok, yes. I think I may have misunderstood the original claim then, I thought the GP was saying that JSON had mechanisms to express all xml functionality. BTH though this still only makes sense with the XML spec laying next to it and is just notation. Maybe I'm not getting the point of the discussion, I'll just let it be ;)

Yeah, there's no agreed convention on how the infoset of an XML document (which I should have used rather than DOM) ought to be represented in JSON, and generally people don't do it (e.g., RDF/JSON isn't a direct mapping from RDF/XML, but a new format to express the same basic facts), it's just technically possible.

It really seems that a lot of people in this thread don't get the meaning of "mixed content". That's where you have plain text mixed with tags, and it's difficult to represent with JSON. If you don't think so, I'm curious to see a good way of doing it.

Here's a link that illustrates this concept:

http://seanmcgrath.blogspot.com/2007/01/mixed-content-trying...

It's not as persuasive as it could be, but it gets the idea across.

Only partially. Take a look at DOM interpretations for HTML's flavor of XML: that sort of [b][text]a word[/text][/b] markup is precisely what it interprets [b]a word[/b] as. Because that's what it means.

And in any case, in order to handle truly inline content you've still got to correctly detect such in-line code, and label it as separate from regular text which just looks like inline code. Which means escaping. Which means

  "text {b:'bold text'} more text"

is the same solution, with the same problems.

>Here is XML's sweet spot (using square brackets to keep everything un-mungable by the angle-bracket chewers in my current tool chain):

Sweet spot, in that parsers usually just assume everything which looks like code is code, even when the spec allows for other ways, forcing people to fake it with things like square brackets.

edit: whups. Editors, not parsers, are primarily responsible for such mangling, by making it hard to insert code-as-text. The problem with inline markup still exists, however.

God, but I hate XML, and sad to say, for the same reason a lot of people hate PHP.

I hate XML because it is so mis-used. People try to use it for EVERYTHING and you get these monstrous XML trees with legions of attributes, when what you're trying to send could comfortably expressed in "{success: true, message: 'Record deleted.'}".

I admit my ignorance, at least. I'm sure that were I properly shown well-used XML and these wonderful and vast tools that the competent XML worker has at their disposal, I'd be as happy to work with XML as I am to work with PHP.

That said, you won't ever catch me trying to write a 3D FPS in PHP, and I hope that if you ever DID catch me doing so, you'd give me the exact same fish-slapping that XML abusers deserve.

At the game studio I work at, they use XML for all scripting tasks: gameplay scripts and UI scripts.

As in, XML nodes are "game script commands" which are executed sequentially.

That's kind of like XSLT, a language with an XML syntax. I can see how that is an appealing use of XML since it basically is a nice representation of a high-level syntax tree.

I believe you have come up with a rare example where XML is decidedly better suited than JSON!

However, the majority of XML use cases are for document-interchanging applications and the way those are being handled requires massively bloated toolchains of poorly inter-operating software.

If you want a language with a JSON-like syntax, consider using JavaScript. (If you want a language with a uniform syntax, that's easy to parse, choose some form of Scheme or Forth.)

I believe though the point was that I kept wondering what it is specifically that XML does better than JSON, since the article didn't specify. And so it occurred to me that one way to make use of XML's inherent complexity is indeed to represent an instruction tree. But the question here is not what language is best, or even that JSON can used for the same purpose, it was merely the "discovery" of an inherent XML feature that would make reasonable developers prefer it for a certain task. The whole point is moot, however, since XML is actually intended for structured information interchange, regardless of any recent efforts to portray it otherwise, and that's a task which has been thoroughly taken over by JSON in the last few years.

> If you want a language with a JSON-like syntax, consider using JavaScript.

You're probably right in making this joke though, since JSON is based on JavaScript it certainly owes its popularity mostly to the browser environment.

"it certainly owes its popularity mostly to the browser environment"

I don't think that's a given. JSON is useful because it provides a clear, compact syntax for the most commonly useful data structures - lists, dicts, strings, numbers and booleans. That's certainly why I switched to it over XML (and serialised PHP objects).

Luckily, embedding more useful languages like Lua, Python or Scheme is becoming more and more common.

Dear God.

Why not just... use a scripting language?

I hear LUI is pretty popular as a DSN these days.

'Cause I didn't write it, I just work here. :)

These XML vs JSON talks are tiring. They solve entirely different problem domains. XML is for documents and JSON is for data. It is not the fault of the XML spec that programmers go nutso on its usage outside of its problem domain.

I don't understand your point. Documents are data, are they not?

Documents are semi-structured data, that is they are a mix of text and structured data elements put into a structured hierarchy.

problem is in that 90% of applications does not need to process mixed-content documents, yet because XML was the new cool-and-interoperable-solution-to-everything it got to be used for anything and mainly for things that are only simple structured data. Probably because you can abuse it for that and as a bonus you get lots of tools (like XSLT)

XML's bad, JSON is better.

But Protocol Buffers are best. Like JSON, the data model for Protocol Buffers maps nicely onto simple data structures (unlike DOM). But with Protocol Buffers you also get a schema for free, a wicked efficient binary format if you want it, default values, etc.

And you can use JSON as a text format. In other words, you could take your JSON that you have sitting around, whip up a Protocol Buffers .proto file for it, and get nice generated C++ classes for it with full schema validation. Your JSON file:

    {field1="foo", field2=5}

...could be accessed from a C++ object as:

    my_obj.field1();

The only bummer about protocol buffers is that its support for high-level languages (PHP, Perl, Ruby, etc) is not very good. I've been working on a separate implementation of Protocol Buffers in C to address this (by making it easy to write bindings for) but this project has unfortunately been stalled as I've been busy with work and life. :(

What is it the tool that generates C++ codecs for JSON from .proto specifications?

(I wrote a generic command-line Protobuf-JSON converter).

Hmm, I just looked and apparently this code isn't part of the open-source protobuf release. :( This code exists inside Google, but apparently hasn't been disentangled from the rest of the Google source tree to be released outside.

The protobuf encoding carries a ton of redundant crap around (if not as much as text formats). You can do a lot better by paying more attention to the schema and omitting facts that aren't allowed to change, like tags on self-delimiting required fields and arrays (ASN.1 PER does this well).

The protobuf tradeoffs only make any sense if you think you can somehow do something useful with messages that are somewhat but not entirely corrupted, because you still have to solve the problem of finding intact field boundaries without being given any HDLC-style framing.

> The protobuf encoding carries a ton of redundant crap around (if not as much as text formats).

[citation needed]

One of the features of protocol buffers is that they're backwards and forwards compatible. You can add and remove fields, change "required" to "optional" and back again, and still make sense of what comes to you on the wire. I don't think there's much of anything that can be eliminated from the protobuf binary format.

Eliminating tags for a field (even if you consider it required) wouldn't be backward compatible with a previous version of the protocol that considered it optional.

A message from a previous version of the schema is not "corrupted." Being able to make wire-compatible changes to the protocol is an extremely important feature.

You can't add or remove required fields, because outdated recipients will be dangerously wrong about whether they understand the intent of a message in the revised format. At some point meeting new requirements and keeping interoperability calls for deprecating and replacing the old format, because treating everything as optional (which some Googlers apparently do, avoiding "required" completely) is almost as bad as having 2^n mostly-untested formats.

This is the kind of over-engineering analysis that leads to overly complicated systems like XML schema.

Just because a field says "optional" doesn't mean it's logically optional. You don't have to make your schema formalism complex enough that it can describe every last rule of what it takes for a message to be valid. In fact you definitely don't want to do that, because it's a horrible amount of complexity in the schema for little gain.

Yes, it's true that some Googlers use "optional" instead of "required" everywhere in their .proto files. That doesn't mean that you can omit any field and expect your message to be processed by your peer without error. It just means that you won't get an error at the schema validation level. But the application could still throw an error. More complex rules about what fields must be specified or what values they must have can be described in comments, and enforced with custom validation if necessary.

Also, since protobufs support default values, you can define what value will be returned for scalar fields if no value is explicitly sent. This can often be used to define useful default behavior for the case where a field is omitted.

It comes down to different design choices. Any constraints that are missing from the schema have to be recreated separately in each implementation, and I see them as unlikely to do that consistently enough to interoperate well. So I prefer not to pay at runtime for expressing many variations of the protocol, when I don't expect them to work anyway. Like HTML vs. XHTML—I shudder to think how much work was wasted trying to handle the worst tag soup imaginable, simply for lack of a well-formedness (or DTD validity) requirement.

> Any constraints that are missing from the schema have to be recreated separately in each implementation

Not true at all. The server can implement them -- once -- and any client who makes an invalid request to the server will get an error message. These constraints can be expressed in comments in the interface (.proto) file.

> Like HTML vs. XHTML—I shudder to think how much work was wasted trying to handle the worst tag soup imaginable, simply for lack of a well-formedness (or DTD validity) requirement.

HTML and XHTML is a completely different ball of wax. Insisting on even well-formedness is simply unreasonable in practice, because it is so difficult to ensure, and it is the user who pays the price when the software isn't perfect.

If you're still convinced that the world would have been better if strict XHTML had won, you should read: http://diveintomark.org/archives/2004/01/14/thought_experime...

ASN.1 does not map well to any meaningful and generic in-memory representation (I tried to do that in dfsch's BER/DER module and failed spectacularly), while JSON does, but modifing BER to be efficient json-like representation is not that complex, basic idea is to large extent similar. And as for efficiency and ease of use, if you want efficient dataformat with fixed schema, XDR is certainly better than PER (and free of ASN.1's design-by-comitee nonsense)

I/O is relatively so expensive now that deserializing packed fields is more efficient than transmitting enough padding to make them usable in-place. Some people claim they can do compression and come out ahead on the reduction in sends and recvs and copies.

My take on efficiency of serialisation is more concerned with resulting data size, not actual coding/decoding processing overhead. ASN.1 encodings are mostly concerned about size and not about direct usability of encodings (both PER and BER actually use UTF-8 like encodings for various values, PER even does not align fields to byte boundaries).

And as for compression: dfsch's binary serialization format does some de-facto dictionary compression on some fields and it actually speeds up decoding itself (decoder caches various high-level metadata in decompressor's dictionaries), not only reduces I/O size.

The lack of a standard for handling namespaces is a fatal flaw in JSON for many applications. Some of the healthcare data exchange formats we deal with require mixing multiple XML namespaces together; it's complex, but it works. Trying to do the same in JSON would be a huge mess. http://blogs.sun.com/bblfish/entry/the_limitations_of_json

IMO the biggest advantage of JSON on the web is a simple one: fewer bytes on the wire.

EDIT: also the concise yet all-encompassing nature of its home at http://www.json.org

Is this really true? It seems like they would be remarkably close in number of bytes on the wire, accept in cases where you generate really poor XML. In fact, in some basic examples I quickly looked at, I think XML actually puts fewer bytes on the wire.

I do have to agree with the author though. This feels like a really "meh" discussions.

If the actual data is small compared to the tag names, then XML will be significantly larger.

Also if the data scheme is very simple and only for consumption by the person who designed it, one can eschew tag names altogether and just have an array and rely of the order of elements to define meaning.

And I'm looking forward to a real world example of 'width' where JSON fails and XML shines.

I have the same reaction as the author, although for perhaps a slightly different reason. XML has far less syntax than JSON, and strings are the default input. So XML is better when you have large chunks of text want to add structure and meaning to abstract subcomponents, and want it to be human-readable. JSON is better when you need to organize lots of little pieces of data.

Unfortunately, neither use case is typical. Usually it's a mix of both, and it's not worth using both formats so you have to pick just one.

I spend all my time doing front-end development and I'm not sure what the author means by "I look forward to seeing what the JSON folks do when they are asked to develop richer APIs". The only deliberately unstructured XML I've worked with is document formats. Where are these rich unstructured APIs that wouldn't otherwise be classified as lazy?

I'm no expert on these things...

But generally what I want out of a data stream is a set of name/value pairs. That's it. I really don't understand why, but trying to get those name/value pairs from an xml based api is always an adventure. Well - I know why. It's because everyone structures their data differently when they create xml. Sometimes the name I'm after will be a node name. Sometimes it will be a value of a text node. Sometime the value that properly maps to that name will be a textnode 3 layers deep, sometimes it will be an attribute value.

I'm still a newb but I've worked with about 8 different apis now. For the json apis I wrote one recursive function that worked on all of them to get the data I wanted... It was about 8 lines of code. For the XML apis, I STILL haven't figured out how to write a recursive function which works for ONE of them, let alone all of them. (while relying on python minidom to do the actual parsing for me).

I remember when XML was still young and I was introduced to XML-RPC. It was truly beautiful protocol -- straight forward, human readable, human writable, and easy to implement. I wrote desktop apps that connected to web services written in different languages on different platforms and it all worked.

Then SOAP happened. The same philosophy as XML-RPC gone horribly wrong: a human readable format no longer readable by humans, insanely complex, and hard to implement properly (even with the libraries). Frustrating all around.

Although JSON is much simpler than XML, there's no reason why someone couldn't invent something as horrible as SOAP (or XSLT) on top of it. I can only hope that JSON implementers see the value of keeping things simple. Perhaps the existence of XML as an "enterprise" technology will help differentiate JSON in that way.

I used xmlrpc for this exact purpose (desktop to 'web service' - now there's a buzzword I haven;t heard in 5 years!) early this year, it was awesome. On the server side I had PHP's simple xml api, which also made pretty much all of the pain of parsing xml go away.

JSON falls flat when trying to define data types and serialize objects.

  var foo1 = new Foo1();
  foo1.bar1 = new Bar1();
  var foo2 = new Foo2();
  foo2.bar2 = new Bar2();

If you were to serialize that data using XML you might do this:

  <Foo1 name="foo1">
    <Bar1 name="bar1"/>
  </Foo1>
  <Foo2 name="foo2">
    <Bar2 name="bar2"/>
  </Foo2>

But now what if you use JSON? You'll probably end up with something like this:

  {
    "foo1" : {
      "class" : "Foo1",
       "@bar1" : {"class":"Bar1"}
     },
    "foo2" : {
      "class" : "Foo2",
      "@bar2" : {"class":"Bar2"}
    }
  }

Generally it makes sense to use XML for imperative data structures, and use JSON for functional data structures.

I don't see what you're getting at. First of all, how is example 1 better than example 2? And how does that prove that JSON is better for functional data while XML is better for imperative data?

It boils down to JSON being schemaless. In XML the data type is implicitly defined by the tag, whereas in JSON you need to arbitrarily encode the datatype as a property and somehow differentiate between properties and child elements/objects.

How about this?

    <Foo1 name="foo1">
        <Bar1 name="bar1"/>
    </Foo1>
    <Foo2 name="foo2">
        <Bar2 name="bar2"/>
    </Foo2>


    [["Foo1", {"name" : "foo1"}, [
        ["Bar1", {"name" : "bar1" }]
     ],
     ["Foo2", {"name" : "foo2"}, [
        ["Bar2", {"name" : "bar2" }]
     ]]

I personally wouldn't do this, but the arbitrary encodings between the two samples are now equivalent.

No, I think you proved my point.

I still don't understand. What makes the XML version better than the JSON version? Why is creating XML like that a good solution, while creating JSON like that is not?

The XML is better because when the data types directly relate to tag names it is simple to understand, read, and write, process, and there are tons of XML libraries in every language that do object-xml serialization automatically. With JSON, since there are no types, you must manually write your own data-object serialization and embed the type system right into the data structure itself.

It sounds like that might be better for a statically-typed language where you might need specific types in the data file. But I would argue that not only is it overkill in a dynamically-typed language, it's bad. We're talking about data here. There's no reason to couple it to data types in your code.

Plus, serialization to JSON in a dynamically-typed language is pretty much automagic compared to what you have to do with XML.

In various conversations on the internet, starting with comp.text.sgml where XML was born in the 1990s, I have seen many signs that someone hopes or expects some of the immense richness in meaning that humans assign to words and other symbols to be carried along by the XML.

In other words, I've seen many special cases of the mistaken belief that programmers of today can do things that only researchers of the future wielding human-level AI will be able to do -- and that just has to cause grief if those hopes and expectations inform IT decisions.

I am a huge JSON fan, but I have still managed to find a few cases where I can make use of XML - the mixed-mode situations the author describes.

To generalize my viewpoint: XML is a good way to mix data and data processing, or mash up multiple DSLs in polyglot fashion. When stream-parsed, one can imagine great use-cases of XML, where an early node adds context, references and functionality for other data later in the document. But it sucks for plain old standalone-structured data, which is the kind of data we usually like to _store_.

I think they shouldn't be mixed. JSON has its strong attributes as also does XML. I started working with XML on 1999 and started doing AJAX style web applications on that time using XML/XSL and Internet Explorer XMLHttpRequest. So now we have JSON, good, excellent addition. Is fast and simple to implement.

But to deprecate XML, I don't think so. Imagine just an EDIFACT document in JSON?

I find XML to be too heavy and complicated for an interchange format.

Quote: "any damn fool could write a better data interchange format than XML"

There are hilariously terrible protocol designers out there, and too often nobody with taste manages to stop them. The EDI standards are often cited as examples of how much worse than XML it could get.

http://en.wikipedia.org/wiki/EDIFACT#Example

an example would be useful

one good property of xml is that it's also a database. it can be queried once inside, say, postgresql's xml type.

json lacks that level of support from mainstream relational databases, which makes it a waste of time for certain use-cases.

http://wiki.postgresql.org/wiki/JSON_datatype_GSoC_2010

XML just gives me a headache.

I just like to point out that there was a time before XML. Fixed width formats are still very common when working with mainframe systems. Surprisingly, they aren't actually that bad to work with.

I agree XML has it's uses, but I would go for JSON first, XML somewhere after JSON. Any day.

I still love JSON, http://ilovejson.com for it's readability and simplicity.

I remember a while ago I read a submission on HN (or reddit?) talking that a founder of jabber protocol is ditching XML for something new. Anyone remember?

How about SXML?

http://okmij.org/ftp/Scheme/SXML.html

FWIW, if you change "unstructured" to "semi-structured" then Norm's argument works much better.

Reply on news.ycombinator.com