Support for Capabilities vocabulary

[LaylaLiu]

ODataLib should have a way to expose an accurate Capabilities vocabulary.

[jogonzal]

Please pay special attention to annotations targeted towards contained entity sets. We had to hack EdmLib quite a bit to get those to work.

[ghost]

👍
It may be useful if you link relevant discussions about containment* @jogonzal-msft . If there were public issues tracking that work it'd be super easy to put the link here. :)

I think it may be constructive to have a wider public discussion about how the apis for this feature are implemented. Especially since other projects, such as Vipr (https://github.com/Microsoft/Vipr) have been working with annotations in EDM lib.

I believe part of this work should include simplifying the API for accessing vocabulary terms on EDM items. (This has an added benefit that it'll make all vocabulary-related work simpler, which should also make users of custom annotations such as SAP happy)

Right now, to read vocabulary terms, you need to write some code like this ++ apply custom mapping on your own time. This shouldn't be the case long term.
https://github.com/Microsoft/Vipr/blob/master/src/Readers/Vipr.Reader.OData.v4/ODataVocabularyReader.cs

It'd additionally be nice for the underlying EDMLib to ship representations of the major vocabularies. (In particular, representations for complex types exposed in the Core and Capabilities vocabulary would be wonderful so that consumers of these apis do not need to compile their own c# class to represent Core vocabularies) Having vocabularies in the class hierarchy could also improve the design time experience.

Vipr Devs probably have more to say in this thread too.

*(In my interperetation, the key insight from most of those discussions is that the "AppliesTo" term of an annotation should be interpreted as a hint, and not a requirement. This obviously informs the implementation of capabilites vocabularies across OData.Net, WebApi, Restier)

[congysu]

Related issue: #37

[mikepizzo]

Capabilities is added in PR #232.