Spec Changes
From OpenSocial
Contents |
All changes to the OpenSocial spec are proposed, discussed, and voted on in the spec list. Changes in the previous iteration have been archived.
Spec Process
Below is a summary of how this wiki is used in the OpenSocial spec process. For information about the spec process itself, please see the Spec Process document.
Propose and agree on timeline
The timeline for each iteration is proposed and agreed to on the spec list. The current proposed timeline is documented here on the wiki:
- Dec 21 - Post current draft with annotations around unfinished sections (RC0)
- Dec 21 - Jan 10 - Review incomplete content, complete discussions and prototypes, commit final spec patches for proposals
- Jan 5 - OS Templates conference call
- Jan 11 - Post draft with complete set of all proposals that will be in 1.0 (RC1)
- Jan 11 - Jan 17 - Review for accuracy and completeness
- Jan 18 - Post draft addressing any issues found in RC1 review (RC2)
- Jan 18-Jan 22 - Vote to accept RC2 as official 1.0 spec
- Jan 25 - Publish OpenSocial 1.0!
Scope: submit proposals and vote for inclusion
If you propose a change to the spec, be prepared the shepherd your proposal through the entire spec process. This includes...
- fostering discussion to clearly define the proposal,
- keeping the proposal's wiki page up to date with discussion on the spec list
- providing a prototype for the proposal (or finding someone who will prototype it for you)
- submitting a patch (or at least the text a patch) to the OpenSocial spec
Prposals that are orphaned by their owners may be dropped!
To propose a change to the OpenSocial spec, send an email to the spec list with [vX.X Proposal] in the subject (e.g. for example, [v1.0 Proposal]: Template improvements). Be sure to include the following:
- A description of the change
- A link to a wiki page with details
- (Optional) A diff or patch file showing the proposed modifications to the current spec
Proposals are discussed on the spec list as needed to be clarified, or modified. At this stage in the process, voting is based on whether or not a given proposal should be included in the current iteration, which means that the proposal will be prototyped in the next stage of the process. When a proposal has received the necessary votes for inclusion, the proposal's wiki page should be tagged with [[Category:Approved (vX.X)]] to indicate that it is ready to be prototyped.
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 [[Category: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 [[Category: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 [[Category: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.
Current Status At a Glance
| No patch |
| Patch under discussion |
| Patch partially submitted, still needs work |
| Patch got a -1, still under discussion |
| Patch fully committed to SVN |
| Proposal rejected or abandoned |
| Proposal | Owner | Status | Ind. CLA | Corp. CLA |
|---|---|---|---|---|
| Versioned Core Gadget Features | Tim Moore | Needs 2 more +1 votes, then we can remove the <x:draft> tags | Y | Y |
| Define EL access to meta-data about data-pipeline tag response | Chris Cole | Patch under review: [Patch 150052] thread
[Voting Thread] 5 +1 | Y | Y |
| Extensions | Mark Weitzel | Patch in progress at 154135. Proposed Thread | Y | Y |
| Complete existing basic groups support | Dave Johnson | OpenSocial should include basic groups support: ability to get a list of groups associated with a user. The REST protocol already does this. Proposal is to bring same level of group support that we see in REST protocol to JavaScript API, OSAPI and JSON-RPC. See also: [thread] and [patch] | Y | N |
| Clarify "Friend" term | Chris Schalk | Submitted (see Terminology section of OpenSocial-Specification.xml) | N | Y |
| Clarify Custom Tag Template Parameter Behavior | Chris Cole | Patch under review [Patch 151062] thread
[additional thread]: Votes: 5 +1 | Y | Y |
| | Chris Cole | Patch under review [Patch 154162] [thread] [Updated thread] [Voting thread] Votes: 5 +1 | Y | Y |
| Create Social-Gadget.xml | Lane LiaBraaten | Was "Deprecate redundant opensocial.* methods]". | Y | Y |
| Create Core-Gadget.xml | Lane LiaBraaten | Was "Add gadgets XML reference to the spec". Draft checked into svn. Needs content from feature versioning proposal and there are still some other small tasks left (see wiki page for details). | Y | Y |
| Revise the compliance section | Lane LiaBraaten | Patch available for review at http://codereview.appspot.com/156043. | Y | Y |
| Create Social-API-Server.xml | Lane LiaBraaten | Was "Condense protocol and data definitions" | Y | Y |
| Create Core-Data.xml and Social-Data.xml | Jon Weygandt | Patch ready for review at 154120. Vote on this thread. Formerly known as "Clarify Separation of Gadgets and OpenSocial in the specs". | Y | N |
| Create Core-API-Server.xml | Lane LiaBraaten | Was "Condense protocol and data definitions" | Y | Y |
| Normalize between birthday and DATE_OF_BIRTH between REST and Javascript person | Chris Cole | Patch under discussion [Patch] [discussion thread]
Votes: 5 +1 | Y | Y |
| Remove the Background section | Lane LiaBraaten | CL 144066 submitted. Final Background content will be removed by the Core-Data and Social-Data patch | Y | Y |
| Errata in v0.9 | Lane LiaBraaten | Two CLs: 143053 and 144044 | Y | Y |
| Remove Metadata and JavaScript Request from Gadget Specification | Jon Weygandt | CL: 144053 Voting passed, 6 - +1's no -1's Thread | Y | N |
| Clean Account.userid data field to match all other data on casing to userId | Chris Cole | Patch under review: [Patch 143082] Has five +1's. Including discovered data error normalizing "currentLocation" to "location" to match other objects as well, so will be left under review for a few days. [thread] | Y | Y |
| REST data "title" field normalized between Album and MediaItem | Chris Cole | Patch under review [Patch 144085] thread | Y | Y |
| Clarify case sensitivity rules for DataPipeline/ EL variables | Chris Cole | Patch under review [Patch 143063]. Currently has 5 +1's thread | Y | Y |
| os:Var variables in templates and data pipelining | Chris Cole | Update Patch [Patch 169044] and also this thread [alternate thread] Other items: OS:Var in templates Summary | Y | Y |
| Clarify JSP compatibility with Templates | Mike Samuel | a.k.a. Clarify how JSPEL on JS should behave | N | Y |
| | Jacky Wang | Patch under [code review], discussions [thread here]. | N | Y |
| Deprecate os:Render tag | Chris Cole | Patch mailed to spec list: [Patch] pending review. thread | Y | Y |
| REST data format always return data in array of "entry" objects | Chris Cole | Patch under review [Patch 150053] thread | Y | Y |
| Align response formats between REST and RPC specs | Chris Cole | Proposed thread | Y | Y |
| Reorganize the content in the spec | Lane LiaBraaten | This has been turned into several other proposal (i.e. Core-Gadgets, Social-Gadgets, Core-API-Server, Social-API-Server, Core-Data, and Social-Data) | Y | Y |
Out of scope for v1.0
| Proposal | Owner | Status | Ind. CLA | Corp. CLA |
|---|---|---|---|---|
| Cleanup of response structure in DataPipeline spec | Chris Cole | Duplicate of "Align response format between REST and RPC". Proposed thread | ... | ... |
| Deprecate DataAttribute definition of cur outside repeaters | Chris Cole | Proposed thread | ... | ... |
| | Chris Cole | Proposed thread. This has been -1 'ed due to desired future behavior and is effectively dead. | ... | ... |
| Make JSON-RPC a MUST instead of a MAY | ... | ... | ||
| OpenSocial Template Updates for v1.0 | Collecting discussions from the spec list into one place | ... | ... | |
| OSAPI Updates for v1.0 | Collecting discussions from the spec list into one place | ... | ... | |
| REST/RPC Updates for v1.0 | Collecting discussions from the spec list into one place | ... | ... | |
| Support iframe model application in gadget spec | Jacky Wang | ... | ... |
Under Consideration for 1.1
| Proposal | Owner | Status | Ind. CLA | Corp. CLA | |
|---|---|---|---|---|---|
| Incorporate Open Ajax Hub as Pub-Sub Mechanism for OpenSocial 1.next | Mark Weitzel, Han Nguyen | Assuming there are no new features in 1.0, targeting this for 1.1. We are beginning to have conversations with Open Ajax and OpenSocial teams. Cross posting on discussion lists. | Y | Y | |
| UserPrefs vs AppData | Mark Weitzel | No one has signed up yet so, for now, I'll throw my name in the hat. From an IBM perspective, we've been looking at a number of use cases around user prefs & app data and would like to help drive this work. | Y | Y | |
| XSD Validation & ATOM Mapping | Mark Weitzel | We need to determine the right extension patterns for the various OpenSocial schema. Also, there was a blog post on OpenSocial's mapping to ATOM that is worth discussing. | Y | Y | |
| Add additional lifecycle events and/or new management callbacks | Mark Weitzel | This could be the start of a "Management Extension" for OpenSocial | Y | Y | |
| Shared OAuth tokens for trusted gadgets | Mark Weitzel/Mark Halverson | ... (From EOS) | Y | Y | |
| Merge/incorporate Activity Streams into OpenSocial | Chris Schalk | ...(From EOS) | Y | Y | |
| Clarify language around OAuth in the spec | Tim Moore | ...(From EOS) | Y | Y | |
| Investigate spec changes to support inline gadgets | Mark Weitzel / Rich Manalang | ...(From EOS) This is a general requirement to satisfy the performance requirements found within enterprise settings. | Y | Y | |
| Add semantic information to relationships | Mark Weitzel / Inbal Ronen (IBM) / Ido Guy (IBM) | ... | Y/N/N | Y |
