Symphony.

Hi Guys,

While looking into Symphony I met quite a few people from the ‘XML/XLS-sucks’ camp. I am a front-end developer and am not really opinionated on this (although I do ‘believe’ HTML5 > XHTML(2)).

Anyway, the main reason for this discussion is a post on Programmable Web that implies Twitter is moving away from its XML API altogether, favouring JSON. This indeed seems to be a trend: JSON over XML (and I do see why…).

There’s currently a strong interest in simple JSON API’s and Javascript webapps (+ node.js etc.) and I think this will only grow stronger. What do you think are the ramifications for Symphony CMS?

Practically: will that ‘selling point’ of Symphony (“It’s XML! Easily integrate with existing API’s”) become less relevant and maybe even counter-effective? Will people think of XML/XSL as ‘archaïc technology’ and disregard Symphony because of this?

Again, I have too little understanding of the issues to be able to properly asses them but I am interested to hear what the Symphony community thinks.

Here’s my experience and thinking:

1. JSON is smaller, and lighter than XML. But it’s not as strict, and at present you’ll find just about every implementation of JSON is slightly screwed in some fashion. It’s usable, but you’ll spend more than half your time battling inappropriate MIME types and malformed structures;
2. XML’s been the de-facto standard for encapsulated data transfer for years. It’s not going anywhere, and it’s reliable.

I think the Symphony team needs to think about what it means to be able to talk to non-XML datasources out of the box (and there has been discussion/thinking already), but many of us are talking to JSON datasources right now (my FAQ and Support pages are drawn from TenderApp’s JSON feed into Symphony data sources). It’s certainly been discussed a few times, but in my opinion it’s not really an obstacle so it doesn’t get too much attention. PHP supports parsing a certain type of formatted JSON back into native PHP object, so you can just pass that back through to XML via PHP if you want it in Symphony natively. It’s just another data interchange format.

XML/XSLT is not archaic, it’s just not new. There’s a subset of the tech world that’s disinterested in technology that wasn’t introduced in the last 6 months, but I’d hazard a guess and say they’re not making a whole lot of money (getting clients to pay for experimental tech earns you a special place in the salesperson hall of fame). Hell, Ruby on Rails is “old” now. It doesn’t mean it’s not a great tool for the things it’s good at - same goes for XML/XSLT.

If you’re picking your technology purely based upon it’s (lack of) age, you really are doing it wrong.

</informed-rant>

XML/XSLT is not archaic, it’s just not new.

I’m with you on that one. JSON may be the new kid in town, but XSLT is still a dream templating language. Other frameworks employ their own templating systems (EE, Textpattern and Wordpress tags, RoR has various implementations) which are all equally archaic and/or non-standards.

Symphony 3 abstracts Data Sources to a level such that developers can provide new DS “types”, so providing a JSON Data Source (to read a JSON feed and convert to XML for use in templating) will be something of a core-supported feature.

The rise of JSON (particularly with Twitter and Facebook) has been coupled with the rise in heavy use of JavaScript. If you’re sending data directly to the client to be consumed by JavaScript then JSON makes sense (it’s lighter and requires less parsing client side since it’s a native JS object). But if you’re communicating between two systems (when JavaScript isn’t part of the equation) then XML is still the most solid choice.

EDIT Thanks Nick, your comment came through while I edited mine.

Tony thanks, I agree. My point is probably more one of ‘marketing’.

But, although I agree with everything you say, adoption of- and enthusiasm about Symphony will depend on things like ‘hype’, ‘sexy-ness’ etc. This is simply an observation: look at how many people took a closer look at Symphony because getsymphony.com website looks hot…

I am just wondering if communicating XML/XSL as a strong selling point is going to convince less people to even take a look. One of the strongest points for me personally was the ‘Symphony philosophy’… The XML/XSL part was more of a stumbling block really (although now I see more benefits of XSL ‘templating’ etc.)

Also, it might be beneficial to start writing more documentation about working with other data interchange formats (“You can easily work with JSON in Symphony!”).

Just some thoughts, thanks for reacting.

I also think, as has been mentioned, that Symphony should probably have core-support for JSON datasources (point-and-click integration with external data sources is gold). It would also be nice to enable output from pages as JSON as well in an easy fashion.

But XML+XSLT as the core data format and templating language is a big thing for me, and why I instantly clicked with Symphony. I’m a bit biased though since I’ve created a webapp framework which does the same thing (by default). I think there’s tons of selling points regarding XSLT as the templating language. People ignoring Symphony because “XML is verbose, thus XSLT is crap” can go f*** themselves in my opinion, they’ve already made up their minds based on lack of experience with XSLT as a templating language (again, my opinion) ;) I recently used Django for a project and couldn’t for the life of me become friends with it’s templating language (though lack of experience on my part may have made things harder of course).

On the other hand, there is of course a lot of other things that Symphony excels at and which should be shouted from the top of every mountain, hillside and soap box. But the trend for APIs to return JSON instead of XML is a natural process given JavaScripts popularity and quite a different thing than what format Symphony should use for it’s templates.

I also think, as has been mentioned, that Symphony should probably have core-support for JSON datasources.

In Symphony 3, every possible DS type will be an extension. JSON will just be another one. But yes, I agree, fetching and transposing JSON to XML is a handy feature.

It would also be nice to enable output from pages as JSON as well in an easy fashion.

That can be done easily in XSLT.

Merry christmas. ;-)

Haha! Of course someone in the Symphony community has written an XSLT utility for JSON output already. Thanks for the link phoque :)

But if you’re communicating between two systems (when JavaScript isn’t part of the equation) then XML is still the most solid choice.

The relative efficiency and the friendliness of json APIs make many people choose it over XML, from what I see, primarily when sending to the browser. I’ve always wondered how stable javascript-based XSLT is, since caching a single XSLT for your entire Ajax app has to be efficient compared to whatever you’d need to do with json.

Generally, I think once APIs need/want to start sending semantically-rich data, the simplicity of json will not be sufficient, and XML will return as a useful and well-supported transport format.

Here is an interesting article about XML vs. JSON.

XML wasn’t designed to solve the problem of transmitting structured bundles of atomic values. XML was designed to solve the problem of unstructured data. In a word or two: mixed content. ¶

[…]

I predict there will come a day when someone wants to federate JSON data across several application domains. I wonder, when they discover that the key “width” means different things to different constituencies, will they invent namespaces too? ¶

I was momentarily spooked about this, but then I realized that even if XML fell completely out of favor as an interchange format, we would still be in no worse shape than any other CMS with its own custom templating language. Ours would just happen to utilize a decent standard!

The bigger concern, IMO, is the further development of XSLT and PHP’s support of XSLT. Not to mention the perception that XSLT is a pile of stink. (See this hacker news post)

Not to mention the perception that XSLT is a pile of stink.

If you’re procedural programmer accustomed to templating systems that are implemented with a mix of direct output and custom procedural code, then, yes, XSLT must seem like a pile of stink. CSS probably seemed like a pile of stink too in the early days of WYSIWYGs…

Yep. I happen to think XSLT is a pile of awesome. But there does seem to be some negative sentiment out there.

As most things, people tend to think in “piles of stink” when they do not fully understand something, or, as happens more often than we would wish for, they follow the opinion of certain verbally skilled people that, in turn, do not fully understand the thing at hand.

XML / XSL has “1995” written all over it, therefor it is not in the top 10 sexy things and, consequently, it is classified as “a pile of stink”. Reasoning like this we should name XHR as a “pile of stink” as well being technology from 1997, first used in IE4.

I do agree that transport of data could be done in less verbose formats but for the internal workings XML/XSL is what makes Symphony a better CMS than any other CMS i have ever seen (and that’s a lot of CMS’es)

@Zimmen: agreed, but a widespread negative perception of XSLT could prove to be a barrier for Symphony’s growth. If most developers think XSLT is outdated, painful, or not worth learning, they won’t want to try Symphony.

We can make the argument that these people don’t know what they’re talking about, so it’s fine if they decide not to try Symphony — but this is rather short-sighted. We have to promote why XSLT is not only not bad, but actually quite beneficial. (And there are some forthcoming efforts from the Symphony team to do this.)

Jonasd: exactly! My point/question was also in context of the fact that I personally have spoken with a couple of developer friends that were quite convinced xslt sucks. Maybe they do not properly understand it, or are misinformed, but I do value their judgement and it was one of the reasons that kept me personally from trying out Symphony for some time…

It would be a very good idea, IMHO, to have some XSLT guru’s (symphony users) explain some of the pros of XSLT versus e.g. Another templating system…

It would be great to have a series of blog post related to this topic. Here on this site and on our personal blogs or websites.

The other thing about this — and some might disagree with me — is that XSLT is but one piece of the brilliant things that make up Symphony, and I think it’s far from the most important piece. It’s simply a means to an end. I didn’t find it much harder to use than PHPtemplate or EE tags, or whatever other crap you usually have to go through to make CMS templates.

Personally, I have zero attachment to XSLT, it’s just the most obvious way to turn XML into useful output. Rather, what I find incredibly useful about Symphony is the concept of the data layer between the HTML (or whatever format) frontend and the PHP backend.

@jonasd: Yes, we need even those who do not (yet) understand to build a larger userbase. The best way to do this is:

1) Drive the focus away from XSL and promote the other great symphony features(aka positive spin) 2) Make XSL sexy (again) .. somehow .. and write easy to follow documentation 4) More showcases …

if you have any smart ideas I urge you to add them to Symphony Marketing/Promo Ideas :-)

Back to the initial comment: should Symphony play nicely (i.e. consume) JSON more readily?

should Symphony play nicely (i.e. consume) JSON more readily?

I think so, yes.