FBML, YML, OSML oh my! HTML, meet Social

This morning Yahoo! launched the first fourteen OpenSocial applications for users of My Yahoo!, though as TechCrunch pointed out they did a bit of forking OpenSocial for their HTML-ish markup. It’s not all that surprising considering that OpenSocial’s support for this sort of markup (OSML) is relatively new, Yahoo! has been working on their application platform for quite awhile and OSML is just a bit strange.

For instance, the “small view” (i.e. the widgets which actually appear on the MyYahoo page) must be developed using “Yahoo! Markup Language” (YML), which is an extension of HTML with more bells and whistles. Yahoo is trying to bring together YML and the OpenSocial Markup Language (OSML), but right now they are forked. But turning an OpenSocial app into one that works inside Yahoo is getting easier.

Beware, the next few paragraphs get a bit geeky. YML (more info) is a lot like FBML and OSML (more info) in that they are all social markup languages. OSML is a bit different though, unlike YML which only works inside of Yahoo! and FBML in Facebook, OSML is part of the OpenSocial project and is designed to work inside of many different social network containers. If I wanted to display a user’s name inside of my application, here’s what it would look like:

  • FBML: <fb:name uid=”4″ />
  • YML: <yml:name uid=”QPR12345″ />
  • OSML: <os:Name person=”${User}”/>

In this simple example, FBML and YML are nearly identical; you pass in a userid. OSML is a bit different, they’ve created a rich templating language and you’re passing in a user object instead of just a userid.

XFBML is the evolution of FBML but designed for use via Facebook Connect. Given that XFBML is designed to work for sites outside of Facebook.com, I’m much more interested in the ideas behind it and how they will ultimately be useful across social networks. Today XFBML is powered by JavaScript, though in the future I can imagine having actual HTML tags for this sort of social content. One of the large benefits of this approach is that a user’s privacy settings can be maintained easily across sites (see Thoughts on dynamic privacy, though note that Chris’ closing is no longer accurate).

Today XFBML works in such a way that I include Facebook’s JavaScript loader in my page, the JavaScript walks the page’s DOM looking for tags like <fb:profile-pic uid=”4″ />, uses your browser (and thus your current cookied session) to request the user’s photo, and then based on the user’s privacy settings and your relationship to the user fills in their photo (or doesn’t). This provides two main benefits: 1) if you only share your photo with your friends, a non-friend browsing this page would not see the photo and 2) if you change your photo on Facebook it will change on this page as well.

Given how quickly the Social Web is coming together, I believe that HTML will need to support social elements someday soon. It’s great to see this type of innovation by Facebook running in the wild, but the web itself ultimately evolves best when multiple competing approaches come together. Just as OAuth brought together the best practices from AOL, Flickr, Google, Yahoo! and others, there is a similar opportunity to bring together FBML, YML and OSML along with the client-side benefits of XFBML.

tags: ,
  • +1.
    FBML and YML appear to be NVP (Name Value Pairs) that ought to follow a common syntax — no need for the FB or Y prefix — that’s headed down the proprietary road.

    OSML shouldn’t need the ‘os:’ prefix either if there were common agreement on a standard for passing these values. And passing the object tag is preferable to passing the actual value argument — the UID is more private (as it should be).

    From the pov of the ML generator, general is better, more portable, less proprietary, etc. Getting agreement for all parsers lowers the barrier to data portability.

    Reviewing history, this is natural evolution. Each pioneer does it their own way until the spec is widely adopted.

    Open Social can do a great service by promoting the most company-neutral stance possible. Let’s get the std APIs right to relieve every website from dealing with umpteen variants that just promote satellite behavior orbiting around just FB, or just Y, or just M$. Or the dreaded forks with special behavior for each. Such actions slow down data portability.

    Wither XDI?

  • Let’s not leave Microsoft out of this mix: http://msdn.microsoft.com/en-us/library/dd570152.aspx

    This is getting ridiculous. I’d love to work on a way to bring it all together.

  • They should work together … some more features at html would be really cool.

  • I´m using html-only, so more features would be really great. Lets wait for next years.

  • sunny

    check out http://www.friendlane.com
    the guys behind it working hard to be big.

  • roger alex

    Today a saw the link of friendlane..i see the guys are good at design and why u people don’t make friendlane Markup Language..You also friendlane ID FLID and gamelane like thing..It’s a new idea you havesome where developed a good communication system.I read todaY on http://www.friendlane.com/creators.html the guys behind the friendlane.com are just baby engineering students.keep working buddies .

  • Michael Vreeken

    So it’s time to develop own markup language ? I’m just curious when Google will develop it’s own :)
    BTW If you are looking for a nice FBML code you can check http://facebook-templates.net/
    this is something you can use with ease.