This project is read-only.


Support OData Uri Parse extension of ODL 6.7 release


1. Problem:

ODL 6.7 supports

overriding default Uri parsing behavior, including:
-  Resolving property name 
-  Resolving type name 
-  Resolving navigation source name 
-  Resolving operation import name 
-  Resolving bound operation name 
-  Resolving function parameters 
-  Resolving entity set key 
-  Resolving binary operator node elements 
for detail:

2. Secanio - case insensitive

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:
Closed Jan 15, 2015 at 9:12 AM by lianw
Closed here and moved the issue to GitHub (


JackW wrote Aug 25, 2012 at 6:07 PM

This problem applies to more than mere casing differences. Would it be possible use attributes on the model, so when requesting XML or JSON the names declared using [XmlElement] or [JsonProperty] attributes are used in place of the underlying property names?

Obviously more heavily customised serialisation scenarios may require a more sophisticated extension point for mapping OData queries to the underlying properties, but it seems the change suggested above would cover most cases.

aggieben wrote Aug 27, 2012 at 10:36 PM

I seem to be observing a familiar problem with the $orderby query; I have a [Queryable] action in which '$orderby [PropertyName] DESC' causes a "syntax error" positioned right after the 'C' character and winds up responding with a 400 Bad Response. However, if the query is written '$orderby [PropertyName] desc', the action responds as expected.

Grokys wrote Sep 14, 2012 at 2:16 PM

This would be very useful for me too - I use javascript casing on the client side and C# casing on the server side, as I'm sure many people do.

jberd126 wrote Sep 15, 2012 at 3:52 AM

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?

HongmeiG wrote Oct 5, 2012 at 12:45 AM

We are locking down the preview release. This requires some changes in the OData Uri Parser.

HongmeiG wrote Mar 29, 2013 at 11:17 PM

This requires changes not in this product. Will contact the owner for making this change.

Hellmax wrote Sep 13, 2013 at 2:39 PM

Are there any updates on this?

danroth27 wrote Oct 24, 2013 at 12:52 AM

Requires ODataLib support. We will handle this in our next release.

kirkpabk wrote Jul 10, 2014 at 12:02 AM

Understanding that the ODATA protocol specifies case-sensitivity... it doesn't mean that this protocol design choice is the "right" one... Why should we--a consumer of a product--be forced to perform yet another time consuming (and expensive) mapping exercise that could be difficult to troubleshoot in a crunch... So--it's not the aspnetwebstack that really needs to be changed (they're adhering to a standard--although I'd love to see an "override" switch at webapi.config or something)--this should be ALSO addressed with the ODATA board. In lieu of this "defense"--I didn't see anything new in the ODataLib, pretty please--someone make it happen... ;-) We have many data models with an INSANE amount of non-sense casing (mostly from legacy mainframe) that makes documenting (let alone using) ODATA very tough for our consumers. Not to repeat, but the JavaScript standards casing issue is yet another reason why we need consumer-driven flexibility here. An organization should be free to CHOOSE is they want case sensitivity, but not FORCED... Just a thought...

eivindbjarte wrote Sep 9, 2014 at 2:32 PM

Agree complety with kirkpabk, this is yet another example of making something complicated out of something that should be simple .