Symphony.

@jonasd regarding that hackers post here - It is slightly concerning that just about every posts strongly advises not to learn XSLT when I’m just learning myself!

Do you think the majority of the people who say this are developers in much more common and widely used languages (which I’m not), so should not be put off by the comments? Saying that, I’ve still not found a CMS that does things how Symphony does (I don’t want to be spoon fed, or have predefined content!) regardless of template language, and I’m getting along fine with XSLT currently!

Do you think the majority of the people who say this are developers in much more common and widely used languages

Tough to say, of course, without knowing each of them individually, but that’s the impression I get.

The thing is, though, that we’re really not talking apples to apples here. XSLT is not just one other templating language to consider alongside Smarty or Jinja or Twig or whatever. In many ways it’s a completely different paradigm for how a presentation layer can/should work. And I think what you get a lot of the time is people who take a cursory look at XSLT and say, “Well the syntax seems cumbersome compared to simple tags like {% title %}” or “XSLT transformations aren’t as performant as simply parsing mixed HTML templates for tags in PHP.” But most of the power of XSLT is actually unique to the way XSLT functions. So someone who’s used to another templating language is almost certain to overlook those things because there’s simply no point of reference.

This whole discussion seems a bit strange to me. If Facebook prefers JSON over XML, this may have lots of reasons, one of them being bandwidth. But another reason might be that they actually don’t want to be too “verbose”.

The other day I built something like a “Facebook Wall” for a client, and I realized that their RSS feeds are not even valid XML — hey, don’t tell me that they don’t know this! Is it because they don’t want people to parse the contents? I think so. They want web masters to use their JavaScript API and “widgets” in order to push Cookies and track everybody (even people who are not registered) and make money using personal data and profiles. This is what Facebook is about, isn’t it?

So, regarding Facebook, this is not a technical discussion at all. It’s about “marketing” and “politics” and “return on investment” and all this stuff.

My technical understanding is: XML is more verbose, but at the same it is more serious and universal. I will never leave it for JSON, nor will I ever leave XSLT for any strange hand-made templating language. JSON may be cool if you are coding in JavaScript, but XML is cool if you are doing anything else.

So if you want to go with the flow, do it. But don’t try and change Symphony’s heartbeat. JSON may be a nice addition to your technology pool. And maybe you will even see a good reason to use it — some day. That’s it.

@Craig: that is a great analysis. I’m going to follow up with a separate forum post that might help us…

@michael-e: I have to respectfully disagree. I’m not at all suggesting that we should ditch XML or XSLT or any of that, but at a minimum we need to be cognizant of the changing API landscape — given that external API integration is one of the best things Symphony does. I’m currently having to use JSON-to-XML proxy scripts because several APIs I need don’t offer XML, but that’s a problem with a pretty easy solution.

Symphony needs more “data transport formats” or “data input formats”.

Be it JSON, SOAP, AMF even. Not because one format is better than another format, but because it’s a fact of life that different formats are used in the real world, and we want to use them. This has nothing to do with the inner workings of Symphony IMHO.

I agree with Zimmen, but personally I also agree with Michael… It’s my opinion that JSON should really only be used for shifting data about in the frontend, after all its JavaScript, and that’s what JavaScript is for. It’s a trend at the moment, which I don’t like personally. I stumbled across XML & XSLT due to a job requirement, but very quickly loved what it can do. It’ll be a long time before I decide to switch to something else. It just seems to make sense to me.

Twitter, Facebook, all the others that are dropping XML? I think you’re being very shortsighted to cut off a data transport technology, just to fit a current trend.

My preference, too, would be that XML sticks around, and content providers offer both. But for services like Twitter where real-time streams and bandwidth are huge considerations, I can see why they’d go with the lighter of the options. (They also aren’t having to deal with advanced features that XML handles well, like namespaces, etc.)

For @designermonkey and all who enjoy the XSLT approach, help us tell the story!

I think we need to watch out for being too idealistic. The first wave of XML proponents fell into that trap, and next thing you know you’ve got XHTML2.

I see Symphonians as generally in the (very early) second wave of XML proponents. We need to focus on the pragmatic advantages of XML over alternative document/serialization formats. To me, these include:

• Verbose enough to represent data received in most any other format
• Solid, extensible validation
• Singularly capable of handling highly semantic data

I think the last point is most crucial, since that is where json is going to eventually fail. IMHO, the sooner we capitalize on that, the better.

Here’s an interesting article, Why XML is far superior to JSON.

Another one, Web Reflection: Template Engine - Why Bother? XML + XSLT.