Is RSS What XML Was Supposed To Be?

As I watch the whole RSS explosion unfold, I can’t help but wonder if RSS will materialize into a more popular information payload mechanism than XML.  It’s simple, and more importantly, it’s definition is far more narrow than XML.

We all know XML can do a lot of different things – transform information, represent remote procedure calls, etc. – but over time, RSS is going to become far more than just a way to get news feeds.

Take a look at how Yahoo decided to handle their REST-based maps API. It’s based on extension of RSS called GeoRSS. So how does it work? You simply pass in an RSS 2.0 file enriched with some geographical information (zip codes, latitude and longitude, etc.) and Yahoo hands back a nicely plotted map.

So why did Yahoo use RSS here?  Well, I’m sure the team at Yahoo want people to understand and adopt their services as quickly as possible. What better way to do that than to leverage a popular and widely-understood standard. The alternative would have been to create their own home-grown XML format. This would leave developers with the unenviable task of wading through documentation, studying schemas, etc.

Of course, RSS isn’t for everything. Some payloads are simply too complex for it. Nevertheless, it’s becoming clear that one of the strengths of XML, it’s incredible versatility, is also one of its drawbacks. RSS isn’t as versatile but because it is narrowly defined, the learning curve is far less steep.

You can find a whole slew of creative uses of RSS (via extensions) at the RSS Extensions Wiki.

6 Comments Is RSS What XML Was Supposed To Be?

  1. Jay

    Bryan,
    Technically yes, RSS is XML. But thats not
    the point. The point to understand here is
    what XML was meant to achieve: frictionless
    interoperability between disparate systems.
    The problem here is that both of these systems
    need to agree to a common Schema.
    What RSS has achieved is an wide scale agreement
    on a schema. Yes it is basic, but who cares.
    Sockets and TCP/IP existed before HTTP. But
    when Web Servers and Browsers started using
    HTTP “GETS”, “POSTS”, and simple URLs, the
    Internet Revolution began.
    RSS is just delivering on the promise of XML,
    and it is doing it faster…

    Reply
  2. Bryan F. Hogan

    “The problem here is that both of these systems
    need to agree to a common Schema”
    RSS is specific to certain uses. XML allows you to build what you need. XML created RSS; RSS has to follow XML rules. RSS can’t be used for every need, which is why XML allows you to create other schemas. XML is the delivery format to create whatever schema you need. XML should not be narrowed to only allow for the schema that RSS has created for itself. Than XML would be useless outside of the areas that the RSS schema is good at.
    Not everything can be packaged up into RSS just because it is easier for them to understand it’s schema than another that was created by XML.
    You’re putting a designers perspective on a fundamentally developers technology. XML is being used far more widely and successfully on the server side than it is the client side. And not all those schemas that people have created can be packaged up into RSS. RSS is 1% of what it needs to be to do what your talking about. Yes other things can be shoved into RSS but you’re narrowing the scope way too much.
    Take UPS’s webservice for shipment creation, there are at least 100 different nodes that can be used to generate a shipment. That means there are close to that many different shipping variables.
    What you’re saying is that because these 100 nodes don’t exist in the RSS schema than it shouldn’t be used. You’re saying it shouldn’t be used because you want to limit XML to only allow the RSS dialect.
    Points being if you limit XML to only allow RSS than you are going back in time and not ahead.
    I don’t know you and I don’t know where you are coming from other than what I get out of what you’re writing, but in this case I feel you don’t have a true understanding of the consequences of what you’re saying.

    Reply
  3. Bryan F. Hogan

    Also, if you were to extend RSS to include other nodes to allow for the shipping variables. Than your making RSS not RSS any more. To make RSS work for all needs that it wouldn’t be Really Simple would it? What would it be? It would be XML and you can call it whatever you want. But it will always be XML.
    Anyways, I’m sure this is going to open a slew of comments from others like yourself and if I don’t reply it is because I don’t have the energy to explain anymore.
    You should look into what your asking further.

    Reply
  4. Jay

    My comments weren’t to imply that “RSS is the hammer and everything is a nail”. Also, I didn’t intend to say that RSS is technically superior to Generic XML.
    Mine is a more philosophical argument about how technologies reach a tipping point and get adapted into the mainstream.
    The simplicity of RSS allowed people to “get it” quickly. It is delivering on the promise of interoperating systems with little to no apriori knowledge of a custom XML Schema.
    In your UPS example, yes using RSS is suboptimal. Adding custom tags to cover the 100 variables doesn’t make it RSS anymore.
    But that isn’t going to stop someone from trying. And that is the point. The masses adapt technologies that are comfortable to them, and then they build on them.
    I am a trained computer scienist from MIT. Strictly speaking, mangling RSS to do what XML does elegantly is frustrating. But everyone isn’t a geek and people don’t do the most elegant things. People gravitate to what is easiest to grasp and build upon that.
    This trend is a mix of technology, marketing, and perception. It is this mix that leads to disruptive innovation. And recognizing that it is a mix is the key.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>