Since the last roundup, we've received a ton of new feedback and there have been some really exciting new developments too.

Heres the last couple of weeks feedback:

  • OData Wiki: As mentioned last time there is now a OData community wiki called ODataPrimer. We had originally planned to create a wiki on OData.org, but we won't be doing that anytime soon because ODataPrimer looks perfect for now.
  • OData Mailing list: We always planned an OData Mailing List, and are now almost ready to go. So you can expect to see something up on the same site that hosts the M-Specification mailing list soon.
  • Open Source the .NET producer libraries: This is something that we've now heard from a number of people.  We are working through the feasibility and associated logistics at the moment.  We will let you know as we make progress on our thinking around this request.
  • Create or Foster producer libraries for different platforms: Closely related is the need to make it easy to create OData Services on all major platforms. The most common requests being Java (because of it's importance to the enterprise), PHP, Python and Ruby (OData on Rails?). Doug Purdy has a blog post asking for your opinions here. Again we are investigating options here. We are also trying to figure out how we can help simplify creating libraries and services. So far we've released the OData Validation Toolkit to help you validate your service. Can you think of anything else beyond just libraries that would help? We'd love to hear you suggestions here.
  • Sample Producer code on different platforms: We've heard a lot of requests for sample code to create an OData Service in language X on platform Y. You might think this is dependent on the above, and to implement the whole of OData it certainly is, but OData is flexible enough that you can do a rudimentary OData service - in any language - very easily. Check out  Implementing only certain aspects of OData for more.
  • Test Suite for Producers and Producer Libraries: Anders Hol wondered if we would release our test suites too. The OData Validation Toolkit - part of the OData SDK - should help. The toolkit looks at your service's data model, which it tries to extract by going to $metadata, and then runs some T4 templates against your model to produce tests bound to your service. The cool thing is that the location of the T4 templates can easily be changed, so you can reference your own T4 templates. Why would you do that? Well you could extend our, admittedly rudimentary, templates or refactor the existing templates so they emit Ruby or Java tests instead of C#. In fact we hope community authored language packs will emerge over time. Indeed if you create them we will definitely let the community know.
  • Hiding Properties: Luigi wanted to know how to hide properties. If you use the .NET Data Services producer libraries then by default every property in your underlying class gets exposed. So you should think of the classes exposed by your data service in the same way you think about a View Model for UI code: if you don't want to expose it don't put in your class. If re-working your class isn't a realistic option, you can still hide properties by creating a  Custom Data Services Provider. You can find more Custom Data Service samples and guidance in the OData SDK.
  • RDF data sources and RDF format: Jay Funnell would like to have the ability to consume and produce RDF built-in to the protocol. Consuming RDF in a Data Service is possible today, but you have to write a Custom Data Service Provider. And as of today there isn't a prescribed way to translate OData into RDF. We wonder whether RDF integration with OData is important beyond those who are extremely passionate about RDF? Is this something that you want to see?
  • Primitive Types and Namespaces: Eric Westenberger asked a good question about how to map his Java types into OData. Basically when you create your model, you can choose any Namespace and Name so long as it complies with the C# identifier rules and is no more the 480 characters long. What this means in practice is that most Java class and namespace names should be fine. OData also ships with a built-in set of  primitive types, that you must be able to map your properties into. Please let us know if you think we are missing key primitive types.
  • Licensing questions: Gustavo Andriotti wanted to know more about the licensing of the Protocol and the OData SDK. The OData Protocol itself is released under the Open Specification Promise, if you take another look at the OData home page you will notice we reworked it to make this clearer.  The OData SDK on the other hand is a collect of resources, each of which have their own license. Most of the time the license is either  Ms-PL or Apache. To be sure simply follow the download link for licensing terms. Thanks again for the feedback Gustavo.

And in other developments:

As always keep the feedback coming.
Alex James