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 as these are more common than , and the member 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 SHOULD be omitted if they have the default value. JSON Schema Definition The structure of CSDL JSON documents can be verified with the JSON 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.
It MAY contain . Example 81: "@UI.DisplayName": { "$LabeledElement": { "$Path": "FirstName" }, "$Name": "CustomerFirstName" } Labeled Element Reference The labeled element reference expression MUST specify the of a in scope and returns the value of the identified labeled element expression as its value. $LabeledElementReference Labeled element reference expressions are represented as an object with a member $LabeledElementReference whose value is a string containing an qualified name. Example 82: "@UI.DisplayName": { "$LabeledElementReference": "self.CustomerFirstName" } Null The null expression returns an untyped null value. The null expression MAY be annotated. Null expressions that do not contain annotations are represented as the literal null. Example 83: "@UI.DisplayName": null, $Null Null expression containing are represented as an object with a member $Null value is the literal null. Example 84: "@UI.Address": { "$Null": null, "@self.Reason": "Private" } Record The record expression enables a new entity type or complex type instance to be constructed. A record expression MAY specify the structured type of its result, which MUST be an entity type or complex type in scope. If not explicitly specified, the type is derived from the expression’s context. A record expression contains zero or more property value expressions. For each single-valued structural or navigation property of the record expression’s type that is neither nullable nor specifies a default value a property value expression MUST be provided. The only exception is if the record expression is the value of an annotation for a term that has a whose type is structured and directly or indirectly inherits from the type of its base term. In this case, property values that already have been specified in the annotation for the base term or its base term etc. need not be specified again. For collection-valued properties the absence of a property value expression is equivalent to specifying an empty collection as its value.
Revision History Revision Date Editor Changes Made Working Draft 01 2016-11-16 Ralf Handl Initial version Committee Specification Draft 01 2017-06-08 Michael Pizzo Ralf Handl Integrated 4.01 features Committee Specification 02 2017-09-22 Michael Ralf Incorporated review feedback Changed defaults of $Nullable, $Scale, and $Precision Committee Specification Draft 03 2017-11-10 Michael Pizzo Ralf Handl Incorporated review feedback Stable order of action and function parameters