Create separate specification for OData Query Options

I've seen this pop up from time to time, but especially with GraphQL's popularity of late, the need for a way to expand resources beyond their original shape and size to accommodate more use-cases in various clients, is becoming ever more apparent.

Developers are starting to understand that it's impossible to design a resource in a way that effectively can serve multiple widely different needs, which make them search for a query language of some sort to tweak the shape of the resources.

While GraphQL and Falcor are two ways of doing this, I'm personally a fan of OData Query Options as a standardized way to query, filter, and expand resources, to name a few of OData's abilities.

However, I believe it to be a hampering "feature" for these Query Options to reside within the much larger protocol of OData, which is so big and complex that no one can be expected to implement all of it just to be able to use the $expand keyword in the URLs of their API.

So, I propose that chapter 5 of the OData specification be extracted from the OData protocol and created as its own, independent specification that can be implemented isolated from the greater OData protocol. I think it would benefit the web community greatly to see more interoperable OData query implementations.

LinqToQuerystring proves that there's a will and a way to use OData Query Options in isolation, so I hope you will consider this for a future revision of OData.

Thanks!

Start by reviewing chapter 5 of the OData specification and the linked OData Query Options reference. The issue names no repository files or tests, so first determine how specifications are maintained in this repository. Done would be a separately maintainable specification for the query options described in the proposal.