Spec Changes


All changes to the OpenSocial spec are proposed, discussed, and voted on in the spec list.

To look at changes in the previous iterations, please look at:

Spec Process

Adding proposals to the OpenSocial specification may follow many paths, but below is the basic overview.

  1. Come up with a bright idea.
  2. Create a functioning implementation or extension (preferably in Apache Shindig) that embodies the ideas and can be evaluated by other people.
  3. Write up a page in this wiki that describes the proposal and outlines some use cases
  4. Start a discussion thread on the OpenSocial and Gadgets Spec group (link with proposal wiki page).
  5. Iterate on prototype and proposal to include community feedback
  6. Create a new Issue on OpenSocial-Resources project.  (link with proposal wiki page and in discussion thread)
  7. Add a link to the specification-scope document in svn specification-scope in svn.
  8. Modify the spec document(s) to include your proposal.  Surround all changes with <x:draft> tags.
  9. Create a patch file with svn diff and attach to the Issue
  10. Check in the changes to the spec.  Comment must include the issue number and identify proposal - ex: Issue NNN
  11. Designate that revision as the voting revision and link with the Issue.  Make an announcement on the discussion thread and link from the wiki proposal.

For information about the spec process itself, please see the Specification Process. The process for voting on proposals is here documented on the Voting on Proposals page.

Prototype proposals and vote on their specifications

Once the set of proposals for a given iteration is approved, the proposals need to be prototyped. All the wiki pages will be tagged with Needs Prototype (vX.X). If you are implementing a prototype for a proposal, you should update the proposal's wiki page with information about your prototype and add a Prototype in progress (vX.X) tag to the wiki source. Once your prototype is complete, and any necessary modifications to the spec have been discussed and incorporated into the current draft, the proposal page should be tagged with Has Prototype (vX.X).

Final review and publication

Once all proposals have been implemented and any necessary changes made to the draft specification, the community reviews the draft and conducts a final vote to promote the current draft to an official spec. At that time we'll reset this page to start focusing on the next iteration.

OpenSocial Specification Roadmap


In the interests of release predictability and transparency, here is the roadmap for current and future OpenSocial specification development.

For each major release of OpenSocial, we will publish an Implementor's Draft where all major specification changes will be incubated until such time that the community has made significant implementations of these incubating changes and provided feedback. While there is wide agreement in principal, the Community still needs to define and vote on this new process.  Once established it will be documented in the specification process.

The OpenSocial Foundation will plan for a yearly specification release cadence on the OpenSocial specification.

OpenSocial 2.5

Themes for OpenSocial 2.5

  1. Targeted cleanup and de-incubation of major changes introduced in OpenSocial 2.0
    1. Embedded Experiences
    2. Common Container
  2. Specification cleanup that does not require major editorial changes



Early April 2012

First Draft

June 2012

Final Draft

July 2012


OSCON, July 2012


List of Changes: Spec Changes - v2.5

OpenSocial 3.0

Themes for OpenSocial 3.0

  1. Full editorial review (and rewrite) of the specification
  2. Revamp of the OpenSocial REST API
  3. OpenSocial Spaces



May - Sept 2012

Call for New Features

May 12 - Jan 13

Monthly Implementer's Draft

January 2013

Release Candidate 1

February 2013

Release Candidate 2

March 2013


List of Changes: Spec Changes - v3.0

Specification Proposals

OpenSocial 2.5 Proposals

Each entry should be a link to the Feature request on OpenSocial Resources.

Specification Cleanup
  1. Broken links in spec for app id / group id (Issue 1239,Issue 1223)
  2. Inconsistencies with "-ID" and "-Id" (Issue 1244)
  3. Person service clarification / Update API (Issue 1233)
  4. Align the REST core and core API specs to wrap collection response with "list" property (Issue 1230)
  5. Fix missing ExternalService tag in gadget schema (Issue 1224)
  6. Templating Spec Issues (Issue 1243)
  7. Duplication in makeRequest (Issue 1240) (Fix osapi.http, align request parameters (FULL_HEADERS, etc))
  8. Embedded Experiences Clarification (Issue 1236)
  9. CoreGadget/DataRequest does not link to reference of acceptable values (Issue 1227)
  10. Clarify language around views (Issue 1205)
  11. Create index of APIs -> Features (Issue 1246 )
  12. Versioning Refers To The Wrong Version Of The Spec
  13. No explanation of callback function for osapi.http methods
  14. Remove in-spec references to Portable Contacts (poco draft has no official standing anywhere, hasn't been updated in several years and everything it defines is largely already covered by the OS spec) (Are we still doing this?  There has been discussion on the group about reviving the effort.)
  15. container.views.destroyElement clarification (since this is incubating, we *should* be able to do this)
Spec Changes
  1. Metadata service (Includes discovery) (Issue 1261)
  2. Common Container discussion
    1. newGadgetSite and newUrlSite methods (Issue 1235)
    2. Finalize common container spec and move it out of incubation (Issue 1248)
    3. Update common container GET_PREFERENCES interface to be async
    4. Token Refresh API
    5. Enhance open-views and CommonContainer APIs (is this a 2.5 item??)
    6. Allow openEmbeddedExperience, openGadget, and openUrl to be able to specify x,y coordinates
  3. Embedded Experiences Discussion  
    1. More precision for EE data mode& passing the entire model when EE is opened (Issue 1284)
    2. Simplify the amount of boilerplate code required to get the EE context (Issue 1249)
  4. Adding label on plural fields (Issue 1282)
  5. Additional group models: @followers/@following/@colleagues/@reports/@manager  (Issue 1281)
  6. Add Icons/Screenshots/Privacy Policy/License to gadget metadata (Issue 1283)
  7. Completion of the multipart upload work (gadgets.proxiedMultipartFormPost)
  8. Need to complete OAuth 2.0 related stuff (e.g. Issue 1201)

Candidates for Deprecation  (Issue 1275)

  1. Tabs 
  2. Skins 
  3. OpenSocial WAP Extension

OpenSocial 3.0 Proposals

This page will be used to track the proposals for OpenSocial 3.0!

Each entry should be a link to the Feature request on OpenSocial Resources

New Proposals

Spec Cleanup 

  • Simplification and Clarification of entire spec** Drop Core API Spec Document... merge it's stuff more intelligently into the other specifications
    • Provide a new Use-Case Driven Primer
  •  There are many, many more issues... See here for a small sampling... (preview)
  • Move container language from other specs into common container spec (Issue 1247) 

Candidates for Deprecation

  • Deprecate OAuth 1.0 requirements
  • Can we deprecate or at least separate the RPC protocol.. perhaps isolate it for use only with the Javascript API?
  • Can we deprecate the XML Format???  (must have replacement API incubating)
  • Deprecate media items / albums in lieu of CMIS alignment
  • Deprecate makeRequest  (must have fixed osapi API incubating)