Proposal for OData Committee Spec Draft #2

Dear fellow OData TC Members;

As you know, progression of the OData V4 Specification is currently on hold until we have a minimum of three statements of use. While a number of member companies are fervently implementing the new specification, it will likely be mid- to late- October before we have at least the minimum number of strong statements of use.

Once we have three statements, the OASIS admin will prepare a final 60 day public review. It will take the admin about a week to prepare the public review, so if we are able to make our 3 statements of use by the end of October then the earliest the public review would start would be the second week of November. That means it would complete mid-December, which (given vacations) means that the final ballot would likely not be prepared until early January, with the specification becoming standard late January/early February.

In the meantime, we are finding a number of (primarily editorial) issues that we are collecting and processing as part of an errata, to be published alongside the specification when finalized. While it's not at all surprising that we are finding these issues (that is, after all, the reason OASIS requires the statement of use) there is extra overhead for us, as well as consumers of the specification, in having to apply a long set of errata to a new specification.

At this point we have 38 such non-normative editorial issues. Rather than publish these in an errata alongside the new specification, I would like to propose that we address these in a new version of the Committee Specification (CS2). Any such non-normative changes that we take at this point would require another one week TC ballot to progress a Committee Specification 2. However, if we aren't going to have our statements of use until end of October, we have time to prepare such a document and get it approved without delaying the start of the next phase of standardization (the 60 day public review.)

Any normative changes would require an additional 15 day public review (in addition to a week for the admin to prepare the docs). However, since the public review currently ends in the middle of holidays we have basically 2 weeks of dead time at the end of December before the final ballot is prepared, which means that we have a very narrow window of opportunity to address a small number of additional *normative* changes with minimal impact on the schedule.

We have identified a small set of such normative changes, currently slated to 4.1, which are breaking changes that we *really* would have liked to get in the 4.0 standard. Getting them in now would significantly decrease the urgency for a 4.1 release and increase compatibility with 4.1 if/when it was released.

My proposal, for your consideration, is to stop processing known editorial issues as errata and to direct the editors to prepare new/clean versions of all five specifications (and any related components within the three work products). At our meeting on September 25^th (I would propose we block off 2 hours) we would discuss and vote on any normative changes we wanted to apply, and review the final documents on Thursday, October 2^nd. By the end of the October 2^nd meeting we would seek committee approval to direct the OASIS Admin to initiate a 15 day public review of this new CSD. Assuming no public comment on the few normative changes we make we would then vote to have the OASIS Admin prepare another week long TC Ballot to promote the new CS2. This would put us in early/mid November, at which time we should have our statements of use and can initiate the 60 day public review. That public review would run through the vacation and complete mid-January, within 1-2 weeks of our current schedule but with a much cleaner set of documents.

I have asked Ram to add this to the agenda to discuss at out 8am PT 9/18 meeting, but I wanted to send it out to the TC ahead of time for consideration.

Thanks,

-Mike

odata message