Draft timeline for OData v4 Work Products:

·         July 2012 through November 2012

o   July 26-27, 2012 1st F2F meeting (Redmond, WA) and TC launch

o   Make progress on issues

o   Nov 8-9, 2012 2nd F2F meeting (Littleton, MA)

o   Make progress on issues

·         December 2012

o   December 19, 2012

§  File all known issues on core Work Products resulting from new proposals

·         January 2013

o   January 17, 2013

§  File all known issues on core Work Products resulting from extension Work Products

o   3rd F2F meeting January 30–31, 2013 (Zürich, Switzerland)

§  Resolve all key issues on core Work Products

§  TC agrees to setting a higher bar for accepting new issues on core Work Products

·         February 2013

o   Starting Feb 7, 2013

§  Higher bar in effect for accepting issues on core Work Products. The TC will only accept class A, class B, and class C issues for processing on OData v4.0 core Work Products; class D issues will be deferred to a future revision (such as or v4.1 or v5.0). See classification [1] of issues.

o   Make progress on remaining issues on Core Work Products

·         March 2013

o   March 14, 2013

§  Aim to resolve all remaining issues on Core Work Products

·         April 2013

o   April 4, 2013

§  Resolve all remaining issues on Core Work Products

o   April 11, 2013

§  Detailed specification reviews during extended TC meeting

o   April 18, 2013

§  Detailed specification reviews during extended TC meeting

o   April 22, 2013

§  Editors to post candidate Committee Specification Draft 01 (CSD01) of core Work Products containing resolutions to all issues

o   4th F2F meeting April 25-26, 2013 (Walldorf, Germany)

§  Approve Committee Specification Draft 01 (CSD01) of core Work Products and agree to start 30-day public review

§  Continue work on extension Work Products

·         May 2013

o   May 1 through May 30, 2013

§  30-day public review of core Work Products

§  Address public review comments on core Work Products

·         June 2013

o   5th F2F meeting June 13-14, 2013 (Redmond, WA)

§  Address all public review comments on core Work Products

§  Agree to higher bar for accepting new issues (class A or class B issues only); see [1] for issue classification.

o   June 18, 2013

§  Editors to post candidate Committee Specification Draft 02 (CSD02) of core Work Products containing resolutions to all issues

o   June 20, 2013

§  Approve Committee Specification Draft 02 (CSD02) of core Work Products and agree to start 15-day public review

o   June 20 through 30, 2013

§  Work with TC administration to publish CSD02 and start 15-day public review

·         July 2013

o   July 1 through 15, 2013

§  15-day public review

·         August 2013

o   Approve Committee Specification 01 (CS01)

·         September 2013

o   Address select errata and minor technical issues

·         October 2013

o   Approve Committee Specification Draft 03

o   15-day public review

·         November 2013

o   Approve Committee Specification 02

o   Obtain at least THREE Statements of Use

o   Approve Candidate OASIS Standard

o   Publish Candidate OASIS Standard

o   Initiate request to start 60-day public review

·         December 2013 through January 2014

o   60-day public review

·         February 2014

o   14-day OASIS-wide membership ballot

o   OASIS Standard approved

·         March through May 2014

o   Address OData v4 errata issues

o   6th F2F meeting May 15-16, 2013 (Redmond, WA)

§  Address OData v4 errata issues

§  Approve OData v4 errata as Committee Specification Draft 01

§  Confirm (via Full Majority vote) that the corrections do not constitute substantive change

§  Agree to start 15-day public review

§  Prepare request package (containing Explanatory Report, Q&A, etc.) for submitting OData v4 OASIS Standard (as corrected by OData v4 Approved Errata) and OData JSON Format v4 OASIS Standard to ISO/IEC JTC 1 for ratification as an International Standard.

·         June 2014

o   June 2 through 16, 2014

§  15-day public review of OData v4 errata

o   June 26, 2014

§  Approve the OData v4 errata as Approved Errata (via Full Majority Vote)

§  Agree to start a Special Majority Vote (electronic ballot for 7 days) to approve submitting OData v4 OASIS Standard (as corrected by OData v4 Approved Errata) and OData JSON Format v4 OASIS Standard to ISO/IEC JTC 1

·         July 2014

o   Approve (via Special Majority Vote) submitting OData v4 OASIS Standard (as corrected by OData v4 Approved Errata) and OData JSON Format v4 OASIS Standard to ISO/IEC JTC 1

o   Submit the request package for international standardization (containing Explanatory Report, Q&A, etc.) to OASIS President for review and further processing

·         August 2014

o   30-day public review of the request package (for international standardization)

·         September 2014

o   OASIS President approves the package

o   ISO/IEC JTC 1 reviews the application

·         November 2014 through March 2015

o   5-month Draft International Standard (DIS) Ballot (involving various countries) to approve International Standard.

·         April 2015

o   International Standard published (assuming the DIS ballot passes without comments)

o   Note, if there are comments arising from the DIS ballot, a BRM (Ballot Resolution Meeting) is required followed by a 2-month Final DIS Ballot (FDIS). This would add another 4 to 5 months to this schedule.

 

Draft timeline for OData Extension for Data Aggregation:

·         November 2012 through July 2013

o   Process issues

·        August 2013

o   Approve Committee Specification Draft 01

·         September 2013

o   30-day public review

·         Feb 2014

o   OData Extension for Data Aggregation approved as Committee Specification 01

·         March 2014 through TBD

o   Awaiting implementations (Statements of Use) before proceeding to Candidate OASIS Standard and onwards

 

[1] Classification of issues

·         Class A: Purely editorial corrections

·         Class B: Something is broken (due to an existing flaw or due to a missing feature): Major/minor technical flaws or interoperability problems

·         Class C: Nothing is broken but need this for a “real good” reason (for example, this could not be deferred to a future revision): Major/minor technical changes

·         Class D: Nothing is broken but nice to have: Major/minor technical changes