Spec Changes - v1.0
Overview
The purpose of this page is to capture the requirements et. that went into v1.0 of the OpenSocial specification. It is a 'capture', via cut & paste, of the Spec Changes page as it was at the end of the 1.0 iteration. This page was created in preparation for the opening up of the "1.0 next" iteration process.
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
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
. 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
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
.
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
Tim Moore | Y | Y | ||
Define EL access to meta-data about data-pipeline tag response | Chris Cole | Y | Y | |
Mark Weitzel | Y | Y | ||
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 | Y | |
Chris Schalk | Submitted (see Terminology section of OpenSocial-Specification.xml) | N | Y | |
Chris Cole | Y | Y | ||
Auto-escaping of strings in EL a MAY Clarify escaping behavior of EL | Chris Cole | Y | Y | |
Lane LiaBraaten | Was "Deprecate redundant opensocial.* methods]". | Y | Y | |
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 | |
Lane LiaBraaten | Patch available for review at http://codereview.appspot.com/156043. | Y | Y | |
Lane LiaBraaten | Was "Condense protocol and data definitions" | Y | Y | |
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 | |
Lane LiaBraaten | Was "Condense protocol and data definitions" | Y | Y | |
a:Normalize between birthday and DATE_OF_BIRTH between REST and Javascript person | Chris Cole | Y | Y | |
Lane LiaBraaten | CL 144066 submitted. Final Background content will be removed by the Core-Data and Social-Data patch | Y | Y | |
Lane LiaBraaten | Y | Y | ||
Remove Metadata and JavaScript Request from Gadget Specification | Jon Weygandt | Y | N | |
Clean Account.userid data field to match all other data on casing to userId | Chris Cole | Y | Y | |
REST data "title" field normalized between Album and MediaItem | Chris Cole | Y | Y | |
Clarify case sensitivity rules for DataPipeline- EL variables | Chris Cole | Y | Y | |
Chris Cole | Y | Y | ||
Mike Samuel | a.k.a. Clarify how JSPEL on JS should behave | N | Y | |
PoCo Alignment for v1.0 (move to "Create Core-Data.xml and Social-Data.xml") | Jacky Wang | Patch under code review, discussions thread here. | N | Y |
Chris Cole | Y | Y | ||
REST data format always return data in array of "entry" objects | Chris Cole | Y | Y | |
Chris Cole | Y | Y | ||
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 |
|---|---|---|---|---|
Chris Cole | ... | ... | ||
Chris Cole | ... | ... | ||
Chris Cole | ... | ... | ||
| ... | ... | ||
| Collecting discussions from the spec list into one place | ... | ... | |
| Collecting discussions from the spec list into one place | ... | ... | |
| Collecting discussions from the spec list into one place | ... | ... | |
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 |
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 |
Mark Weitzel/Mark Halverson | ... (From EOS) | Y | Y | |
Chris Messina / Mark Weitzel | ...(From EOS) | Y | Y | |
Tim Moore | ...(From EOS) | Y | Y | |
Mark Weitzel / Rich Manalang | ...(From EOS) This is a general requirement to satisfy the performance requirements found within enterprise settings. | Y | Y | |
Mark Weitzel / Inbal Ronen (IBM) / Ido Guy (IBM) | ... | Y/N/N | Y | |
Thomas Duebendorfer / Christoph Renner | ?/?/? | ? |