Terms describing capabilities of a service There are some capabilities which are strongly recommended for services to support even though they are optional. Support for $top and $skip is a good example as supporting these query options helps with performance of a service and are essential. Such capabilities are assumed to be default capabilities of an OData service even in the case that a capabilities annotation doesn’t exist. Capabilities annotations are mainly expected to be used to explicitly specify that a service doesn’t support such capabilities. Capabilities annotations can as well be used to declaratively specify the support of such capabilities. On the other hand, there are some capabilities that a service may choose to support or not support and in varying degrees. $filter and $orderby are such good examples. This vocabulary aims to define terms to specify support or no support for such capabilities. A service is assumed to support by default the following capabilities even though an annotation doesn’t exist: - Countability ($count) - Client pageability ($top, $skip) - Expandability ($expand) - Indexability by key - Batch support ($batch) - Navigability of navigation properties A service is expected to support the following capabilities. If not supported, the service is expected to call out the restrictions using annotations: - Filterability ($filter) - Sortability ($orderby) - Queryability of top level entity sets - Query functions A client cannot assume that a service supports certain capabilities. A client can try, but it needs to be prepared to handle an error in case the following capabilities are not supported: - Insertability - Updatability - Deletability Using a property of `NavigationPropertyRestriction` in a [`NavigationRestrictions`](#NavigationRestrictions) annotation is discouraged in favor of using an annotation with the corresponding term from this vocabulary and a target path starting with a container and ending in the `NavigationProperty`, unless the favored alternative is impossible because a dynamic expression requires an instance path whose evaluation starts at the target of the `NavigationRestrictions` annotation. See [this example](../examples/Org.OData.Capabilities.V1.capabilities.md). The target path of a [`NavigationRestrictions`](#NavigationRestrictions) annotation followed by this navigation property path addresses the resource to which the other properties of `NavigationPropertyRestriction` apply. Instance paths that occur in dynamic expressions are evaluated starting at the boundary between both paths, which must therefore be chosen accordingly. Core.Description Core.LongDescription When the client specifies the `continue-on-error` preference, the service applies it by processing all requests according to their dependencies, regardless of the format for the $batch request. Core.Description The filter expression for this property consists of one or more interval expressions, combined by `or`. See SingleRange for the definition of an interval expression. Alternatively the filter expression can consist of one or more `ne` expressions combined by `and`, which is roughly equivalent to the union of the complementing open intervals. Roughly equivalent because `null` is allowed as a right-side operand of an `ne` expression. Core.Description Core.Description Core.Description Possible string value identifiers when specifying properties are `*`, _PropertyName_, `-`_PropertyName_. `*` denotes all properties are accessible. `-`_PropertyName_ excludes that specific property. _PropertyName_ explicitly provides access to the specific property. The absence of `RestrictedProperties` denotes all properties are accessible using that scope. Annotating a specific capability term, which is included as property in `DefaultCapabilitiesType`, for a specific collection-valued resource overrides the default capability with the specified properties using PATCH semantics: - Primitive or collection-valued properties specified in the specific capability term replace the corresponding properties specified in `DefaultCapabilities` - Complex-valued properties specified in the specific capability term override the corresponding properties specified in `DefaultCapabilities` using PATCH semantics recursively - Properties specified neither in the specific term nor in `DefaultCapabilities` have their default value