Eyes Above The Waves

Interesting to read that you hate XML. I haven't much looked into JSON as I have found XML to solve my problems very well. Maybe I have different problems? I'm working mostly from a document-centric position, if that makes any sense.
I have searched but not come across a balanced, impartial analysis of the two. They obviously overlap to a great degree but it seems everyone has different problems they want solved and so end up rooting for one or the other. Do you know of any articles that provide a broad and balanced look at the two, possibly including requirements for transformation abilities like XSLT?
Thanks.

There's a reason why we gave "OIT" names like "The Office of Incompetent Technicians" and even less complementary: They were officious, useless and totally sold to their private "xerox-machine" mentality.
None of us who had a run in with them or the results of same wanted to have anything to do with that part of the field afterwards.

Dude, rock on man, damn straight. If only more people thought like that...at least you do. I would also argue that most unfortunate souls who go for "IT" do it to enter corporations anyway. Money is what builds respect.

Fortunately, my Web 3.0 startup is focusing on JSONHTML.

XSLT is an unbelievably bad programming language that makes simple things tricky and complex things mind-bendingly near-impossible. Just admit that transformation means programming, pick a real language --- make it a scripting language if you want to keep pretending you're not doing "real" programming --- and break free.
Another thing that I forgot to rant about was how people advocate XML because it's "transformable". Like "CSS should be in XML syntax because then we could transform it with XSLT!" As if anyone has ever wanted to do that.

Re: mawrya,
JSON and XML are similar but really they suit different purposes -- it's not like anyone would write an office format in JSON, for example. So yes, as you're working on document-centric data then XML is probably a better fit than JSON.
But if you're just storing key:value pairs then XML would be overkill, and JSON would be better. And there is now an equivalent to XSLT... JSON-T for reformatting JSON.
I recently came across a webapp that sent JSON to the browser, which - in javascript - was reformatted into HTML. The logic was rather complex, and they'd basically rewritten their C# server-side display logic in javascript to reformat JSON into HTML. Their company policy was sync up their C# display logic in JS. Now there's a place they should have just used XML rather than JSON.
I'm going to disagree with Robert here, despite being a fellow Kiwi (in Wellington), and say that XSLT is a pretty great language, but mostly so when used with XProc or some XML pipeline language.. hopefully one that allows stages of regular code where necessary.

Errm. First of all, there are many people who say XML solves easy problems badly; and they uniformly seem to come from a programming background and be looking for a data structure serialisation format. Yeah, XML doesn’t do that very well. It was never designed for that purpose. If you come at XML from an SGML-ish document-centric perspective, you’ll find that the problems it attacks range from complex to very difficult, and that it actually solves them roughly as well as they allow. It is also pretty good at loose coupling; if you process XML correctly (ie. you avoid trying to directly map it onto data types and -structures, and rather treat it as markup), then you can avoid the fragility that’s typical of RPC-ish systems where any change in the data structure affects everyone who generates or consumes it.
Secondly, I don’t know what you’re talking about as far as XSLT is concerned. Granted, most people really don’t understand XSLT, and it took me a long time until I got it myself, because every. Single. Tutorial about them. Ever written. Is utter crap. XSLT is more misunderstood than Javascript! But if you use it well, you can express transformations in it in a 10th of the code that the same thing would take in imperative languages. My weblog lives in a single Atom feed which gets processed by XSLT, and I stay amazed that years after writing all that code, it has remained incredibly easy to add small but tricky features to it. If it were written in an imperative language, it would be much harder to maintain.
FWIW, XSLT does not have a magical monopoly on this stuff; it’s its functional match-driven tree-walk programming paradigm that yields this sort of extremely powerful and concise transforms, and in theory this paradigm could be implemented in more or less any language (and for any data structure, not just XML DOMs). It’s just that no one has actually done that, although some of the more obscure functional languages come close.
The one thing that really sucks about XSLT is the verbose syntax. Even without abandoning XML as the base grammar, it could be a lot more concise. And using XML as the base grammar is simultaneously a stroke of genius (ever heard of Lisp macros?) and at the same time utterly retarded (my hovercraft is full of angle brackets!).
XML and XSLT serve particular purposes, and they do so very, very well, as far as they go. But they are no panacea or a silver bullet to solve every single problem. If you try to use them for purposes they weren’t designed for, don’t be surprised if they break down.
And yeah, using XML as the base grammar for CSS would be retarded. Using JSON as the base grammar for CSS? Now that’s an idea I could get behind.

Rock on! Robert tells it like it is.
Now if only we could get rid of the rest of the web programming morass. HTML, CSS, XML, XSLT, and all the rest. Pity that will never happen.
Javascript can stay, obviously. Otherwise JSON wouldn't work.

Matthew - everyone with a clue these days using AJAX has given up on the XML part, and instead uses JSON, including HTML delivery. It's actually harder doing it any other way, including for HTML/XHTML DOM injection/modification.
Aristotle - You say using JSON as the base grammar for CSS would be good? Check out http://en.wikipedia.org/wiki/JavaScript_Style_Sheets - choice quote: "It now remains little more than a historical footnote, with many Web developers not even being aware of its existence". Pity.

XML wouldn't be a good grammar for CSS, but at least we'd be able to ditch CSS Selectors for XPath.

YouTube, MySpace Beebo etc were clones of earlier products.
So if you are a VC you take a look at the clones of an existing product, look at the user take up rate, then buy in.
It worked for YouTube, why not for more 'web 2.0' products.
Take myspace, remember geocities? Back in the old days before it was owned by Yahoo? Clone that = MySpace.
XML = turd. Lets go back to ini files.
Nice post though :-)
monk.e.boy

Re: Edouard,
Well, I'll take your "anyone with a clue" gibe as meaning that you don't yet have a cogent argument against the scenario I mentioned. That when you're replacing text nodes or small parts of the page then JSON is a good choice, but X(HT)ML is better than putting too much display logic in JavaScript.
Now I'm not bashing either format, and obviously JSON would be a good replacement for INI files -- it's just that all data isn't INI, some is HTML or word processor files, and JSON would be a poor fit for that.

I will admit that XML is useful when you're interfacing with other XML-based systems, or XML-ish formats such as HTML.

@ Matthew - Thanks for your comments, you are confirming my muddy suspicions on where XML and JSON fit into the data puzzle. I can now think of one place in an AJAX app where I am using XML and should be using JSON, but am also beginning to understand that JSON would not cut the mustard when it comes to document data.
@ Aristotle - I have experienced the frustratingly mind-bending nature of XSLT but also have been in awe of its power on more than one occasion - the latest spec seems to be moving in the right direction, but is sure is a different world. If you ever write an XSLT tutorial, let me know! (mawrya_at_furtherNorth_net) Its always a joy to read an author who "gets it".
@ROC - Thanks for your blog, I enjoy it! And I have to agree, CSS in XML would be silly. CSS is not a "document" like an expense report or an invoice or a web page, its just a "computer file", a list key:value pairs.

Minor nitpick: Microsoft didn't avoid DCE, they actively embraced it and created an even more collosal form of corporate bloatware in the form of DCOM using DCE as a base.