For OData $filter/$sort queries, our output could potentially different casings vs. the model. In this scenario the query parsing will fail.
For example, if my model has a "Name" property but my JSON outputs the property as "name" I cannot use $filter=startswith(name,'Joe') which consumers would expect.
Discussion reference: http://aspnetwebstack.codeplex.com/discussions/391903
Comments: @JackW, Ideally I would like to have a query property name provider (or something) that would be more flexible and support scenarios that are content negotiated. I felt that the case insensitive support would be simpler to implement and go a long way to supporting many scenarios. However it's going to go so far. Is there any plans for something like JackW mentions?
For example, if my model has a "Name" property but my JSON outputs the property as "name" I cannot use $filter=startswith(name,'Joe') which consumers would expect.
Discussion reference: http://aspnetwebstack.codeplex.com/discussions/391903
Comments: @JackW, Ideally I would like to have a query property name provider (or something) that would be more flexible and support scenarios that are content negotiated. I felt that the case insensitive support would be simpler to implement and go a long way to supporting many scenarios. However it's going to go so far. Is there any plans for something like JackW mentions?