\(\hbox{}\)

This stage:

https://docs.oasis-open.org/odata/odata-csdl-json/v4.02/csd02/odata-csdl-json-v4.02-csd02.md (Authoritative)
https://docs.oasis-open.org/odata/odata-csdl-json/v4.02/csd02/odata-csdl-json-v4.02-csd02.html
https://docs.oasis-open.org/odata/odata-csdl-json/v4.02/csd02/odata-csdl-json-v4.02-csd02.pdf

Previous stage:

https://docs.oasis-open.org/odata/odata-csdl-json/v4.02/csd01/odata-csdl-json-v4.02-csd01.md (Authoritative)
https://docs.oasis-open.org/odata/odata-csdl-json/v4.02/csd01/odata-csdl-json-v4.02-csd01.html
https://docs.oasis-open.org/odata/odata-csdl-json/v4.02/csd01/odata-csdl-json-v4.02-csd01.pdf

Latest stage:

https://docs.oasis-open.org/odata/odata-csdl-json/v4.02/odata-csdl-json-v4.02.md (Authoritative)
https://docs.oasis-open.org/odata/odata-csdl-json/v4.02/odata-csdl-json-v4.02.html
https://docs.oasis-open.org/odata/odata-csdl-json/v4.02/odata-csdl-json-v4.02.pdf

Technical Committee:

OASIS Open Data Protocol (OData) TC

Chairs:

Ralf Handl (ralf.handl@sap.com), SAP SE
Michael Pizzo (mikep@microsoft.com), Microsoft

Editors:

Ralf Handl (ralf.handl@sap.com), SAP SE
Michael Pizzo (mikep@microsoft.com), Microsoft
Heiko Theißen (heiko.theissen@sap.com), SAP SE

Additional artifacts:

This prose specification is one component of a Work Product that also includes:

• JSON schemas: OData CSDL JSON schema. https://docs.oasis-open.org/odata/odata-csdl-json/v4.02/csd02/schemas/.

Related work:

This specification replaces or supersedes:

• OData Common Schema Definition Language (CSDL) JSON Representation Version 4.01. Edited by Michael Pizzo, Ralf Handl, and Martin Zurmuehl. OASIS Standard. Latest stage: https://docs.oasis-open.org/odata/odata-csdl-json/v4.01/odata-csdl-json-v4.01.html.

This specification is related to:

• OData Version 4.02. Edited by Michael Pizzo, Ralf Handl, and Heiko Theißen. A multi-part Work Product that includes:
  • OData Version 4.02 Part 1: Protocol. Latest stage: https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part1-protocol.html
  • OData Version 4.02 Part 2: URL Conventions. Latest stage: https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part2-url-conventions.html
  • ABNF components: OData ABNF Construction Rules Version 4.02 and OData ABNF Test Cases. https://docs.oasis-open.org/odata/odata/v4.02/csd02/abnf/
• OData Vocabularies Version 4.0. Edited by Michael Pizzo, Ralf Handl, and Ram Jeyaraman. Latest stage: https://docs.oasis-open.org/odata/odata-vocabularies/v4.0/odata-vocabularies-v4.0.html
• OData Common Schema Definition Language (CSDL) XML Representation Version 4.02. Edited by Michael Pizzo, Ralf Handl, and Heiko Theißen. Latest stage: https://docs.oasis-open.org/odata/odata-csdl-xml/v4.02/odata-csdl-xml-v4.02.html
• OData JSON Format Version 4.02. Edited by Ralf Handl, Mike Pizzo, and Heiko Theißen. Latest stage: https://docs.oasis-open.org/odata/odata-json-format/v4.02/odata-json-format-v4.02.html

Abstract:

OData services are described by an Entity Model (EDM). The Common Schema Definition Language (CSDL) defines specific representations of the entity data model exposed by an OData service, using XML, JSON, and other formats. This document (OData CSDL JSON Representation) specifically defines the JSON representation of CSDL.

Status:

This document was last revised or approved by the OASIS Open Data Protocol (OData) TC on the above date. The level of approval is also listed above. Check the “Latest stage” location noted above for possible later revisions of this document. Any other numbered Versions and other technical work produced by the Technical Committee (TC) are listed at https://groups.oasis-open.org/communities/tc-community-home2?CommunityKey=e7cac2a9-2d18-4640-b94d-018dc7d3f0e2#technical.

TC members should send comments on this specification to the TC’s email list. Any individual may submit comments to the TC by sending email to Technical-Committee-Comments@oasis-open.org. Please use a Subject line like “Comment on OData CSDL”.

This specification is provided under the RF on RAND Terms Mode of the OASIS IPR Policy, the mode chosen when the Technical Committee was established. For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC’s web page (https://www.oasis-open.org/committees/odata/ipr.php).

Note that any machine-readable content (Computer Language Definitions) declared Normative for this Work Product is provided in separate plain text files. In the event of a discrepancy between any such plain text file and display content in the Work Product’s prose narrative document(s), the content in the separate plain text file prevails.

Key words:

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 RFC2119 and RFC8174 when, and only when, they appear in all capitals, as shown here.

Citation format:

When referencing this specification the following citation format should be used:

[OData-CSDL-JSON-v4.02]

OData Common Schema Definition Language (CSDL) JSON Representation Version 4.02. Edited by Ralf Handl, Michael Pizzo, and Heiko Theißen. 28 February 2024. OASIS Committee Specification Draft 02. https://docs.oasis-open.org/odata/odata-csdl-json/v4.02/csd02/odata-csdl-json-v4.02-csd02.html. Latest stage: https://docs.oasis-open.org/odata/odata-csdl-json/v4.02/odata-csdl-json-v4.02.html.

Notices

Copyright © OASIS Open 2024. All Rights Reserved.

Distributed under the terms of the OASIS IPR Policy.

The name “OASIS” is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs.

For complete copyright information please see the full Notices section in an Appendix below.

The OData CSDL JSON representation can be requested using the $format query option in the request URL with the media type application/json, optionally followed by media type parameters, or the case-insensitive abbreviation json which MUST NOT be followed by media type parameters.

Alternatively, this representation can be requested using the Accept header with the media type application/json, optionally followed by media type parameters.

If specified, $format overrides any value specified in the Accept header.

The response MUST contain the Content-Type header with a value of application/json, optionally followed by media type parameters.

Possible media type parameters are:

• IEEE754Compatible
• metadata

The names and values of these parameters are case-insensitive.

CSDL JSON documents are designed for easy and efficient lookup of model constructs by their name without having to know or guess what kind of model element it is. Thus, all primary model elements (entity types, complex types, type definitions, enumeration types, terms, actions, functions, and the entity container) are direct members of their schema, using the schema-unique name as the member name. Similarly, child elements of primary model elements (properties, navigation properties, enumeration type members, entity sets, singletons, action imports, and function imports) are direct members of the objects describing their parent model element, using their locally unique name as the member name.

To avoid name collisions, all fixed member names are prefixed with a dollar ($) sign and otherwise have the same name and capitalization as their counterparts in the CSDL XML representation OData-CSDLXML (with one exception: the counterpart of the EntitySet element’s EntityType member is $Type, to harmonize it with all other type references).

Additional fixed members introduced by this specification and without counterpart in OData-CSDLXML are also prefixed with a dollar ($) sign and use upper-camel-case names. One of these is $Kind which represents the kind of model element. Its value is the upper-camel-case local name of the XML element representing this kind of model element in OData-CSDLXML, e.g. EntityType or NavigationProperty.

While the XML representation of CSDL allows referencing model elements with alias-qualified names as well as with namespace-qualified names, this JSON representation requires the use of alias-qualified names if an alias is specified for an included or document-defined schema. Aliases are usually shorter than namespaces, so this reduces text size of the JSON document. Text size matters even if the actual HTTP messages are sent in compressed form because the decompressed form needs to be reconstructed, and clients not using a streaming JSON parser have to materialize the full JSON document before parsing.

To further reduce size the member $Kind is optional for structural properties as these are more common than navigation properties, and the member $Type is optional for string properties, parameters, and return types, as this type is more common than other primitive types.

In general, all members that have a default value SHOULD be omitted if they have the default value.

The structure of CSDL JSON documents can be verified with the JSON Schema OData-CSDL-Schema provided as an additional artifact of this prose specification. This schema only defines the shape of a well-formed CSDL JSON document but is not descriptive enough to define what a correct CSDL JSON document MUST be in every imaginable use case. This specification document defines additional rules that correct CSDL JSON documents MUST fulfill. In case of doubt on what makes a CSDL JSON document correct the rules defined in this specification document take precedence.

A nominal type has a name that MUST be a simple identifier. Nominal types are referenced using their qualified name. The qualified type name MUST be unique within a model as it facilitates references to the element from other parts of the model.

Names are case-sensitive, but service authors SHOULD NOT choose names that differ only in case.

Structured types are composed of other model elements. Structured types are common in entity models as the means of representing entities and structured properties in an OData service. Entity types and complex types are both structured types.

Structured types are composed of zero or more structural properties and navigation properties. These properties can themselves be of a structured type.

An instance of a structured type must have a finite representation that includes all its properties. These properties are either integral parts of the instance or references to instances. In the first case the integral parts must be represented as part of the overall representation. These integral parts are modeled as structural properties and containment navigation properties. If an instance of a structured type contains a chain of these, this chain MUST be finite for the overall representation to be finite, even if the chain of types leads back to the structured type of the instance. Note that in this circular case finiteness is only possible if the chain of instances ends with a null value or an empty collection. In the second case the references are modeled as non-containment navigation properties. Chains of these can be infinite, for example, if an entity contains a self-reference.

Open entity types and open complex types allow properties to be added dynamically to instances of the open type.

Structured types are composed of other structured types and primitive types. OData defines the following primitive types:

Edm.Date and Edm.DateTimeOffset follow XML-Schema-2 and use the proleptic Gregorian calendar, allowing the year 0000 (equivalent to 1 BCE) and negative years (year -0001 being equivalent to 2 BCE etc.). The supported date range is service-specific and typically depends on the underlying persistency layer, e.g. SQL only supports years 0001 to 9999.

Edm.Decimal with a Scale value of floating, Edm.Double, and Edm.Single allow the special numeric values -INF, INF, and NaN.

Edm.Stream is a primitive type that can be used as a property of an entity type or complex type, the underlying type for a type definition, or a binding or non-binding parameter or return type of an action or function. Edm.Stream, or a type definition whose underlying type is Edm.Stream, cannot be used in collections.

Some of these types allow facets, defined in section 3.4.

Representation of primitive type values within a URL is defined by the rule primitiveLiteral in OData-ABNF. Representation within request and response bodies is format specific.

The facets in the following subsections modify or constrain the acceptable values of primitive typed model elements, for example a structural property, action or function parameter, action or function return type, or term.

For single-valued model elements the facets apply to the value of the model element. For collection-valued model elements the facets apply to the items in the collection.

"SuggestedTimes": {
  "$Type": "Edm.DateTimeOffset",
  "$Collection": true,
  "$Precision": 6
}

"Amount32": {
  "$Type": "Edm.Decimal",
  "$Precision": 3,
  "$Scale": 2
}

"Amount22": {
  "$Type": "Edm.Decimal",
  "$Precision": 2,
  "$Scale": 2
}

"Amount3v": {
  "$Type": "Edm.Decimal",
  "$Precision": 3
}

"Amount7f": {
  "$Type": "Edm.Decimal",
  "$Precision": 7,
  "$Scale": "floating"
}

The following built-in abstract types can be used within a model:

• Edm.PrimitiveType
• Edm.ComplexType
• Edm.EntityType
• Edm.Untyped

Conceptually, these are the abstract base types for primitive types (including type definitions and enumeration types), complex types, entity types, or any type or collection of types, respectively, and can be used anywhere a corresponding concrete type can be used, except:

• Edm.EntityType
  • cannot be used as the type of a singleton in an entity container because it doesn’t define a structure, which defeats the purpose of a singleton.
  • cannot be used as the type of an entity set because all entities in an entity set must have the same key fields to uniquely identify them within the set.
  • cannot be the base type of an entity type or complex type.
• Edm.ComplexType
  • cannot be the base type of an entity type or complex type.
• Edm.PrimitiveType
  • cannot be used as the type of a key property of an entity type or as the underlying type of an enumeration type.
  • cannot be used as the underlying type of a type definition in a CSDL document with a version of 4.0.
  • can be used as the underlying type of a type definition in a CSDL document with a version of 4.01 or greater.
• Edm.Untyped
  • cannot be returned in a payload with an OData-Version header of 4.0. Services should treat untyped properties as dynamic properties in 4.0 payloads.
  • cannot be used as the type of a key property of an entity type.
  • cannot be the base type of an entity type or complex type.
  • cannot be used as the underlying type of a type definition or enumeration type.
• Collection(Edm.PrimitiveType)
  • cannot be used.
• Collection(Edm.Untyped)
  • cannot be returned in a payload with an OData-Version header of 4.0. Services should treat untyped properties as dynamic properties in 4.0 payloads.

Vocabulary terms can, in addition, use

• Edm.AnnotationPath
• Edm.PropertyPath
• Edm.NavigationPropertyPath
• Edm.AnyPropertyPath (Edm.PropertyPath or Edm.NavigationPropertyPath)
• Edm.ModelElementPath (any model element, including Edm.AnnotationPath, Edm.NavigationPropertyPath, and Edm.PropertyPath)

as the type of a primitive term, or the type of a property of a complex type (recursively) that is exclusively used as the type of a term. See section 14.4.1 for details.

Many parts of the model can be decorated with additional information using annotations. Annotations are identified by their term name and an optional qualifier that allows applying the same term multiple times to the same model element.

A model element MUST NOT specify more than one annotation for a given combination of term and qualifier.

A reference to an external CSDL document allows to bring part of the referenced document’s content into the scope of the referencing document.

A reference MUST specify a URI that uniquely identifies the referenced document, so two references MUST NOT specify the same URI. The URI SHOULD be a URL that locates the referenced document. If the URI is not dereferencable it SHOULD identify a well-known schema. The URI MAY be absolute or relative URI; relative URLs are relative to the URL of the document containing the reference, or relative to a base URL specified in a format-specific way.

A reference MAY be annotated.

The Core.SchemaVersion annotation, defined in OData-VocCore, MAY be used to indicate a particular version of the referenced document. If the Core.SchemaVersion annotation is present, the $schemaversion system query option, defined in OData-Protocol, section 11.2.12, SHOULD be used when retrieving the referenced schema document.

{
  …
  "$Reference": {
    "https://oasis-tcs.github.io/odata-vocabularies/vocabularies/Org.OData.Capabilities.V1.json": {
      …
    },
    "https://oasis-tcs.github.io/odata-vocabularies/vocabularies/Org.OData.Core.V1.json": {
      …
    },
    "http://example.org/display/v1": {
      …
    }
  },
  …
}

A reference MAY include zero or more schemas from the referenced document.

The included schemas are identified via their namespace. The same namespace MUST NOT be included more than once, even if it is declared in more than one referenced document.

When including a schema, a simple identifier value MAY be specified as an alias for the schema that is used in qualified names instead of the namespace. For example, an alias of display might be assigned to the namespace org.example.vocabularies.display. An alias-qualified name is resolved to a fully qualified name by examining aliases for included schemas and schemas defined within the document.

Aliases are document-global, so all schemas defined within or included into a document MUST have different aliases, and aliases MUST differ from the namespaces of all schemas defined within or included into a document.

The alias MUST NOT be one of the reserved values Edm, odata, System, or Transient.

An alias is only valid within the document in which it is declared; a referencing document may define its own aliases for included schemas.

{
  …
  "$Reference": {
    "https://oasis-tcs.github.io/odata-vocabularies/vocabularies/Org.OData.Capabilities.V1.json": {
      "$Include": [
        {
          "$Namespace": "Org.OData.Capabilities.V1",
          "$Alias": "Capabilities"
        }
      ]
    },
    "https://oasis-tcs.github.io/odata-vocabularies/vocabularies/Org.OData.Core.V1.json": {
      "$Include": [
        {
          "$Namespace": "Org.OData.Core.V1",
          "$Alias": "Core",
          "@Core.DefaultNamespace": true
        }
      ]
    },
    "http://example.org/display/v1": {
      "$Include": [
        {
          "$Namespace": "org.example.display",
          "$Alias": "UI"
        }
      ]
    }
  },
  …
}

In addition to including whole schemas with all model constructs defined within that schema, a reference may include annotations.

Annotations are selectively included by specifying the namespace of the annotations’ term. Consumers can opt not to inspect the referenced document if none of the term namespaces is of interest for the consumer.

In addition, the qualifier of annotations to be included MAY be specified. For instance, a service author might want to supply a different set of annotations for various device form factors. If a qualifier is specified, only those annotations from the specified term namespace with the specified qualifier (applied to a model element of the target namespace, if present) SHOULD be included. If no qualifier is specified, all annotations within the referenced document from the specified term namespace (taking into account the target namespace, if present) SHOULD be included.

The qualifier also provides consumers insight about what qualifiers are present in the referenced document. If the consumer is not interested in that particular qualifier, the consumer can opt not to inspect the referenced document.

In addition, the namespace of the annotations’ target MAY be specified. If a target namespace is specified, only those annotations which apply a term form the specified term namespace to a model element of the target namespace (with the specified qualifier, if present) SHOULD be included. If no target namespace is specified, all annotations within the referenced document from the specified term namespace (taking into account the qualifier, if present) SHOULD be included.

The target namespace also provides consumers insight about what namespaces are present in the referenced document. If the consumer is not interested in that particular target namespace, the consumer can opt not to inspect the referenced document.

{
  …
  "$Reference": {
    "http://odata.org/ann/b": {
      "$IncludeAnnotations": [
        {
          "$TermNamespace": "org.example.validation"
        },
        {
          "$TermNamespace": "org.example.display",
          "$Qualifier": "Tablet"
        },
        {
          "$TermNamespace": "org.example.hcm",
          "$TargetNamespace": "com.example.Sales"
        },
        {
          "$TermNamespace": "org.example.hcm",
          "$Qualifier": "Tablet",
          "$TargetNamespace": "com.example.Person"
        }
      ]
    }
  },
  …
}

A schema MAY specify an alias which MUST be a simple identifier.

If a schema specifies an alias, the alias MUST be used instead of the namespace within qualified names throughout the document to identify model elements of that schema. A mixed use of namespace-qualified names and alias-qualified names is not allowed.

Aliases are document-global, so all schemas defined within or included into a document MUST have different aliases, and aliases MUST differ from the namespaces of all schemas defined within or included into a document. Aliases defined by a schema can be used throughout the containing document and are not restricted to the schema that defines them.

The alias MUST NOT be one of the reserved values Edm, odata, System, or Transient.

{
  …
  "org.example": {
    "$Alias": "self",
    "@Core.Description": "Example schema",
    …
  },
  …
}

An entity type can inherit from another entity type by specifying it as its base type.

An entity type inherits the key as well as structural and navigation properties of its base type.

An entity type MUST NOT introduce an inheritance cycle by specifying a base type.

"Manager": {
  "$Kind": "EntityType",
  "$BaseType": "self.Employee",
  "AnnualBudget": {
    "$Nullable": true,
    "$Type": "Edm.Decimal",
    "$Scale": 0
  },
  "Employees": {
    "$Kind": "NavigationProperty",
    "$Collection": true,
    "$Type": "self.Employee"
  }
}

An entity type MAY indicate that it is abstract and cannot have instances.

For OData 4.0 responses a non-abstract entity type MUST define a key or derive from a base type with a defined key.

An abstract entity type MUST NOT inherit from a non-abstract entity type.

An entity type MAY indicate that it is open and allows clients to add properties dynamically to instances of the type by specifying uniquely named property values in the payload used to insert or update an instance of the type.

An entity type derived from an open entity type MUST indicate that it is also open.

Note: structural and navigation properties MAY be returned by the service on instances of any structured type, whether or not the type is marked as open. Clients MUST always be prepared to deal with additional properties on instances of any structured type, see OData-Protocol, section 3.

An entity type that does not specify a base type MAY indicate that it is a media entity type. Media entities are entities that represent a media stream, such as a photo. Use a media entity if the out-of-band stream is the main topic of interest and the media entity is just additional structured information attached to the stream. Use a normal entity with one or more properties of type Edm.Stream if the structured data of the entity is the main topic of interest and the stream data is just additional information attached to the structured data. For more information on media entities see OData-Protocol, section 11.2.3.

An entity type derived from a media entity type MUST indicate that it is also a media entity type.

Media entity types MAY specify a list of acceptable media types using an annotation with term Core.AcceptableMediaTypes, see OData-VocCore.

An entity is uniquely identified within an entity set by its key. A key MAY be specified if the entity type does not specify a base type that already has a key declared.

In order to be specified as the type of an entity set or a collection-valued containment navigation property, the entity type MUST either specify a key or inherit its key from its base type.

In OData 4.01 responses entity types used for singletons or single-valued navigation properties do not require a key. In OData 4.0 responses entity types used for singletons or single-valued navigation properties MUST have a key defined.

An entity type’s key refers to the set of properties whose values uniquely identify an instance of the entity type within an entity set. The key MUST consist of at least one property.

Key properties MUST NOT be nullable and MUST be typed with an enumeration type, one of the following primitive types, or a type definition based on one of these primitive types:

• Edm.Boolean
• Edm.Byte
• Edm.Date
• Edm.DateTimeOffset
• Edm.Decimal
• Edm.Duration
• Edm.Guid
• Edm.Int16
• Edm.Int32
• Edm.Int64
• Edm.SByte
• Edm.String
• Edm.TimeOfDay

Key property values MAY be language-dependent, but their values MUST be unique across all languages and the entity-ids (defined in OData-Protocol, section 4.1) MUST be language independent.

A key property MUST be a non-nullable primitive property of the entity type itself, including non-nullable primitive properties of non-nullable single-valued complex properties, recursively.

In OData 4.01 the key properties of a directly related entity type MAY also be part of the key if the navigation property is single-valued and not nullable. This includes navigation properties of non-nullable single-valued complex properties (recursively) of the entity type. If a key property of a related entity type is part of the key, all key properties of the related entity type MUST also be part of the key.

If the key property is a property of a complex property (recursively) or of a directly related entity type, the key MUST specify an alias for that property that MUST be a simple identifier and MUST be unique within the set of aliases, structural and navigation properties of the declaring entity type and any of its base types.

An alias MUST NOT be defined if the key property is a primitive property of the entity type itself.

For key properties that are a property of a complex or navigation property, the alias MUST be used in the key predicate of URLs instead of the path to the property because the required percent-encoding of the forward slash separating segments of the path to the property would make URL construction and parsing rather complicated. The alias MUST NOT be used in the query part of URLs, where paths to properties don’t require special encoding and are a standard constituent of expressions anyway.

"Category": {
  "$Kind": "EntityType",
  "$Key": [
    "ID"
  ],
  "ID": {
    "$Type": "Edm.Int32"
  },
  "Name": {
    "$Nullable": true,
    "@Core.IsLanguageDependent": true
  }
}

"Category": {
  "$Kind": "EntityType",
  "$Key": [
    {
      "EntityInfoID": "Info/ID"
    }
  ],
  "Info": {
    "$Type": "self.EntityInfo"
  },
  "Name": {
    "$Nullable": true
  }
},
"EntityInfo": {
  "$Kind": "ComplexType",
  "ID": {
    "$Type": "Edm.Int32"
  },
  "Created": {
    "$Type": "Edm.DateTimeOffset",
    "$Precision": 0
  }
}

"OrderLine": {
  "$Kind": "EntityType",
  "$Key": [
    "OrderID",
    "LineNumber"
  ],
  "OrderID": {
    "$Type": "Edm.Int32"
  },
  "LineNumber": {
    "$Type": "Edm.Int32"
  }
}

GET http://host/service/Categories(EntityInfoID=1)

GET http://example.org/OData.svc/Categories?$filter=Info/ID le 100

The property’s type MUST be a primitive type, complex type, or enumeration type in scope, or a collection of one of these types.

If the property is part of a chain of structural properties and containment navigation properties leading back to the property’s declaring type, the finiteness condition for structured types demands that at least one property in this chain MUST be nullable or collection-valued.

A collection-valued property MAY be annotated with the Core.Ordered term, defined in OData-VocCore, to specify that it supports a stable ordering.

A collection-valued property MAY be annotated with the Core.PositionalInsert term, defined in OData-VocCore, to specify that it supports inserting items into a specific ordinal position.

"Units": {
  "$Collection": true
}

A Boolean value specifying whether the property can have the value null.

A primitive- or enumeration-typed property MAY define a default value that is used if the property is not explicitly represented in an annotation, the body of a request or response, or a complex literal in a request URL.

If no value is specified, the client SHOULD NOT assume a default value.

The navigation property’s type MUST be an entity type in scope, the abstract type Edm.EntityType, or a collection of one of these types.

If the property is part of a chain of structural properties and containment navigation properties leading back to the property’s declaring type, the finiteness condition for structured types demands that at least one property in this chain MUST be nullable or collection-valued.

If the type is a collection, an arbitrary number of entities can be related. Otherwise there is at most one related entity.

The related entities MUST be of the specified entity type or one of its subtypes.

For a collection-valued containment navigation property the specified entity type MUST have a key defined.

A collection-valued navigation property MAY be annotated with the Core.Ordered term, defined in OData-VocCore, to specify that it supports a stable ordering.

A collection-valued navigation property MAY be annotated with the Core.PositionalInsert term, defined in OData-VocCore, to specify that it supports inserting items into a specific ordinal position.

A Boolean value specifying whether the declaring type MAY have no related entity. If false, instances of the declaring structured type MUST always have a related entity.

Nullable MUST NOT be specified for a collection-valued navigation property, a collection is allowed to have zero items.

A navigation property of an entity type MAY specify a partner navigation property. Navigation properties of complex types MUST NOT specify a partner.

If specified, the partner navigation property is identified by a path relative to the entity type specified as the type of the navigation property. This path MUST lead to a navigation property defined on that type or a derived type. The path MAY traverse complex types, including derived complex types, but MUST NOT traverse any navigation properties. The type of the partner navigation property MUST be the declaring entity type of the current navigation property or one of its parent entity types.

If the partner navigation property is single-valued, it MUST lead back to the source entity from all related entities. If the partner navigation property is collection-valued, the source entity MUST be part of that collection.

If no partner navigation property is specified, no assumptions can be made as to whether one of the navigation properties on the target type will lead back to the source entity.

If a partner navigation property is specified, this partner navigation property MUST either specify the current navigation property as its partner to define a bi-directional relationship or it MUST NOT specify a partner navigation property. The latter can occur if the partner navigation property is defined on a complex type, or if the current navigation property is defined on a type derived from the type of the partner navigation property.

A navigation property MAY indicate that instances of its declaring structured type contain the targets of the navigation property, in which case the navigation property is called a containment navigation property.

Containment navigation properties define an implicit entity set for each instance of its declaring structured type. This implicit entity set is identified by the read URL of the navigation property for that structured type instance.

Instances of the structured type that declares the navigation property, either directly or indirectly via a property of complex type, contain the entities referenced by the containment navigation property. The canonical URL for contained entities is the canonical URL of the containing instance, followed by the path segment of the navigation property and the key of the contained entity, see OData-URL, section 4.3.2.

Entity types used in collection-valued containment navigation properties MUST have a key defined.

For items of an ordered collection of complex types (those annotated with the Core.Ordered term defined in OData-VocCore the canonical URL of the item is the canonical URL of the collection appended with a segment containing the zero-based ordinal of the item. Items within in an unordered collection of complex types do not have a canonical URL. Services that support unordered collections of complex types declaring a containment navigation property, either directly or indirectly via a property of complex type, MUST specify the URL for the navigation link within a payload representing that item, according to format-specific rules.

OData 4.0 responses MUST NOT specify a complex type declaring a containment navigation property as the type of a collection-valued property.

An entity cannot be referenced by more than one containment relationship, and cannot both belong to an entity set declared within the entity container and be referenced by a containment relationship.

Containment navigation properties MUST NOT be specified as the last path segment in the path of a navigation property binding.

When a containment navigation property navigates between entity types in the same inheritance hierarchy, the containment is called recursive.

Containment navigation properties MAY specify a partner navigation property. If the containment is recursive, the relationship defines a tree, thus the partner navigation property MUST be nullable (for the root of the tree) and single-valued (for the parent of a non-root entity). If the containment is not recursive, the partner navigation property MUST NOT be nullable.

An entity type inheritance chain MUST NOT contain more than one navigation property with a partner navigation property that is a containment navigation property.

Note: without a partner navigation property, there is no reliable way for a client to determine which entity contains a given contained entity. This may lead to problems for clients if the contained entity can also be reached via a non-containment navigation path.

A single-valued navigation property MAY define one or more referential constraints. A referential constraint asserts that the dependent property (the property defined on the structured type declaring the navigation property) MUST have the same value as the principal property (the referenced property declared on the entity type that is the target of the navigation). Elsewhere this specification calls the dependent property and the principal property tied to each other.

The type of the dependent property MUST match the type of the principal property, or both types MUST be complex types.

If the principal property references an entity, then the dependent property must reference the same entity.

If the principal property’s value is a complex type instance, then the dependent property’s value must be a complex type instance with the same properties, each with the same values.

If the navigation property on which the referential constraint is defined is nullable, or the principal property is nullable, then the dependent property MUST also be nullable. If both the navigation property and the principal property are not nullable, then the dependent property MUST NOT be nullable.

"Product": {
  "$Kind": "EntityType",
  …
  "CategoryID": {},
  "CategoryKind": {},
  "Category": {
    "$Kind": "NavigationProperty",
    "$Type": "self.Category",
    "$Partner": "Products",
    "$ReferentialConstraint": {
      "CategoryID": "ID",
      "CategoryKind": "Kind",
      "CategoryKind@Core.Description": "Referential Constraint to non-key property"
    }
  }
},
"Category": {
  "$Kind": "EntityType",
  "$Key": [
    "ID"
  ],
  "ID": {},
  "Kind": {
    "$Nullable": true
  },
  …
}

A navigation property MAY define an on-delete action that describes the action the service will take on related entities when the entity on which the navigation property is defined is deleted.

The action can have one of the following values:

• Cascade, meaning the related entities will be deleted if the source entity is deleted,
• None, meaning a DELETE request on a source entity with related entities will fail,
• SetNull, meaning all properties of related entities that are tied to properties of the source entity via a referential constraint and that do not participate in other referential constraints will be set to null,
• SetDefault, meaning all properties of related entities that are tied to properties of the source entity via a referential constraint and that do not participate in other referential constraints will be set to their default value.

If no on-delete action is specified, the action taken by the service is not predictable by the client and could vary per entity.

"Category": {
  "$Kind": "EntityType",
  …
  "Products": {
    "$Kind": "NavigationProperty",
    "$Collection": true,
    "$Type": "self.Product",
    "$Partner": "Category",
    "$OnDelete": "Cascade",
    "$OnDelete@Core.Description": "Delete all products in this category"
  }
}

A complex type can inherit from another complex type by specifying it as its base type.

A complex type inherits the structural and navigation properties of its base type.

A complex type MUST NOT introduce an inheritance cycle by specifying a base type.

The rules for annotations of derived complex types are described in section 14.2.

A complex type MAY indicate that it is abstract and cannot have instances.

A complex type MAY indicate that it is open and allows clients to add properties dynamically to instances of the type by specifying uniquely named property values in the payload used to insert or update an instance of the type.

A complex type derived from an open complex type MUST indicate that it is also open.

Note: structural and navigation properties MAY be returned by the service on instances of any structured type, whether or not the type is marked as open. Clients MUST always be prepared to deal with additional properties on instances of any structured type, see OData-Protocol, section 3.

An enumeration type MAY specify one of Edm.Byte, Edm.SByte, Edm.Int16, Edm.Int32, or Edm.Int64 as its underlying type.

If not explicitly specified, Edm.Int32 is used as the underlying type.

An enumeration type MAY indicate that the enumeration type allows multiple members to be selected simultaneously.

If not explicitly specified, only one enumeration type member MAY be selected simultaneously.

"Pattern": {
  "$Kind": "EnumType",
  "$UnderlyingType": "Edm.Int32",
  "$IsFlags": true,
  "Plain": 0,
  "Red": 1,
  "Blue": 2,
  "Yellow": 4,
  "Solid": 8,
  "Striped": 16,
  "SolidRed": 9,
  "SolidBlue": 10,
  "SolidYellow": 12,
  "RedBlueStriped": 19,
  "RedYellowStriped": 21,
  "BlueYellowStriped": 22
}

Enumeration type values consist of discrete members.

Each member is identified by its name, a simple identifier that MUST be unique within the enumeration type. Names are case-sensitive, but service authors SHOULD NOT choose names that differ only in case.

Each member MUST specify an associated numeric value that MUST be a valid value for the underlying type of the enumeration type.

Enumeration types can have multiple members with the same value. Members with the same numeric value compare as equal, and members with the same numeric value can be used interchangeably.

Enumeration members are sorted by their numeric value.

For flag enumeration types the combined numeric value of simultaneously selected members is the bitwise OR of the discrete numeric member values.

"ShippingMethod": {
  "$Kind": "EnumType",
  "FirstClass": 0,
  "FirstClass@Core.Description": "Shipped with highest priority",
  "TwoDay": 1,
  "TwoDay@Core.Description": "Shipped within two days",
  "Overnight": 2,
  "Overnight@Core.Description": "Shipped overnight",
  "@Core.Description": "Method of shipping"
}

The underlying type of a type definition MUST be a primitive type that MUST NOT be another type definition.

The type definition MAY specify facets applicable to the underlying type. Possible facets are: $MaxLength, $Unicode, $Precision, $Scale, or $SRID.

Additional facets appropriate for the underlying type MAY be specified when the type definition is used but the facets specified in the type definition MUST NOT be re-specified.

For a type definition with underlying type Edm.PrimitiveType no facets are applicable, neither in the definition itself nor when the type definition is used, and these should be ignored by the client.

Where type definitions are used, the type definition is returned in place of the primitive type wherever the type is specified in a response.

Actions are service-defined operations that MAY have observable side effects and MAY return a single instance or a collection of instances of any type.

The action’s name is a simple identifier that MUST be unique within its schema.

Actions cannot be composed with additional path segments.

An action MAY specify a return type that MUST be a primitive, entity or complex type, or a collection of primitive, entity or complex types in scope.

An action MAY define parameters used during the execution of the action.

Bound actions support overloading (multiple actions having the same name within the same schema) by binding parameter type. The combination of action name and the binding parameter type MUST be unique within a schema.

Unbound actions do not support overloads. The names of all unbound actions MUST be unique within a schema.

An unbound action MAY have the same name as a bound action.

Functions are service-defined operations that MUST NOT have observable side effects and MUST return a single instance or a collection of instances of any type.

The function’s name is a simple identifier that MUST be unique within its schema.

Functions MAY be composable.

The function MUST specify a return type which MUST be a primitive, entity or complex type, or a collection of primitive, entity or complex types in scope.

A function MAY define parameters used during the execution of the function.

Bound functions support overloading (multiple functions having the same name within the same schema) subject to the following rules:

• The combination of function name, binding parameter type, and unordered set of non-binding parameter names MUST be unique within a schema.
• The combination of function name, binding parameter type, and ordered set of parameter types MUST be unique within a schema.
• All bound functions with the same function name and binding parameter type within a schema MUST specify the same return type.

Unbound functions support overloading subject to the following rules:

• The combination of function name and unordered set of parameter names MUST be unique within a schema.
• The combination of function name and ordered set of parameter types MUST be unique within a schema.
• All unbound functions with the same function name within a schema MUST specify the same return type.

An unbound function MAY have the same name as a bound function.

Note that type definitions can be used to disambiguate overloads for both bound and unbound functions, even if they specify the same underlying type.

An action or function overload MAY indicate that it is bound. If not explicitly indicated, it is unbound.

Bound actions or functions are invoked on resources matching the type of the binding parameter. The binding parameter can be of any type, and it MAY be nullable.

Unbound actions are invoked from the entity container through an action import.

Unbound functions are invoked as static functions within a common expression (see OData-URL, section 5.1.1), or from the entity container through a function import.

Bound actions and functions that return an entity or a collection of entities MAY specify an entity set path if the entity set of the returned entities depends on the entity set of the binding parameter value.

The entity set path consists of a series of segments joined together with forward slashes.

The first segment of the entity set path MUST be the name of the binding parameter. The remaining segments of the entity set path MUST represent navigation segments or type casts.

A navigation segment names the simple identifier of the navigation property to be traversed. A type-cast segment names the qualified name of the entity type that should be returned from the type cast.

A function MAY indicate that it is composable. If not explicitly indicated, it is not composable.

A composable function can be invoked with additional path segments or key predicates appended to the resource path that identifies the composable function, and with system query options as appropriate for the type returned by the composable function.

The return type of an action or function overload MAY be any type in scope, or a collection of any type in scope.

The facets MaxLength, Precision, Scale, and SRID can be used as appropriate to specify value restrictions of the return type, as well as the Unicode facet for 4.01 or greater payloads.

For a single-valued return type the facets apply to the returned value. For a collection-valued return type the facets apply to the items in the returned collection.

Annotation Core.IsDelta

An action or function that returns a single entity or a collection of entities MAY return results as a delta payload. This is indicated by annotating the return type with the term Core.IsDelta.

Delta payloads represent changes between two versions of data and, in addition to current values, MAY include deleted entities as well as changes to related entities and relationships, according to the format-specific delta representation.

An action or function overload MAY specify parameters.

A bound action or function overload MUST specify at least one parameter; the first parameter is its binding parameter. The order of parameters MUST NOT change unless the schema version changes.

Each parameter MUST have a name that is a simple identifier. The parameter name MUST be unique within the action or function overload.

The parameter MUST specify a type. It MAY be any type in scope, or a collection of any type in scope.

The facets MaxLength, Precision, Scale, or SRID can be used as appropriate to specify value restrictions of the parameter, as well as the Unicode facet for 4.01 or greater payloads.

For single-valued parameters the facets apply to the parameter value. If the parameter value is a collection, the facets apply to the items in the collection.

Annotation Core.OptionalParameter

A parameter that is annotated with the term Core.OptionalParameter MAY be omitted when invoking the function or action.

All parameters marked as optional MUST come after any parameters not marked as optional. The binding parameter MUST NOT be marked as optional.

"TopSellingProducts": [
  {
    "$Kind": "Function",
    "$Parameter": [
      {
        "$Name": "Year",
        "$Nullable": true,
        "$Type": "Edm.Decimal",
        "$Precision": 4,
        "$Scale": 0
      }
    ],
    "$ReturnType": {
      "$Collection": true,
      "$Type": "self.Product"
    }
  }
]

Annotation Core.IsDelta

A parameter that accepts a single entity or a collection of entities MAY accept a delta representation. This is indicated by annotating the parameter with the term Core.IsDelta.

Deltas represent changes between two versions of data and, in addition to current values, MAY include deleted entities as well as changes to related entities and relationships, according to the format-specific delta representation.

An entity container MAY specify that it extends another entity container in scope. All children of the “base” entity container are added to the “extending” entity container.

If the “extending” entity container defines an entity set with the same name as defined in any of its “base” containers, then the entity set’s type MUST specify an entity type derived from the entity type specified for the identically named entity set in the “base” container. The same holds for singletons. Action imports and function imports cannot be redefined, nor can the “extending” container define a child with the same name as a child of a different kind in a “base” container.

Note: services SHOULD NOT introduce cycles by extending entity containers. Clients should be prepared to process cycles introduced by extending entity containers.

"Extending": {
  "$Kind": "EntityContainer",
  "$Extends": "Some.Other.Schema.Base",
   …
}

Entity sets are top-level collection-valued resources.

An entity set is identified by its name, a simple identifier that MUST be unique within its entity container.

An entity set MUST specify a type that MUST be an entity type in scope.

An entity set MUST contain only instances of its specified entity type or its subtypes. The entity type MAY be abstract but MUST have a key defined.

An entity set MAY indicate whether it is included in the service document. If not explicitly indicated, it is included.

Entity sets that cannot be queried without specifying additional query options SHOULD NOT be included in the service document.

Singletons are top-level single-valued resources.

A singleton is identified by its name, a simple identifier that MUST be unique within its entity container.

A singleton MUST specify a type that MUST be an entity type in scope.

A singleton MUST reference an instance its entity type.

If the entity type of an entity set or singleton declares navigation properties, a navigation property binding allows describing which entity set or singleton will contain the related entities.

An entity set or a singleton SHOULD contain a navigation property binding for each non-containment navigation property that can be reached from the entity type through a sequence of type casts, complex properties, or containment navigation properties.

If omitted, clients MUST assume that the target entity set or singleton can vary per related entity.

"Categories": {
  "$Collection": true,
  "$Type": "self.Category",
  "$NavigationPropertyBinding": {
    "Products": "SomeSet"
  }
}

"Categories": {
  "$Collection": true,
  "$Type": "self.Category",
  "$NavigationPropertyBinding": {
    "Products": "SomeModel.SomeContainer/SomeSet"
  }
}

"Categories": {
  "$Collection": true,
  "$Type": "self.Category",
  "$NavigationPropertyBinding": {
    "Products/Supplier": "Suppliers"
  }
}

Action imports sets are top-level resources that are never included in the service document.

An action import is identified by its name, a simple identifier that MUST be unique within its entity container.

An action import MUST specify the name of an unbound action in scope.

If the imported action returns an entity or a collection of entities, a simple identifier or target path value MAY be specified to identify the entity set that contains the returned entities. If a simple identifier is specified, it MUST resolve to an entity set defined in the same entity container. If a target path is specified, it MUST resolve to an entity set in scope.

Function imports sets are top-level resources.

A function import is identified by its name, a simple identifier that MUST be unique within its entity container.

A function import MUST specify the name of an unbound function in scope. All unbound overloads of the imported function can be invoked from the entity container.

If the imported function returns an entity or a collection of entities, a simple identifier or target path value MAY be specified to identify the entity set that contains the returned entities. If a simple identifier is specified, it MUST resolve to an entity set defined in the same entity container. If a target path is specified, it MUST resolve to an entity set in scope.

A function import for a parameterless function MAY indicate whether it is included in the service document. If not explicitly indicated, it is not included.

A term allows annotating a model element or OData resource representation with additional data.

The term’s name is a simple identifier that MUST be unique within its schema.

The term’s type MUST be a type in scope, or a collection of a type in scope.

"IsURL": {
  "$Kind": "Term",
  "$Type": "Core.Tag",
  "$DefaultValue": true,
  "$AppliesTo": [
    "Property",
    "Term"
  ],
  "@Core.Description": "Properties and terms annotated with this term MUST contain a valid URL",
  "@Core.RequiresType": "Edm.String"
}

An annotation applies a term to a model element and defines how to calculate a value for the term application. Both term and model element MUST be in scope. Section 14.1.2 specifies which model elements MAY be annotated with a term.

The value of an annotation is specified as an annotation expression, which is either a constant expression representing a constant value, or a dynamic expression. The most common construct for assigning an annotation value is a path expression that refers to a property of the same or a related structured type.

"AmountInReportingCurrency": {
  "$Nullable": true,
  "$Type": "Edm.Decimal",
  "$Scale": 0,
  "@Measures.ISOCurrency": "USD",
  "@Measures.ISOCurrency@Core.Description": "The parent company's currency"
},
"AmountInTransactionCurrency": {
  "$Nullable": true,
  "$Type": "Edm.Decimal",
  "$Scale": 0,
  "@Measures.ISOCurrency": {
    "$Path": "Currency"
  }
},
"Currency": {
  "$Nullable": true,
  "$MaxLength": 3
}

If an entity type or complex type is annotated with a term that itself has a structured type, an instance of the annotated type may be viewed as an “instance” of the term, and the qualified term name may be used as a term-cast segment in path expressions.

Structured types “inherit” annotations from their direct or indirect base types. If both the type and one of its base types is annotated with the same term and qualifier, the annotation on the type completely replaces the annotation on the base type; structured or collection-valued annotation values are not merged. Similarly, properties of a structured type inherit annotations from identically named properties of a base type.

It is up to the definition of a term to specify whether and how annotations with this term propagate to places where the annotated model element is used, and whether they can be overridden. E.g. a “Label” annotation for a UI can propagate from a type definition to all properties using that type definition and may be overridden at each property with a more specific label, whereas an annotation marking a type definition as containing a phone number will propagate to all using properties but may not be overridden.

"@UI.DisplayName#Tablet": {
  "$Path": "FirstName"
}

MySchema.MyAction(MySchema.MyBindingType) 
MySchema.MyAction(Collection(MySchema.BindingType)) 
MySchema.MyAction()

MySchema.MyAction

MySchema.MyEntityContainer/MyActionImport

MySchema.MyEntityType/@MyVocabulary.MyTerm 
MySchema.MyEntityType/@MyVocabulary.MyTerm#MyQualifier

MySchema.MyComplexType

MySchema.MyEntityContainer

MySchema.MyEntityContainer/MyEntitySet

MySchema.MyEntityType

MySchema.MyEnumType

MySchema.MyEnumType/MyMember

MySchema.MyFunction(MySchema.MyBindingParamType, 
  First.NonBinding.ParamType) 
MySchema.MyFunction(First.NonBinding.ParamType, 
  Second.NonBinding.ParamType)

MySchema.MyFunction

MySchema.MyEntityContainer/MyFunctionImport

MySchema.MyEntityContainer/MyEntitySet 
  /MyNavigationProperty 
MySchema.MyEntityContainer/MyEntitySet 
  /MySchema.MyEntityType/MyNavProperty 
MySchema.MyEntityContainer/MyEntitySet 
  /MyComplexProperty/MyNavProperty 
MySchema.MyEntityContainer/MySingleton 
  /MyComplexProperty/MyNavProperty

MySchema.MyEntityType/MyNavigationProperty 
MySchema.MyComplexType/MyNavigationProperty

MySchema.MyEntityContainer/MyFunctionImport/MyParameter

MySchema.MyFunction/MyParameter

MySchema.MyEntityContainer/MyEntitySet 
 /MyProperty 
MySchema.MyEntityContainer/MyEntitySet 
 /MySchema.MyEntityType/MyProperty 
MySchema.MyEntityContainer/MyEntitySet 
  /MyComplexProperty/MyProperty

MySchema.MyEntityType/MyProperty 
MySchema.MyComplexType/MyProperty

MySchema.MyEntityContainer/MyFunctionImport/$ReturnType

MySchema.MyFunction/$ReturnType 
MySchema.MyFunction(MySchema.MyBindingParamType, 
  First.NonBinding.ParamType)/$ReturnType

MySchema.MyEntityContainer/MySingleton

MySchema.MyTerm

MySchema.MyTypeDefinition

Constant expressions allow assigning a constant value to an applied term.

Primitive values of various types are represented as strings, therefore their type cannot be inferred from the constant expression alone. If such an ambiguous constant expression is an operand of a larger expression, clients MUST assume that the operand has the type demanded by the larger expression, for example, in a client-side function or in a comparison with another operand of known type. (In the $Le comparison in example 75 Duration is of type Edm.Duration, therefore the constant expression "PT1H" is a duration, not a string.)

"@UI.Thumbnail": "T0RhdGE"

"@UI.ReadOnly": true

"@vCard.birthDay": "2000-01-01"

"@UI.LastUpdated": "2000-01-01T16:00:00.000Z"

"@UI.Width": 3.14

"@UI.Width": "3.14"

"@task.duration": "P7D"

"@self.HasPattern": "1"

"@self.HasPattern": "Red"

"@self.HasPattern": "17"

"@self.HasPattern": "Red,Striped"

"@UI.FloatWidth": 3.14

"@UI.FloatWidth": "INF"

"@UI.Id": "21EC2020-3AEA-1069-A2DD-08002B30309D"

"@An.Int": 42

"@A.Very.Long.Int": "9007199254740992"

"@UI.DisplayName": "Product Catalog"

"@UI.EndTime": "21:45:00"

"Location": { "type": "Point", "coordinates": [142.1,64.1] }

"JsonStream": { "foo":true,"bar":42 },
"JsonStream@Core.MediaType": "application/json",

"TextStream": "Hello World!",
"TextStream@Core.MediaType": "text/plain",

"OtherStream": "T0RhdGE",
"OtherStream@Core.MediaType": "application/octet-stream"

Dynamic expressions allow assigning a calculated value to an applied term.

/My.Schema.MyEntityContainer/MyEntitySet

Address/City

…/self.Manager/…

…/@Capabilities.SortRestrictions/…

…/Orders/Items/Product/…

…/Addresses/Street

…/Addresses/$count

…/Items@Core.Description

…/Items/@Core.Description

/self.container/SettingsCollection('FeatureXxx')/IsAvailable

/self.container/Products(ID=ProductID)/Name

Addresses/1

Addresses/-1/Street

"self": {
  "A": {
    "$Kind": "EntityType",
    "A1": {
      "$Type": "Edm.Boolean"
    },
    "A2": {
      "$Type": "self.B"
      "@Core.Description@Core.IsLanguageDependent": {
        "$Path": "A1"
      },
      "@Core.Description": "…"
    }
  },
  "B": {
    "$Kind": "ComplexType",
    "B1": {
      "$Type": "Edm.Boolean"
    }
  },

  "Container": {
    "$Kind": "EntityContainer",
    "SetA": {
      "$Collection": true,
      "$Type": "self.A"
    }
  },
  "$Annotations": {
    "self.Container/SetA/A2": {
      "@Core.Description#viaSet@Core.IsLanguageDependent": {
        "$Path": "B1"
      },
      "@Core.Description#viaSet": "…"
    },
    "self.Container/SetA/A2/@Core.Description#viaSet": {
      "@Core.IsLanguageDependent": {
        "$Path": "B1"
      }
    },

    "self.A/A2": {
      "@Core.Description#external@Core.IsLanguageDependent": {
        "$Path": "A1"
      },
      "@Core.Description#external": "…"
    },
    "self.A/A2/@Core.Description": {
      "@Core.IsLanguageDependent": {
        "$Path": "A1"
      }
    }
  }
}

"@UI.ReferenceFacet": "Product/Supplier/@UI.LineItem",
"@UI.CollectionFacet#Contacts": [
  "Supplier/@Communication.Contact",
  "Customer/@Communication.Contact"
]

"@org.example.MyFavoriteModelElement": "/self.someAction"

"@UI.HyperLink": "Supplier",
"@Capabilities.UpdateRestrictions": {
  "NonUpdatableNavigationProperties": [
    "Supplier",
    "Category"
  ]
}

"@UI.RefreshOnChangeOf": "ChangedAt",
"@Capabilities.UpdateRestrictions": {
  "NonUpdatableProperties": [
    "CreatedAt",
    "ChangedAt"
  ]
}

"@UI.DisplayName": {
  "$Path": "FirstName"
},
"@UI.DisplayName#second": {
  "$Path": "@vCard.Address#work/FullName"
}

{
  "$And": [
    {
      "$Path": "IsMale"
    },
    {
      "$Path": "IsMarried"
    }
  ]
},
{
  "$Or": [
    {
      "$Path": "IsMale"
    },
    {
      "$Path": "IsMarried"
    }
  ]
},
{
  "$Not": {
    "$Path": "IsMale"
  }
},
{
  "$Eq": [
    null,
    {
      "$Path": "IsMale"
    }
  ]
},
{
  "$Ne": [
    null,
    {
      "$Path": "IsMale"
    }
  ]
},
{
  "$Gt": [
    {
      "$Path": "Price"
    },
    20
  ]
},
{
  "$Ge": [
    {
      "$Path": "Price"
    },
    10
  ]
},
{
  "$Lt": [
    {
      "$Path": "Price"
    },
    20
  ]
},
{
  "$Le": [
    {
      "$Path": "Duration"
    },
    "PT1H"
  ]
},
{
  "$Has": [
    {
      "$Path": "Fabric"
    },
    "Red"
  ]
},
{
  "$In": [
    {
      "$Path": "Size"
    },
    [
      "XS",
      "S"
    ]
  ]
}

{
  "$Add": [
    {
      "$Path": "StartDate"
    },
    {
      "$Path": "Duration"
    }
  ]
},
{
  "$Sub": [
    {
      "$Path": "Revenue"
    },
    {
      "$Path": "Cost"
    }
  ]
},
{
  "$Neg": {
    "$Path": "Height"
  }
},
{
  "$Mul": [
    {
      "$Path": "NetPrice"
    },
    {
      "$Path": "TaxRate"
    }
  ]
},
{
  "$Div": [
    {
      "$Path": "Quantity"
    },
    {
      "$Path": "QuantityPerParcel"
    }
  ]
},
{
  "$DivBy": [
    {
      "$Path": "Quantity"
    },
    {
      "$Path": "QuantityPerParcel"
    }
  ]
},
{
  "$Mod": [
    {
      "$Path": "Quantity"
    },
    {
      "$Path": "QuantityPerParcel"
    }
  ]
}

"@UI.DisplayName": {
  "$Apply": [
    "Product: ",
    {
      "$Apply": [
        {
          "$Path": "ProductName"
        },
        {
          "$Apply": [
            " (",
            {
              "$Apply": [
                {
                  "$Path": "Available/Quantity"
                },
                {
                  "$Apply": [
                    " ",
                    {
                      "$Apply": [
                        {
                          "$Path": "Available/Unit"
                        },
                        " available)"
                      ],
                      "$Function": "odata.concat"
                    }
                  ],
                  "$Function": "odata.concat"
                }
              ],
              "$Function": "odata.concat"
            }
          ],
          "$Function": "odata.concat"
        }
      ],
      "$Function": "odata.concat"
    }
  ],
  "$Function": "odata.concat"
}

{
  "$Apply": [
    "http://host/someAPI/Actors/{actorName}/CV",
    {
      "$LabeledElement": {
        "$Path": "Actor/Name"
      },
      "$Name": "self.actorName"
    }
  ],
  "$Function": "odata.fillUriTemplate"
}

{
  "$Apply": [
    {
      "$Path": "FirstName"
    },
    "^[^b-d]+$"
  ],
  "$Function": "odata.matchesPattern"
}