With so many different types of websites adopting OpenSocial it has become clear that a "one size fits all" approach isn't appropriate for the OpenSocial spec. Containers have different types of data they want to make available to clients (sometimes it's social data, sometimes it's not), and some want to expose that data via web services, while others wish to use gadgets. As such, modularity was a key goal in the OpenSocial 1.0 iteration, allowing implementers to pick and choose the elements of OpenSocial that make sense for their use cases. OpenSocial 1.0 also defines extension points so containers can add functionality not covered in the spec, but do so in a standard way, making it easier to fold such extensions back into the spec or share extensions across containers.
To accommodate the varied use cases of OpenSocial containers, OpenSocial 1.0 has been revised to include four compliance models:
- Core API Server - For containers that wish to expose data in a standard way though web services.
- Core Gadget Server - For containers that simply want to be able to render gadgets.
- Social API Server - For containers that wish to expose social data through standard web services that are consistent across containers.
- Social Gadget Server - For containers that want to render gadgets and provide them access to standard social data.
The spec itself has been reorganized along these lines as well, consolidating all data definitions into the Core Data Spec and Social Data spec, and creating a separate file for each of the four compliance models.