From dcd871dba71849bbd43f5688c2bd421d1ed38c03 Mon Sep 17 00:00:00 2001 From: Ralf Handl Date: Wed, 8 Nov 2023 17:16:30 +0100 Subject: [PATCH] Use -- for en-dashes and --- for em-dashes (#206) Fixes #205 --- docs/odata-csdl-json/odata-csdl-json.html | 156 +++++++------- docs/odata-csdl-json/odata-csdl-json.md | 12 +- docs/odata-csdl-xml/odata-csdl-xml.html | 180 ++++++++--------- docs/odata-csdl-xml/odata-csdl-xml.md | 12 +- .../odata-data-aggregation-ext.html | 92 ++++----- .../odata-data-aggregation-ext.md | 4 +- docs/odata-json-format/odata-json-format.html | 144 ++++++------- docs/odata-json-format/odata-json-format.md | 56 +++--- docs/odata-protocol/odata-protocol.html | 190 +++++++++--------- docs/odata-protocol/odata-protocol.md | 54 ++--- .../odata-temporal-ext.html | 116 +++++------ docs/odata-temporal-ext/odata-temporal-ext.md | 8 +- .../odata-url-conventions.html | 117 +++++------ .../odata-url-conventions.md | 60 +++--- lib/pandoc.js | 2 +- odata-csdl/0 frontmatter.md | 2 +- odata-csdl/1 Introduction.md | 8 +- odata-csdl/Appendix.md | 2 +- odata-data-aggregation-ext/0 frontmatter.md | 2 +- odata-data-aggregation-ext/1 Introduction.md | 2 +- odata-json-format/0 frontmatter.md | 2 +- odata-json-format/1 Introduction.md | 2 +- odata-json-format/15 Delta Payload.md | 50 ++--- odata-json-format/7 Structural Property.md | 2 +- odata-protocol/0 frontmatter.md | 2 +- odata-protocol/1 Introduction.md | 2 +- odata-protocol/10 Context URL.md | 6 +- odata-protocol/11 Data Service Requests.md | 24 +-- odata-protocol/11.5 Operations.md | 8 +- odata-protocol/11.7 Batch Requests.md | 4 +- odata-protocol/8 Header Fields.md | 8 +- odata-temporal-ext/0 frontmatter.md | 2 +- odata-temporal-ext/1 Introduction.md | 2 +- odata-temporal-ext/4 Temporal Requests.md | 4 +- odata-url-conventions/0 frontmatter.md | 2 +- odata-url-conventions/1 Introduction.md | 2 +- odata-url-conventions/4 Resource Path.md | 6 +- odata-url-conventions/5 Query Options.md | 48 ++--- odata-url-conventions/Appendix.md | 2 +- 39 files changed, 699 insertions(+), 698 deletions(-) diff --git a/docs/odata-csdl-json/odata-csdl-json.html b/docs/odata-csdl-json/odata-csdl-json.html index d271b7b61..64532fd2c 100644 --- a/docs/odata-csdl-json/odata-csdl-json.html +++ b/docs/odata-csdl-json/odata-csdl-json.html @@ -142,12 +142,12 @@

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://www.oasis-open.org/committees/tc_home.php?wg_abbrev=odata#technical.

-

TC members should send comments on this specification to the TC's email list. Others should send comments to the TC's public comment list, after subscribing to it by following the instructions at the "Send A Comment" button on the TC's web page at https://www.oasis-open.org/committees/odata/.

-

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.

+

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://www.oasis-open.org/committees/tc_home.php?wg_abbrev=odata#technical.

+

TC members should send comments on this specification to the TC’s email list. Others should send comments to the TC’s public comment list, after subscribing to it by following the instructions at the “Send A Comment” button on the TC’s web page at https://www.oasis-open.org/committees/odata/.

+

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.

+

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]

@@ -155,7 +155,7 @@

Citation format:

Notices

Copyright © OASIS Open 2023. 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.

+

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.

Table of Contents

@@ -407,7 +407,7 @@

Representation-Specific Headline

All other text is normative unless otherwise labeled.

Here is a customized command line which will generate HTML from this markdown file (named odata-csdl-json-v4.02-csd01.md). Line breaks are added for readability only:

-
pandoc -f gfm+tex_math_dollars+fenced_divs
+
pandoc -f gfm+tex_math_dollars+fenced_divs+smart
        -t html
        -o odata-csdl-json-v4.02-csd01.html
        -c styles/markdown-styles-v1.7.3b.css
@@ -426,7 +426,7 @@ 
Representation-Specific Headline

 
 

 
2 JSON Representation

-
OData CSDL JSON is a full representation of the OData Common Schema Definition Language in the JavaScript Object Notation (JSON) defined in RFC8259. It additionally follows the rules for "Internet JSON" (I-JSON) defined in RFC7493 for e.g. objects, numbers, date values, and duration values.

+
OData CSDL JSON is a full representation of the OData Common Schema Definition Language in the JavaScript Object Notation (JSON) defined in RFC8259. It additionally follows the rules for “Internet JSON” (I-JSON) defined in RFC7493 for e.g. objects, numbers, date values, and duration values.

 
It is an alternative to the CSDL XML representation defined in OData-CSDLXML and neither adds nor removes features.

 
2.1 Requesting the JSON Representation

 
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.

@@ -463,7 +463,7 @@ 
2.1.2.3 <
 
The metadata=none format parameter indicates that the service SHOULD omit all control information.

 
2.2 Design Considerations

 
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).

+
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.

@@ -524,7 +524,7 @@ 
3.3
 
 
 Edm.Double
-IEEE 754 binary64 floating-point number (15-17 decimal digits)
+IEEE 754 binary64 floating-point number (15–17 decimal digits)
 
 
 Edm.Duration
@@ -552,7 +552,7 @@ 
3.3
 
 
 Edm.Single
-IEEE 754 binary32 floating-point number (6-9 decimal digits)
+IEEE 754 binary32 floating-point number (6–9 decimal digits)
 
 
 Edm.Stream
@@ -564,7 +564,7 @@ 
3.3
 
 
 Edm.TimeOfDay
-Clock time 00:00-23:59:59.999999999999
+Clock time 00:00–23:59:59.999999999999
 
 
 Edm.Geography
@@ -635,7 +635,7 @@ 
3.3
 
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 the 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 or for non-binding parameters to functions or actions.

-
Some of these types allow facets, defined in section "Type Facets".

+
Some of these types allow facets, defined in section “Type Facets”.

 
See rule primitiveLiteral in OData-ABNF for the representation of primitive type values in URLs and OData-JSON for the representation in requests and responses.

 
3.4 Type Facets

 
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.

@@ -650,7 +650,7 @@ 
 $MaxLengt
 
Note: OData-CSDL-XML defines a symbolic value max that is only allowed in OData 4.0 responses. This symbolic value is not allowed in CDSL JSON documents at all. Services MAY instead specify the concrete maximum length supported for the type by the service or omit the member entirely.

3.4.2 Precision

-

For a decimal value: the maximum number of significant decimal digits of the model element's value; it MUST be a positive integer.

+

For a decimal value: the maximum number of significant decimal digits of the model element’s value; it MUST be a positive integer.

For a temporal value (datetime-with-timezone-offset, duration, or time-of-day): the number of decimal places allowed in the seconds portion of the value; it MUST be a non-negative integer between zero and twelve.

Note: service authors SHOULD be aware that some clients are unable to support a precision greater than 28 for decimal values and 7 for temporal values. Client developers MUST be aware of the potential for data loss when round-tripping values of greater precision. Updating via PATCH and exclusively specifying modified values will reduce the risk for unintended data loss.

Note: model elements with duration values and a granularity less than seconds (e.g. minutes, hours, days) can be annotated with term Measures.DurationGranularity, see OData-VocMeasures.

@@ -742,7 +742,7 @@

Path Expressions" for details.

+

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 “Path Expressions” for details.

3.7 Annotations

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.

@@ -812,7 +812,7 @@

4.1 Reference

-

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 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 OData-Protocol, SHOULD be used when retrieving the referenced schema document.

@@ -895,10 +895,10 @@

$Alias

4.3 Included Annotations

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.

+

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.

+

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.

$IncludeAnnotations

@@ -952,7 +952,7 @@

5 Schema

One or more schemas describe the entity model exposed by an OData service. The schema acts as a namespace for elements of the entity model such as entity types, complex types, enumerations and terms.

A schema is identified by a namespace. Schema namespaces MUST be unique within the scope of a document and SHOULD be globally unique. A schema cannot span more than one document.

-

The schema's namespace is combined with the name of elements in the schema to create unique qualified names, so identifiers that are used to name types MUST be unique within a namespace to prevent ambiguity.

+

The schema’s namespace is combined with the name of elements in the schema to create unique qualified names, so identifiers that are used to name types MUST be unique within a namespace to prevent ambiguity.

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

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

@@ -1002,7 +1002,7 @@

$Annotations

6 Entity Type

Entity types are nominal structured types with a key that consists of one or more references to structural properties. An entity type is the template for an entity: any uniquely identifiable record such as a customer or order.

-

The entity type's name is a simple identifier that MUST be unique within its schema.

+

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

An entity type can define two types of properties. A structural property is a named reference to a primitive, complex, or enumeration type, or a collection of primitive, complex, or enumeration types. A navigation property is a named reference to another entity type or collection of entity types.

All properties MUST have a unique name within an entity type. Properties MUST NOT have the same name as the declaring entity type. They MAY have the same name as one of the direct or indirect base types or derived types.

@@ -1085,8 +1085,8 @@

6.5 Key

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 (whether or not it is marked as abstract) MAY define a key only if it doesn't inherit one.

-

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.

+

An entity type (whether or not it is marked as abstract) MAY define a key only if it doesn’t inherit one.

+

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
    • @@ -1108,7 +1108,7 @@

    6.5 Key

    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.

    +

    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.

    $Key

    The value of $Key is an array with one item per key property.

    @@ -1192,7 +1192,7 @@

    type.

    -

    The property's name MUST be a simple identifier. It is used when referencing, serializing or deserializing the property. It MUST be unique within the set of structural and navigation properties of the declaring structured type, and MUST NOT match the name of any navigation property in any of its base types. If a structural property with the same name is defined in any of this type's base types, then the property's type MUST be a type derived from the type specified for the property of the base type and constrains this property to be of the specified subtype for instances of this structured type. The name MUST NOT match the name of any structural or navigation property of any of this type's base types for OData 4.0 responses.

    +

    The property’s name MUST be a simple identifier. It is used when referencing, serializing or deserializing the property. It MUST be unique within the set of structural and navigation properties of the declaring structured type, and MUST NOT match the name of any navigation property in any of its base types. If a structural property with the same name is defined in any of this type’s base types, then the property’s type MUST be a type derived from the type specified for the property of the base type and constrains this property to be of the specified subtype for instances of this structured type. The name MUST NOT match the name of any structural or navigation property of any of this type’s base types for OData 4.0 responses.

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

    Property Object

    @@ -1217,13 +1217,13 @@

    Property Object

    }

7.1 Type

-

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

+

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

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.

$Type and $Collection

-

For single-valued properties the value of $Type is the qualified name of the property's type.

-

For collection-valued properties the value of $Type is the qualified name of the property's item type, and the member $Collection MUST be present with the literal value true.

+

For single-valued properties the value of $Type is the qualified name of the property’s type.

+

For collection-valued properties the value of $Type is the qualified name of the property’s item type, and the member $Collection MUST be present with the literal value true.

Absence of the $Type member means the type is Edm.String. This member SHOULD be omitted for string properties to reduce document size.

@@ -1250,7 +1250,7 @@

$DefaultValue

8 Navigation Property

A navigation property allows navigation to related entities. It MUST specify a unique name as well as a type.

-

The navigation property's name MUST be a simple identifier. It is used when referencing, serializing or deserializing the navigation property. It MUST be unique within the set of structural and navigation properties of the declaring structured type, and MUST NOT match the name of any structural property in any of its base types. If a navigation property with the same name is defined in any of this type's base types, then the navigation property's type MUST be a type derived from the type specified for the navigation property of the base type, and constrains this navigation property to be of the specified subtype for instances of this structured type. The name MUST NOT match the name of any structural or navigation property of any of this type's base types for OData 4.0 responses.

+

The navigation property’s name MUST be a simple identifier. It is used when referencing, serializing or deserializing the navigation property. It MUST be unique within the set of structural and navigation properties of the declaring structured type, and MUST NOT match the name of any structural property in any of its base types. If a navigation property with the same name is defined in any of this type’s base types, then the navigation property’s type MUST be a type derived from the type specified for the navigation property of the base type, and constrains this navigation property to be of the specified subtype for instances of this structured type. The name MUST NOT match the name of any structural or navigation property of any of this type’s base types for OData 4.0 responses.

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

Navigation Property Object

@@ -1291,7 +1291,7 @@

Navig }

8.1 Navigation Property Type

-

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.

+

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 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.

@@ -1299,8 +1299,8 @@

Core.PositionalInsert term, defined in OData-VocCore, to specify that it supports inserting items into a specific ordinal position.

$Type and $Collection

-

For single-valued navigation properties the value of $Type is the qualified name of the navigation property's type.

-

For collection-valued navigation properties the value of $Type is the qualified name of the navigation property's item type, and the member $Collection MUST be present with the literal value true.

+

For single-valued navigation properties the value of $Type is the qualified name of the navigation property’s type.

+

For collection-valued navigation properties the value of $Type is the qualified name of the navigation property’s item type, and the member $Collection MUST be present with the literal value true.

8.2 Nullable Navigation Property

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.

@@ -1340,7 +1340,7 @@

$ReferentialConstraint

@@ -1410,7 +1410,7 @@

$OnDelete

9 Complex Type

Complex types are keyless nominal structured types. The lack of a key means that instances of complex types cannot be referenced, created, updated or deleted independently of an entity type. Complex types allow entity models to group properties into common structures.

-

The complex type's name is a simple identifier that MUST be unique within its schema.

+

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

A complex type can define two types of properties. A structural property is a named reference to a primitive, complex, or enumeration type, or a collection of primitive, complex, or enumeration types. A navigation property is a named reference to an entity type or a collection of entity types.

All properties MUST have a unique name within a complex type. Properties MUST NOT have the same name as the declaring complex type. They MAY have the same name as one of the direct or indirect base types or derived types.

@@ -1480,7 +1480,7 @@

$OpenType

10 Enumeration Type

Enumeration types are nominal types that represent a non-empty series of related values. Enumeration types expose these related values as members of the enumeration.

-

The enumeration type's name is a simple identifier that MUST be unique within its schema.

+

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

Although enumeration types have an underlying numeric value, the preferred representation for an enumeration value is the member name. Discrete sets of numeric values should be represented as numeric values annotated with the AllowedValues annotation defined in OData-VocCore.

Enumeration types marked as flags allow values that consist of more than one enumeration member at a time.

@@ -1566,7 +1566,7 @@

Enume

11 Type Definition

A type definition defines a specialization of one of the primitive types or of the built-in abstract type Edm.PrimitiveType.

-

The type definition's name is a simple identifier that MUST be unique within its schema.

+

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

Type definitions can be used wherever a primitive type is used (other than as the underlying type in a new type definition) and are type-comparable with their underlying types and any type definitions defined using the same underlying 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 type definition is used, and whether they can be overridden.

@@ -1612,7 +1612,7 @@

$UnderlyingTy

12 Action and Function

12.1 Action

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.

+

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.

@@ -1628,7 +1628,7 @@

Action Over

12.3 Function

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.

+

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.

@@ -1744,7 +1744,7 @@

$Nullabl

13 Entity Container

Each metadata document used to describe an OData service MUST define exactly one entity container.

-

The entity container's name is a simple identifier that MUST be unique within its schema.

+

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

Entity containers define the entity sets, singletons, function and action imports exposed by the service.

Entity set, singleton, action import, and function import names MUST be unique within an entity container.

An entity set allows access to entity type instances. Simple entity models frequently have one entity set per entity type.

@@ -1832,8 +1832,8 @@

Entity Co }

13.1 Extending an Entity Container

-

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.

+

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.

$Extends

@@ -1886,7 +1886,7 @@

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.

13.4.1 Navigation Property Path Binding

-

A navigation property binding MUST specify a path to a navigation property of the entity set's or singleton's declared entity type, or a navigation property reached through a chain of type casts, complex properties, or containment navigation properties. If the navigation property is defined on a subtype, the path MUST contain the qualified name of the subtype, followed by a forward slash, followed by the navigation property name. If the navigation property is defined on a complex type used in the definition of the entity set's entity type, the path MUST contain a forward-slash separated list of complex property names and qualified type names that describe the path leading to the navigation property.

+

A navigation property binding MUST specify a path to a navigation property of the entity set’s or singleton’s declared entity type, or a navigation property reached through a chain of type casts, complex properties, or containment navigation properties. If the navigation property is defined on a subtype, the path MUST contain the qualified name of the subtype, followed by a forward slash, followed by the navigation property name. If the navigation property is defined on a complex type used in the definition of the entity set’s entity type, the path MUST contain a forward-slash separated list of complex property names and qualified type names that describe the path leading to the navigation property.

The path can traverse one or more containment navigation properties, but the last navigation property segment MUST be a non-containment navigation property and there MUST NOT be any non-containment navigation properties prior to the final navigation property segment.

If the path traverses collection-valued complex properties or collection-valued containment navigation properties, the binding applies to all items of these collections.

If the path contains a recursive sub-path (i.e. a path leading back to the same structured type, the binding applies recursively to any positive number of cycles through that sub-path.

@@ -2018,8 +2018,8 @@

14.1 Term

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.

+

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.

Term Object

A term is represented as a member of the schema object whose name is the unqualified name of the term and whose value is an object.

@@ -2027,8 +2027,8 @@

Term ObjectIt MAY contain the members $Type, $Collection, $Nullable, $DefaultValue, $BaseTerm, $AppliesTo, $MaxLength, $Precision, $Scale, and $SRID, as well as $Unicode for 4.01 and greater payloads.

It MAY contain annotations.

$Type and $Collection

-

For single-valued terms the value of $Type is the qualified name of the term's type.

-

For collection-valued terms the value of $Type is the qualified name of the term's item type, and the member $Collection MUST be present with the literal value true.

+

For single-valued terms the value of $Type is the qualified name of the term’s type.

+

For collection-valued terms the value of $Type is the qualified name of the term’s item type, and the member $Collection MUST be present with the literal value true.

Absence of the $Type member means the type is Edm.String.

$Nullable

The value of $Nullable is one of the Boolean literals true or false. Absence of the member means false.

@@ -2239,9 +2239,9 @@

Annotation Member "$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.

+

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.

14.2.1 Qualifier

A term can be applied multiple times to the same model element by providing a qualifier to distinguish the annotations. The qualifier is a simple identifier.

The combination of target model element, term, and qualifier uniquely identifies an annotation.

@@ -2253,7 +2253,7 @@

14.2.1 Qualifier

14.2.2 Target

The target of an annotation is the model element the term is applied to.

-

The target of an annotation MAY be specified indirectly by "nesting" the annotation within the model element. Whether and how this is possible is described per model element in this specification.

+

The target of an annotation MAY be specified indirectly by “nesting” the annotation within the model element. Whether and how this is possible is described per model element in this specification.

The target of an annotation MAY also be specified directly; this allows defining an annotation in a different schema than the targeted model element.

This external targeting is only possible for model elements that are uniquely identified within their parent, and all their ancestor elements are uniquely identified within their parent.

These are the direct children of a schema with a unique name (i.e. except actions and functions whose overloads to not possess a natural identifier), and all direct children of an entity container.

@@ -2433,7 +2433,7 @@

14.3.5 Decimal

"@UI.Width": 3.14
-

Example 48: "safe" representation as a string

+

Example 48: “safe” representation as a string

"@UI.Width": "3.14"

14.3.6 Duration

@@ -2484,7 +2484,7 @@

14.3.10 Integer

"@An.Int": 42
-

Example 55: "safe" representation as a string

+

Example 55: “safe” representation as a string

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

14.3.11 String

@@ -2519,7 +2519,7 @@

14.4.1.1 Path

Example 58: absolute path to an entity set

/My.Schema.MyEntityContainer/MyEntitySet
-

Paths not starting with a forward slash are interpreted relative to the annotation target, following the rules specified in section "Path Evaluation".

+

Paths not starting with a forward slash are interpreted relative to the annotation target, following the rules specified in section “Path Evaluation”.

Example 59: relative path to a property

Address/City
@@ -2529,7 +2529,7 @@

14.4.1.1 Path

Example 60: type-cast segment

.../self.Manager/...

-

If a path segment starts with an at (@) character, it represents a term cast. The at (@) character MUST be followed by a qualified name that MAY be followed by a hash (#) character and a simple identifier. The qualified name preceding the hash character MUST resolve to a term that is in scope, the simple identifier following the hash sign is interpreted as a qualifier for the term. If the model element or instance identified by the preceding path part has not been annotated with that term (and if present, with that qualifier), the term cast evaluates to the null value. Four special terms are implicitly "annotated" for media entities and stream properties:

+

If a path segment starts with an at (@) character, it represents a term cast. The at (@) character MUST be followed by a qualified name that MAY be followed by a hash (#) character and a simple identifier. The qualified name preceding the hash character MUST resolve to a term that is in scope, the simple identifier following the hash sign is interpreted as a qualifier for the term. If the model element or instance identified by the preceding path part has not been annotated with that term (and if present, with that qualifier), the term cast evaluates to the null value. Four special terms are implicitly “annotated” for media entities and stream properties:

  • odata.mediaEditLink
  • odata.mediaReadLink
    • @@ -3145,7 +3145,7 @@

    14

    A labeled element expression MUST provide a simple identifier value as its name that MUST be unique within the schema containing the expression.

    $LabeledElement

    -

    Labeled element expressions are represented as an object with a member $LabeledElement whose value is an annotation expression, and a member $Name whose value is a string containing the labeled element's name.

    +

    Labeled element expressions are represented as an object with a member $LabeledElement whose value is an annotation expression, and a member $Name whose value is a string containing the labeled element’s name.

    It MAY contain annotations.

    @@ -3191,8 +3191,8 @@

    $Null

    14.4.12 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 base term 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.

    +

    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 base term 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.

    Record expressions are represented as objects with one member per property value expression. The member name is the property name, and the member value is the property value expression.

    @@ -3200,7 +3200,7 @@

    14.4.12 Record

    It MAY contain annotations for itself and its members. Annotations for record members are prefixed with the member name.

    -

    Example 87: this annotation "morphs" the entity type from example 13 into a structured type with two structural properties GivenName and Surname and two navigation properties DirectSupervisor and CostCenter. The first three properties simply rename properties of the annotated entity type, the fourth adds a calculated navigation property that is pointing to a different service

    +

    Example 87: this annotation “morphs” the entity type from example 13 into a structured type with two structural properties GivenName and Surname and two navigation properties DirectSupervisor and CostCenter. The first three properties simply rename properties of the annotated entity type, the fourth adds a calculated navigation property that is pointing to a different service

Non-normatively speaking it starts with a letter or underscore, followed by at most 127 letters, underscores or digits.

15.3 Qualified Name

@@ -3602,52 +3602,52 @@
[EPSG]

European Petroleum Survey Group (EPSG). http://www.epsg.org/.

[OData-ABNF]

OData ABNF Construction Rules Version 4.02.
-See link in "Additional artifacts" section on cover page.

+See link in “Additional artifacts” section on cover page.

[OData-CSDL]

OData Common Schema Definition Language (CSDL) JSON Representation Version 4.02. This document.

-

OData Common Schema Definition Language (CSDL) XML Representation Version 4.02. See link in "Related work" section on cover page.

+

OData Common Schema Definition Language (CSDL) XML Representation Version 4.02. See link in “Related work” section on cover page.

[OData-CSDL-Schema]

OData CSDL JSON Schema.
-See link in "Additional artifacts" section on cover page.

+See link in “Additional artifacts” section on cover page.

[OData-JSON]

OData JSON Format Version 4.02.
-See link in "Related work" section on cover page.

+See link in “Related work” section on cover page.

[OData-Protocol]

OData Version 4.02 Part 1: Protocol.
-See link in "Related work" section on cover page.

+See link in “Related work” section on cover page.

[OData-URL]

OData Version 4.02 Part 2: URL Conventions.
-See link in "Related work" section on cover page.

+See link in “Related work” section on cover page.

[OData-VocCore]

OData Vocabularies Version 4.0: Core Vocabulary.
-See link in "Related work" section on cover page.

+See link in “Related work” section on cover page.

[OData-VocMeasures]

OData Vocabularies Version 4.0: Measures Vocabulary.
-See link in "Related work" section on cover page.

+See link in “Related work” section on cover page.

[OData-VocValidation]

OData Vocabularies Version 4.0: Validation Vocabulary.
-See link in "Related work" section on cover page.

+See link in “Related work” section on cover page.

[RFC2119]
-

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
+

Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
https://www.rfc-editor.org/info/rfc2119.

[RFC6570]

Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, “URI Template”, RFC 6570, March 2012.
http://tools.ietf.org/html/rfc6570.

[RFC7493]
-

Bray, T., Ed., "The I-JSON Message Format", RFC7493, March 2015.
+

Bray, T., Ed., “The I-JSON Message Format”, RFC7493, March 2015.
https://tools.ietf.org/html/rfc7493.

[RFC8174]
-

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.
+

Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.
http://www.rfc-editor.org/info/rfc8174.

[RFC8259]
-

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 8259, December 2017.
+

Bray, T., Ed., “The JavaScript Object Notation (JSON) Data Interchange Format”, RFC 8259, December 2017.
http://tools.ietf.org/html/rfc8259.

[XML-Schema-2]

W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. D. Peterson, S. Gao, C. M. Sperberg-McQueen, H. S. Thompson, P. V. Biron, A. Malhotra, Editors, W3C Recommendation, 5 April 2012.
http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/. Latest version available at http://www.w3.org/TR/xmlschema11-2/.

A.2 Informative References

[OpenUI5]
-

OpenUI5 Version 1.40.10 - OData V4 Metadata JSON Format.
+

OpenUI5 Version 1.40.10 — OData V4 Metadata JSON Format.
https://openui5.hana.ondemand.com/1.40.10/#docs/guide/87aac894a40640f89920d7b2a414499b.html.

Appendix B. Table of JSON Objects and Members

@@ -3919,14 +3919,14 @@

Appendix E. Notices

Copyright © OASIS Open 2023. All Rights Reserved.

-

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

+

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the “OASIS IPR Policy”). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

-

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

+

This document and the information contained herein is provided on an “AS IS” basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

As stated in the OASIS IPR Policy, the following three paragraphs in brackets apply to OASIS Standards Final Deliverable documents (Committee Specification, Candidate OASIS Standard, OASIS Standard, or Approved Errata).

[OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Standards Final Deliverable, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this deliverable.]

[OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this OASIS Standards Final Deliverable by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this OASIS Standards Final Deliverable. OASIS may include such claims on its website, but disclaims any obligation to do so.]

-

[OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this OASIS Standards Final Deliverable or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Standards Final Deliverable, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.]

-

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. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark/ for above guidance.

+

[OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this OASIS Standards Final Deliverable or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS’ procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Standards Final Deliverable, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.]

+

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. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark/ for above guidance.

diff --git a/docs/odata-csdl-json/odata-csdl-json.md b/docs/odata-csdl-json/odata-csdl-json.md index f54551bbc..1728e1a2a 100644 --- a/docs/odata-csdl-json/odata-csdl-json.md +++ b/docs/odata-csdl-json/odata-csdl-json.md @@ -61,7 +61,7 @@ OData services are described by an Entity Model (EDM). The Common Schema Definit #### 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://www.oasis-open.org/committees/tc_home.php?wg_abbrev=odata#technical. -TC members should send comments on this specification to the TC's email list. Others should send comments to the TC's public comment list, after subscribing to it by following the instructions at the "[Send A Comment](https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=odata)" button on the TC's web page at https://www.oasis-open.org/committees/odata/. +TC members should send comments on this specification to the TC's email list. Others should send comments to the TC's public comment list, after subscribing to it by following the instructions at the "Send A Comment" button on the TC's web page at https://www.oasis-open.org/committees/odata/. This specification is provided under the [RF on RAND Terms Mode](https://www.oasis-open.org/policies-guidelines/ipr/#RF-on-RAND-Mode) of the [OASIS IPR Policy](https://www.oasis-open.org/policies-guidelines/ipr/), 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). @@ -298,7 +298,7 @@ All other text is normative unless otherwise labeled. Here is a customized command line which will generate HTML from this markdown file (named `odata-csdl-json-v4.02-csd01.md`). Line breaks are added for readability only: ``` -pandoc -f gfm+tex_math_dollars+fenced_divs +pandoc -f gfm+tex_math_dollars+fenced_divs+smart -t html -o odata-csdl-json-v4.02-csd01.html -c styles/markdown-styles-v1.7.3b.css @@ -563,17 +563,17 @@ Type|Meaning `Edm.Date` |Date without a time-zone offset `Edm.DateTimeOffset` |Date and time with a time-zone offset, no leap seconds `Edm.Decimal` |Numeric values with decimal representation -`Edm.Double` |IEEE 754 binary64 floating-point number (15-17 decimal digits) +`Edm.Double` |IEEE 754 binary64 floating-point number (15--17 decimal digits) `Edm.Duration` |Signed duration in days, hours, minutes, and (sub)seconds `Edm.Guid` |16-byte (128-bit) unique identifier `Edm.Int16` |Signed 16-bit integer `Edm.Int32` |Signed 32-bit integer `Edm.Int64` |Signed 64-bit integer `Edm.SByte` |Signed 8-bit integer -`Edm.Single` |IEEE 754 binary32 floating-point number (6-9 decimal digits) +`Edm.Single` |IEEE 754 binary32 floating-point number (6--9 decimal digits) `Edm.Stream` |Binary data stream `Edm.String` |Sequence of characters -`Edm.TimeOfDay` |Clock time 00:00-23:59:59.999999999999 +`Edm.TimeOfDay` |Clock time 00:00--23:59:59.999999999999 `Edm.Geography` |Abstract base type for all Geography types `Edm.GeographyPoint` |A point in a round-earth coordinate system `Edm.GeographyLineString` |Line string in a round-earth coordinate system @@ -5952,7 +5952,7 @@ http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/. Latest version available ## A.2 Informative References ###### [OpenUI5] -_OpenUI5 Version 1.40.10 - OData V4 Metadata JSON Format_. +_OpenUI5 Version 1.40.10 --- OData V4 Metadata JSON Format_. https://openui5.hana.ondemand.com/1.40.10/#docs/guide/87aac894a40640f89920d7b2a414499b.html. ------- diff --git a/docs/odata-csdl-xml/odata-csdl-xml.html b/docs/odata-csdl-xml/odata-csdl-xml.html index 8e564e705..a73b0e75c 100644 --- a/docs/odata-csdl-xml/odata-csdl-xml.html +++ b/docs/odata-csdl-xml/odata-csdl-xml.html @@ -142,12 +142,12 @@

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 XML Representation) specifically defines the XML 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://www.oasis-open.org/committees/tc_home.php?wg_abbrev=odata#technical.

-

TC members should send comments on this specification to the TC's email list. Others should send comments to the TC's public comment list, after subscribing to it by following the instructions at the "Send A Comment" button on the TC's web page at https://www.oasis-open.org/committees/odata/.

-

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.

+

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://www.oasis-open.org/committees/tc_home.php?wg_abbrev=odata#technical.

+

TC members should send comments on this specification to the TC’s email list. Others should send comments to the TC’s public comment list, after subscribing to it by following the instructions at the “Send A Comment” button on the TC’s web page at https://www.oasis-open.org/committees/odata/.

+

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.

+

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]

@@ -155,7 +155,7 @@

Citation format:

Notices

Copyright © OASIS Open 2023. 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.

+

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.

Table of Contents

@@ -402,7 +402,7 @@

Representation-Specific Headline

All other text is normative unless otherwise labeled.

Here is a customized command line which will generate HTML from this markdown file (named odata-csdl-xml-v4.02-csd01.md). Line breaks are added for readability only:

-
pandoc -f gfm+tex_math_dollars+fenced_divs
+
pandoc -f gfm+tex_math_dollars+fenced_divs+smart
        -t html
        -o odata-csdl-xml-v4.02-csd01.html
        -c styles/markdown-styles-v1.7.3b.css
@@ -517,7 +517,7 @@ 
3.3
 
 
 Edm.Double
-IEEE 754 binary64 floating-point number (15-17 decimal digits)
+IEEE 754 binary64 floating-point number (15–17 decimal digits)
 
 
 Edm.Duration
@@ -545,7 +545,7 @@ 
3.3
 
 
 Edm.Single
-IEEE 754 binary32 floating-point number (6-9 decimal digits)
+IEEE 754 binary32 floating-point number (6–9 decimal digits)
 
 
 Edm.Stream
@@ -557,7 +557,7 @@ 
3.3
 
 
 Edm.TimeOfDay
-Clock time 00:00-23:59:59.999999999999
+Clock time 00:00–23:59:59.999999999999
 
 
 Edm.Geography
@@ -628,7 +628,7 @@ 
3.3
 
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 the 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 or for non-binding parameters to functions or actions.

-
Some of these types allow facets, defined in section "Type Facets".

+
Some of these types allow facets, defined in section “Type Facets”.

 
See rule primitiveLiteral in OData-ABNF for the representation of primitive type values in URLs and OData-JSON for the representation in requests and responses.

 
3.4 Type Facets

 
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.

@@ -643,7 +643,7 @@ 
3.4.2 Precision

-
For a decimal value: the maximum number of significant decimal digits of the model element's value; it MUST be a positive integer.

+
For a decimal value: the maximum number of significant decimal digits of the model element’s value; it MUST be a positive integer.

 
For a temporal value (datetime-with-timezone-offset, duration, or time-of-day): the number of decimal places allowed in the seconds portion of the value; it MUST be a non-negative integer between zero and twelve.

 
Note: service authors SHOULD be aware that some clients are unable to support a precision greater than 28 for decimal values and 7 for temporal values. Client developers MUST be aware of the potential for data loss when round-tripping values of greater precision. Updating via PATCH and exclusively specifying modified values will reduce the risk for unintended data loss.

 
Note: model elements with duration values and a granularity less than seconds (e.g. minutes, hours, days) can be annotated with term Measures.DurationGranularity, see OData-VocMeasures.

@@ -719,7 +719,7 @@ 
Path Expressions" for details.

+
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 “Path Expressions” for details.

 
3.7 Annotations

 
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.

@@ -788,7 +788,7 @@ 
</edmx:Edmx>

4.1 Reference

-

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 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 OData-Protocol, SHOULD be used when retrieving the referenced schema document.

@@ -857,10 +857,10 @@

4.3 Included Annotations

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.

+

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.

+

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.

Element edmx:IncludeAnnotations

@@ -904,7 +904,7 @@

5 Schema

One or more schemas describe the entity model exposed by an OData service. The schema acts as a namespace for elements of the entity model such as entity types, complex types, enumerations and terms.

A schema is identified by a namespace. Schema namespaces MUST be unique within the scope of a document and SHOULD be globally unique. A schema cannot span more than one document.

-

The schema's namespace is combined with the name of elements in the schema to create unique qualified names, so identifiers that are used to name types MUST be unique within a namespace to prevent ambiguity.

+

The schema’s namespace is combined with the name of elements in the schema to create unique qualified names, so identifiers that are used to name types MUST be unique within a namespace to prevent ambiguity.

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

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

@@ -950,7 +950,7 @@

6 Entity Type

Entity types are nominal structured types with a key that consists of one or more references to structural properties. An entity type is the template for an entity: any uniquely identifiable record such as a customer or order.

-

The entity type's name is a simple identifier that MUST be unique within its schema.

+

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

An entity type can define two types of properties. A structural property is a named reference to a primitive, complex, or enumeration type, or a collection of primitive, complex, or enumeration types. A navigation property is a named reference to another entity type or collection of entity types.

All properties MUST have a unique name within an entity type. Properties MUST NOT have the same name as the declaring entity type. They MAY have the same name as one of the direct or indirect base types or derived types.

@@ -960,7 +960,7 @@

edm:Key element.

It MAY contain edm:Annotation elements.

Attribute Name

-

The value of Name is the entity type's name.

+

The value of Name is the entity type’s name.

Example 13: a simple entity type

@@ -1020,8 +1020,8 @@

6.5 Key

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 (whether or not it is marked as abstract) MAY define a key only if it doesn't inherit one.

-

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.

+

An entity type (whether or not it is marked as abstract) MAY define a key only if it doesn’t inherit one.

+

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
    • @@ -1043,7 +1043,7 @@

    6.5 Key

    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.

    +

    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.

    Element edm:Key

    The edm:Key element MUST contain at least one edm:PropertyRef element.

    @@ -1108,14 +1108,14 @@

    type.

    -

    The property's name MUST be a simple identifier. It is used when referencing, serializing or deserializing the property. It MUST be unique within the set of structural and navigation properties of the declaring structured type, and MUST NOT match the name of any navigation property in any of its base types. If a structural property with the same name is defined in any of this type's base types, then the property's type MUST be a type derived from the type specified for the property of the base type and constrains this property to be of the specified subtype for instances of this structured type. The name MUST NOT match the name of any structural or navigation property of any of this type's base types for OData 4.0 responses.

    +

    The property’s name MUST be a simple identifier. It is used when referencing, serializing or deserializing the property. It MUST be unique within the set of structural and navigation properties of the declaring structured type, and MUST NOT match the name of any navigation property in any of its base types. If a structural property with the same name is defined in any of this type’s base types, then the property’s type MUST be a type derived from the type specified for the property of the base type and constrains this property to be of the specified subtype for instances of this structured type. The name MUST NOT match the name of any structural or navigation property of any of this type’s base types for OData 4.0 responses.

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

    Element edm:Property

    The edm:Property element MUST contain the Name and the Type attribute, and it MAY contain the attributes Nullable, MaxLength, Unicode, Precision, Scale, SRID, and DefaultValue.

    It MAY contain edm:Annotation elements.

    Attribute Name

    -

    The value of Name is the property's name.

    +

    The value of Name is the property’s name.

    Example 20: complex type with two properties

    @@ -1127,13 +1127,13 @@

    </ComplexType>

    7.1 Type

    -

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

    +

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

    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.

    Attribute Type

    -

    For single-valued properties the value of Type is the qualified name of the property's type.

    -

    For collection-valued properties the value of Type is the character sequence Collection( followed by the qualified name of the property's item type, followed by a closing parenthesis ).

    +

    For single-valued properties the value of Type is the qualified name of the property’s type.

    +

    For collection-valued properties the value of Type is the character sequence Collection( followed by the qualified name of the property’s item type, followed by a closing parenthesis ).

    Example 21: property Units that can have zero or more strings as its value

    @@ -1160,7 +1160,7 @@

    Attri

    8 Navigation Property

    A navigation property allows navigation to related entities. It MUST specify a unique name as well as a type.

    -

    The navigation property's name MUST be a simple identifier. It is used when referencing, serializing or deserializing the navigation property. It MUST be unique within the set of structural and navigation properties of the declaring structured type, and MUST NOT match the name of any structural property in any of its base types. If a navigation property with the same name is defined in any of this type's base types, then the navigation property's type MUST be a type derived from the type specified for the navigation property of the base type, and constrains this navigation property to be of the specified subtype for instances of this structured type. The name MUST NOT match the name of any structural or navigation property of any of this type's base types for OData 4.0 responses.

    +

    The navigation property’s name MUST be a simple identifier. It is used when referencing, serializing or deserializing the navigation property. It MUST be unique within the set of structural and navigation properties of the declaring structured type, and MUST NOT match the name of any structural property in any of its base types. If a navigation property with the same name is defined in any of this type’s base types, then the navigation property’s type MUST be a type derived from the type specified for the navigation property of the base type, and constrains this navigation property to be of the specified subtype for instances of this structured type. The name MUST NOT match the name of any structural or navigation property of any of this type’s base types for OData 4.0 responses.

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

    Element edm:NavigationProperty

    @@ -1168,7 +1168,7 @@

    It MAY contain child elements edm:ReferentialConstraint and at most one child element edm:OnDelete.

    It MAY contain edm:Annotation elements.

    Attribute Name

    -

    The value of Name is the navigation property's name.

    +

    The value of Name is the navigation property’s name.

    Example 22: the Product entity type has a navigation property to a Category, which has a navigation link back to one or more products

    @@ -1186,7 +1186,7 @@

    </EntityType>

    8.1 Navigation Property Type

    -

    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.

    +

    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 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.

    @@ -1194,8 +1194,8 @@

    Core.PositionalInsert term, defined in OData-VocCore, to specify that it supports inserting items into a specific ordinal position.

    Attribute Type

    -

    For single-valued navigation properties the value of Type is the qualified name of the navigation property's type.

    -

    For collection-valued navigation properties the value of Type is the character sequence Collection( followed by the qualified name of the navigation property's item type, followed by a closing parenthesis ).

    +

    For single-valued navigation properties the value of Type is the qualified name of the navigation property’s type.

    +

    For collection-valued navigation properties the value of Type is the character sequence Collection( followed by the qualified name of the navigation property’s item type, followed by a closing parenthesis ).

    8.2 Nullable Navigation Property

    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.

    @@ -1235,7 +1235,7 @@

    Element edm:ReferentialConstraint

    @@ -1302,7 +1302,7 @@

    9 Complex Type

    Complex types are keyless nominal structured types. The lack of a key means that instances of complex types cannot be referenced, created, updated or deleted independently of an entity type. Complex types allow entity models to group properties into common structures.

    -

    The complex type's name is a simple identifier that MUST be unique within its schema.

    +

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

    A complex type can define two types of properties. A structural property is a named reference to a primitive, complex, or enumeration type, or a collection of primitive, complex, or enumeration types. A navigation property is a named reference to an entity type or a collection of entity types.

    All properties MUST have a unique name within a complex type. Properties MUST NOT have the same name as the declaring complex type. They MAY have the same name as one of the direct or indirect base types or derived types.

    @@ -1311,7 +1311,7 @@

    edm:Property and edm:NavigationProperty elements describing the properties of the complex type.

    It MAY contain edm:Annotation elements.

    Attribute Name

    -

    The value of Name is the complex type's name.

    +

    The value of Name is the complex type’s name.

    Example 25: a complex type used by two entity types

    @@ -1358,7 +1358,7 @@

    Attribute

    10 Enumeration Type

    Enumeration types are nominal types that represent a non-empty series of related values. Enumeration types expose these related values as members of the enumeration.

    -

    The enumeration type's name is a simple identifier that MUST be unique within its schema.

    +

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

    Although enumeration types have an underlying numeric value, the preferred representation for an enumeration value is the member name. Discrete sets of numeric values should be represented as numeric values annotated with the AllowedValues annotation defined in OData-VocCore.

    Enumeration types marked as flags allow values that consist of more than one enumeration member at a time.

    @@ -1367,7 +1367,7 @@

    edm:Member elements defining the members of the enumeration type.

    It MAY contain edm:Annotation elements.

    Attribute Name

    -

    The value of Name is the enumeration type's name.

    +

    The value of Name is the enumeration type’s name.

    Example 26: a simple flags-enabled enumeration

    @@ -1421,7 +1421,7 @@

    edm:Annotation elements.

    Attribute Name

    -

    The value of Name is the enumeration member's name.

    +

    The value of Name is the enumeration member’s name.

    Attribute Value

    If the IsFlags attribute has a value of false, either all members MUST specify an integer value for the Value attribute, or all members MUST NOT specify a value for the Value attribute. If no values are specified, the members are assigned consecutive integer values in the order of their appearance, starting with zero for the first member. Client libraries MUST preserve elements in document order.

    If the IsFlags attribute has a value of true, a non-negative integer value MUST be specified for the Value attribute. A combined value is equivalent to the bitwise OR of the discrete values.

    @@ -1446,7 +1446,7 @@

    11 Type Definition

    A type definition defines a specialization of one of the primitive types or of the built-in abstract type Edm.PrimitiveType.

    -

    The type definition's name is a simple identifier that MUST be unique within its schema.

    +

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

    Type definitions can be used wherever a primitive type is used (other than as the underlying type in a new type definition) and are type-comparable with their underlying types and any type definitions defined using the same underlying 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 type definition is used, and whether they can be overridden.

    @@ -1454,7 +1454,7 @@

    UnderlyingType attributes.

    It MAY contain edm:Annotation elements.

    Attribute Name

    -

    The value of Name is the type definition's name.

    +

    The value of Name is the type definition’s name.

    Example 29:

    @@ -1487,7 +1487,7 @@

    A

    12 Action and Function

    12.1 Action

    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.

    +

    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.

    @@ -1501,11 +1501,11 @@

    edm:ReturnType element and MAY contain edm:Parameter elements.

    It MAY contain edm:Annotation elements.

    Attribute Name

    -

    The value of Name is the action's name.

    +

    The value of Name is the action’s name.

    12.3 Function

    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.

    +

    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.

    @@ -1530,7 +1530,7 @@

    edm:ReturnType element, and it MAY contain edm:Parameter elements.

    It MAY contain edm:Annotation elements.

    Attribute Name

    -

    The value of Name is the action's name.

    +

    The value of Name is the action’s name.

    12.5 Bound or Unbound Action or Function Overloads

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

    @@ -1586,10 +1586,10 @@

    MaxLength, Unicode, Precision, Scale, and SRID.

    It MAY contain edm:Annotation elements.

    Attribute Name

    -

    The value of Name is the parameter's name.

    +

    The value of Name is the parameter’s name.

    Attribute Type

    For single-valued parameters the value of Type is the qualified name of the parameter.

    -

    For collection-valued parameters the value of Type is the character sequence Collection( followed by the qualified name of the parameter's type, followed by a closing parenthesis ).

    +

    For collection-valued parameters the value of Type is the character sequence Collection( followed by the qualified name of the parameter’s type, followed by a closing parenthesis ).

    Attribute Nullable

    The value of Nullable is one of the Boolean literals true or false. Absence of the attribute means true.

    The value true means that the parameter accepts a null value.

    @@ -1604,7 +1604,7 @@

    13 Entity Container

    Each metadata document used to describe an OData service MUST define exactly one entity container.

    -

    The entity container's name is a simple identifier that MUST be unique within its schema.

    +

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

    Entity containers define the entity sets, singletons, function and action imports exposed by the service.

    Entity set, singleton, action import, and function import names MUST be unique within an entity container.

    An entity set allows access to entity type instances. Simple entity models frequently have one entity set per entity type.

    @@ -1633,7 +1633,7 @@

    The edm:EntityContainer MUST contain one or more edm:EntitySet, edm:Singleton, edm:ActionImport, or edm:FunctionImport elements.

    It MAY contain edm:Annotation elements.

    Attribute Name

    -

    The value of Name is the entity container's name.

    +

    The value of Name is the entity container’s name.

    Example 33: An entity container aggregates entity sets, singletons, action imports, and function imports.

    @@ -1655,8 +1655,8 @@

    </EntityContainer>

13.1 Extending an Entity Container

-

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.

+

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.

Attribute Extends

@@ -1681,7 +1681,7 @@

edm:NavigationPropertyBinding elements.

It MAY contain edm:Annotation elements.

Attribute Name

-

The value of Name is the entity set's name.

+

The value of Name is the entity set’s name.

Attribute EntityType

The value of EntityType is the qualified name of an entity type in scope.

Attribute IncludeInServiceDocument

@@ -1698,7 +1698,7 @@

edm:NavigationPropertyBinding elements.

It MAY contain edm:Annotation elements.

Attribute Name

-

The value of Name is the singleton's name.

+

The value of Name is the singleton’s name.

Attribute Type

The value of Type is whose value is the qualified name of an entity type in scope.

Attribute Nullable

@@ -1711,7 +1711,7 @@

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.

13.4.1 Navigation Property Path Binding

-

A navigation property binding MUST specify a path to a navigation property of the entity set's or singleton's declared entity type, or a navigation property reached through a chain of type casts, complex properties, or containment navigation properties. If the navigation property is defined on a subtype, the path MUST contain the qualified name of the subtype, followed by a forward slash, followed by the navigation property name. If the navigation property is defined on a complex type used in the definition of the entity set's entity type, the path MUST contain a forward-slash separated list of complex property names and qualified type names that describe the path leading to the navigation property.

+

A navigation property binding MUST specify a path to a navigation property of the entity set’s or singleton’s declared entity type, or a navigation property reached through a chain of type casts, complex properties, or containment navigation properties. If the navigation property is defined on a subtype, the path MUST contain the qualified name of the subtype, followed by a forward slash, followed by the navigation property name. If the navigation property is defined on a complex type used in the definition of the entity set’s entity type, the path MUST contain a forward-slash separated list of complex property names and qualified type names that describe the path leading to the navigation property.

The path can traverse one or more containment navigation properties, but the last navigation property segment MUST be a non-containment navigation property and there MUST NOT be any non-containment navigation properties prior to the final navigation property segment.

If the path traverses collection-valued complex properties or collection-valued containment navigation properties, the binding applies to all items of these collections.

If the path contains a recursive sub-path (i.e. a path leading back to the same structured type, the binding applies recursively to any positive number of cycles through that sub-path.

@@ -1760,7 +1760,7 @@

edm:Annotation elements.

Attribute Name

-

The value of Name is the action import's name.

+

The value of Name is the action import’s name.

Attribute Action

The value of Action is the qualified name of an unbound action.

Attribute EntitySet

@@ -1776,7 +1776,7 @@

13.

Element edm:FunctionImport

The edm:FunctionImport element MUST contain the attributes Name and Function, and it MAY contain the attributes EntitySet and IncludeInServiceDocument.

Attribute Name

-

The value of Name is the function import's name.

+

The value of Name is the function import’s name.

Attribute Function

The value of Function is the qualified name of an unbound function.

Attribute EntitySet

@@ -1824,8 +1824,8 @@

14.1 Term

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.

+

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.

Element edm:Term

The edm:Term element MUST contain the attributes Name and Type. It MAY contain the attributes Nullable, DefaultValue, BaseTerm and AppliesTo.

@@ -1833,10 +1833,10 @@

E

A edm:Term element whose Type attribute specifies a primitive or enumeration type MAY define a value for the DefaultValue attribute.

It MAY contain edm:Annotation elements.

Attribute Name

-

The value of Name is the term's name.

+

The value of Name is the term’s name.

Attribute Type

-

For single-valued terms the value of Type is the qualified name of the term's type.

-

For collection-valued properties the value of Type is the character sequence Collection( followed by the qualified name of the property's item type, followed by a closing parenthesis ).

+

For single-valued terms the value of Type is the qualified name of the term’s type.

+

For collection-valued properties the value of Type is the character sequence Collection( followed by the qualified name of the property’s item type, followed by a closing parenthesis ).

Attribute Nullable

The value of Nullable is one of the Boolean literals true or false.

For single-valued terms the value true means that annotations may have the null value.

@@ -2042,9 +2042,9 @@

</Property> <Property Name="Currency" Type="Edm.String" 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.

+

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.

14.2.1 Qualifier

A term can be applied multiple times to the same model element by providing a qualifier to distinguish the annotations. The qualifier is a simple identifier.

The combination of target model element, term, and qualifier uniquely identifies an annotation.

@@ -2059,7 +2059,7 @@

Attribute <

14.2.2 Target

The target of an annotation is the model element the term is applied to.

-

The target of an annotation MAY be specified indirectly by "nesting" the annotation within the model element. Whether and how this is possible is described per model element in this specification.

+

The target of an annotation MAY be specified indirectly by “nesting” the annotation within the model element. Whether and how this is possible is described per model element in this specification.

The target of an annotation MAY also be specified directly; this allows defining an annotation in a different schema than the targeted model element.

This external targeting is only possible for model elements that are uniquely identified within their parent, and all their ancestor elements are uniquely identified within their parent.

These are the direct children of a schema with a unique name (i.e. except actions and functions whose overloads to not possess a natural identifier), and all direct children of an entity container.

@@ -2399,7 +2399,7 @@

14.4.1.1 Path

Example 58: absolute path to an entity set

/My.Schema.MyEntityContainer/MyEntitySet
-

Paths not starting with a forward slash are interpreted relative to the annotation target, following the rules specified in section "Path Evaluation".

+

Paths not starting with a forward slash are interpreted relative to the annotation target, following the rules specified in section “Path Evaluation”.

Example 59: relative path to a property

Address/City
@@ -2409,7 +2409,7 @@

14.4.1.1 Path

Example 60: type-cast segment

.../self.Manager/...

-

If a path segment starts with an at (@) character, it represents a term cast. The at (@) character MUST be followed by a qualified name that MAY be followed by a hash (#) character and a simple identifier. The qualified name preceding the hash character MUST resolve to a term that is in scope, the simple identifier following the hash sign is interpreted as a qualifier for the term. If the model element or instance identified by the preceding path part has not been annotated with that term (and if present, with that qualifier), the term cast evaluates to the null value. Four special terms are implicitly "annotated" for media entities and stream properties:

+

If a path segment starts with an at (@) character, it represents a term cast. The at (@) character MUST be followed by a qualified name that MAY be followed by a hash (#) character and a simple identifier. The qualified name preceding the hash character MUST resolve to a term that is in scope, the simple identifier following the hash sign is interpreted as a qualifier for the term. If the model element or instance identified by the preceding path part has not been annotated with that term (and if present, with that qualifier), the term cast evaluates to the null value. Four special terms are implicitly “annotated” for media entities and stream properties:

Non-normatively speaking it starts with a letter or underscore, followed by at most 127 letters, underscores or digits.

15.3 Qualified Name

@@ -3253,42 +3253,42 @@
[EPSG]

European Petroleum Survey Group (EPSG). http://www.epsg.org/.

[OData-ABNF]

OData ABNF Construction Rules Version 4.02.
-See link in "Additional artifacts" section on cover page.

+See link in “Additional artifacts” section on cover page.

[OData-CSDL]
-

OData Common Schema Definition Language (CSDL) JSON Representation Version 4.02. See link in "Related work" section on cover page.

+

OData Common Schema Definition Language (CSDL) JSON Representation Version 4.02. See link in “Related work” section on cover page.

OData Common Schema Definition Language (CSDL) XML Representation Version 4.02. This document.

[OData-EDM]

OData EDM XML Schema.
-See link in "Additional artifacts" section on cover page.

+See link in “Additional artifacts” section on cover page.

[OData-EDMX]

OData EDM XML Schema.
-See link in "Additional artifacts" section on cover page.

+See link in “Additional artifacts” section on cover page.

[OData-JSON]

OData JSON Format Version 4.02.
-See link in "Related work" section on cover page.

+See link in “Related work” section on cover page.

[OData-Protocol]

OData Version 4.02 Part 1: Protocol.
-See link in "Related work" section on cover page.

+See link in “Related work” section on cover page.

[OData-URL]

OData Version 4.02 Part 2: URL Conventions.
-See link in "Related work" section on cover page.

+See link in “Related work” section on cover page.

[OData-VocCore]

OData Vocabularies Version 4.0: Core Vocabulary.
-See link in "Related work" section on cover page.

+See link in “Related work” section on cover page.

[OData-VocMeasures]

OData Vocabularies Version 4.0: Measures Vocabulary.
-See link in "Related work" section on cover page.

+See link in “Related work” section on cover page.

[OData-VocValidation]

OData Vocabularies Version 4.0: Validation Vocabulary.
-See link in "Related work" section on cover page.

+See link in “Related work” section on cover page.

[RFC2119]
-

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
+

Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
https://www.rfc-editor.org/info/rfc2119.

[RFC6570]

Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, “URI Template”, RFC 6570, March 2012.
http://tools.ietf.org/html/rfc6570.

[RFC8174]
-

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.
+

Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.
http://www.rfc-editor.org/info/rfc8174.

[XML-1.1]

Extensible Markup Language (XML) 1.1 (Second Edition). F. Yergeau, E. Maler, J. Cowan, T. Bray, C. M. Sperberg-McQueen, J. Paoli, Editors, W3C Recommendation, 16 August 2006.
@@ -3304,7 +3304,7 @@

[XML-Schema-2]
http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/. Latest version available at http://www.w3.org/TR/xmlschema11-2/.

A.2 Informative References

[OpenUI5]
-

OpenUI5 Version 1.40.10 - OData V4 Metadata JSON Format.
+

OpenUI5 Version 1.40.10 — OData V4 Metadata JSON Format.
https://openui5.hana.ondemand.com/1.40.10/#docs/guide/87aac894a40640f89920d7b2a414499b.html.

Appendix B. Table of XML Elements and Attributes

@@ -3658,14 +3658,14 @@

Appendix E. Notices

Copyright © OASIS Open 2023. All Rights Reserved.

-

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

+

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the “OASIS IPR Policy”). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

-

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

+

This document and the information contained herein is provided on an “AS IS” basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

As stated in the OASIS IPR Policy, the following three paragraphs in brackets apply to OASIS Standards Final Deliverable documents (Committee Specification, Candidate OASIS Standard, OASIS Standard, or Approved Errata).

[OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Standards Final Deliverable, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this deliverable.]

[OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this OASIS Standards Final Deliverable by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this OASIS Standards Final Deliverable. OASIS may include such claims on its website, but disclaims any obligation to do so.]

-

[OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this OASIS Standards Final Deliverable or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Standards Final Deliverable, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.]

-

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. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark/ for above guidance.

+

[OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this OASIS Standards Final Deliverable or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS’ procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Standards Final Deliverable, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.]

+

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. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark/ for above guidance.

diff --git a/docs/odata-csdl-xml/odata-csdl-xml.md b/docs/odata-csdl-xml/odata-csdl-xml.md index d7d112ac9..0e6c498a5 100644 --- a/docs/odata-csdl-xml/odata-csdl-xml.md +++ b/docs/odata-csdl-xml/odata-csdl-xml.md @@ -61,7 +61,7 @@ OData services are described by an Entity Model (EDM). The Common Schema Definit #### 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://www.oasis-open.org/committees/tc_home.php?wg_abbrev=odata#technical. -TC members should send comments on this specification to the TC's email list. Others should send comments to the TC's public comment list, after subscribing to it by following the instructions at the "[Send A Comment](https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=odata)" button on the TC's web page at https://www.oasis-open.org/committees/odata/. +TC members should send comments on this specification to the TC's email list. Others should send comments to the TC's public comment list, after subscribing to it by following the instructions at the "Send A Comment" button on the TC's web page at https://www.oasis-open.org/committees/odata/. This specification is provided under the [RF on RAND Terms Mode](https://www.oasis-open.org/policies-guidelines/ipr/#RF-on-RAND-Mode) of the [OASIS IPR Policy](https://www.oasis-open.org/policies-guidelines/ipr/), 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). @@ -296,7 +296,7 @@ All other text is normative unless otherwise labeled. Here is a customized command line which will generate HTML from this markdown file (named `odata-csdl-xml-v4.02-csd01.md`). Line breaks are added for readability only: ``` -pandoc -f gfm+tex_math_dollars+fenced_divs +pandoc -f gfm+tex_math_dollars+fenced_divs+smart -t html -o odata-csdl-xml-v4.02-csd01.html -c styles/markdown-styles-v1.7.3b.css @@ -503,17 +503,17 @@ Type|Meaning `Edm.Date` |Date without a time-zone offset `Edm.DateTimeOffset` |Date and time with a time-zone offset, no leap seconds `Edm.Decimal` |Numeric values with decimal representation -`Edm.Double` |IEEE 754 binary64 floating-point number (15-17 decimal digits) +`Edm.Double` |IEEE 754 binary64 floating-point number (15--17 decimal digits) `Edm.Duration` |Signed duration in days, hours, minutes, and (sub)seconds `Edm.Guid` |16-byte (128-bit) unique identifier `Edm.Int16` |Signed 16-bit integer `Edm.Int32` |Signed 32-bit integer `Edm.Int64` |Signed 64-bit integer `Edm.SByte` |Signed 8-bit integer -`Edm.Single` |IEEE 754 binary32 floating-point number (6-9 decimal digits) +`Edm.Single` |IEEE 754 binary32 floating-point number (6--9 decimal digits) `Edm.Stream` |Binary data stream `Edm.String` |Sequence of characters -`Edm.TimeOfDay` |Clock time 00:00-23:59:59.999999999999 +`Edm.TimeOfDay` |Clock time 00:00--23:59:59.999999999999 `Edm.Geography` |Abstract base type for all Geography types `Edm.GeographyPoint` |A point in a round-earth coordinate system `Edm.GeographyLineString` |Line string in a round-earth coordinate system @@ -5659,7 +5659,7 @@ http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/. Latest version available ## A.2 Informative References ###### [OpenUI5] -_OpenUI5 Version 1.40.10 - OData V4 Metadata JSON Format_. +_OpenUI5 Version 1.40.10 --- OData V4 Metadata JSON Format_. https://openui5.hana.ondemand.com/1.40.10/#docs/guide/87aac894a40640f89920d7b2a414499b.html. ------- diff --git a/docs/odata-data-aggregation-ext/odata-data-aggregation-ext.html b/docs/odata-data-aggregation-ext/odata-data-aggregation-ext.html index fcc342831..bdddb4475 100644 --- a/docs/odata-data-aggregation-ext/odata-data-aggregation-ext.html +++ b/docs/odata-data-aggregation-ext/odata-data-aggregation-ext.html @@ -149,12 +149,12 @@

Abstract:

This specification adds basic grouping and aggregation functionality (e.g. sum, min, and max) to the Open Data Protocol (OData) without changing any of the base principles of OData.

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://www.oasis-open.org/committees/tc_home.php?wg_abbrev=odata#technical.

-

TC members should send comments on this specification to the TC's email list. Others should send comments to the TC's public comment list, after subscribing to it by following the instructions at the "Send A Comment" button on the TC's web page at https://www.oasis-open.org/committees/odata/.

-

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.

+

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://www.oasis-open.org/committees/tc_home.php?wg_abbrev=odata#technical.

+

TC members should send comments on this specification to the TC’s email list. Others should send comments to the TC’s public comment list, after subscribing to it by following the instructions at the “Send A Comment” button on the TC’s web page at https://www.oasis-open.org/committees/odata/.

+

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.

+

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-Data-Agg-v4.0]

@@ -162,7 +162,7 @@

Citation format:

Notices

Copyright © OASIS Open 2023. 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.

+

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.

Table of Contents

@@ -357,7 +357,7 @@

Here is a customized command line which will generate HTML from this markdown file (named odata-data-aggregation-ext-v4.0-cs03.md). Line breaks are added for readability only:

-
pandoc -f gfm+tex_math_dollars+fenced_divs
+
pandoc -f gfm+tex_math_dollars+fenced_divs+smart
        -t html
        -o odata-data-aggregation-ext-v4.0-cs03.html
        -c styles/markdown-styles-v1.7.3b.css
@@ -373,13 +373,13 @@ 
2 Overview

 
Open Data Protocol (OData) services expose a data model that describes the schema of the service in terms of the Entity Data Model (EDM, see OData-CSDL) and then allows for querying data in terms of this model. The responses returned by an OData service are based on that data model and retain the relationships between the entities in the model.

-
Extending the OData query features with simple aggregation capabilities avoids cluttering OData services with an exponential number of explicitly modeled "aggregation level entities" or else restricting the consumer to a small subset of predefined aggregations.

+
Extending the OData query features with simple aggregation capabilities avoids cluttering OData services with an exponential number of explicitly modeled “aggregation level entities” or else restricting the consumer to a small subset of predefined aggregations.

 
Adding the notion of aggregation to OData without changing any of the base principles in OData has two aspects:

 
    
 
  1. Means for the consumer to query aggregated data on top of any given data model (for sufficiently capable data providers)
    2. 
 
  2. Means for the provider to annotate what data can be aggregated, and in which way, allowing consumers to avoid asking questions that the provider cannot answer
    3. 
 

-
Implementing any of these two aspects is valuable in itself independent of the other, and implementing both provides additional value for consumers. The provided aggregation annotations help a consumer understand more of the data structure looking at the service's exposed data model. The query extensions allow the consumers to explicitly express the desired aggregation behavior for a particular query. They also allow consumers to formulate queries that utilize the aggregation annotations.

+
Implementing any of these two aspects is valuable in itself independent of the other, and implementing both provides additional value for consumers. The provided aggregation annotations help a consumer understand more of the data structure looking at the service’s exposed data model. The query extensions allow the consumers to explicitly express the desired aggregation behavior for a particular query. They also allow consumers to formulate queries that utilize the aggregation annotations.

 
2.1 Example Data Model

 

 
Example 2: The following diagram depicts a simple model that is used throughout this document.

@@ -881,7 +881,7 @@ 
hierarchy based on Year, Month, and Date
 
  • SalesOrganization hierarchy based on the recursive association to itself
    • 
 
-
    In the context of Online Analytical Processing (OLAP), this model might be described in terms of a Sales "cube" with an Amount "measure" and three "dimensions". This document will avoid such terms, as they are heavily overloaded.
    
+
    In the context of Online Analytical Processing (OLAP), this model might be described in terms of a Sales “cube” with an Amount “measure” and three “dimensions”. This document will avoid such terms, as they are heavily overloaded.
    
 
    
 
    Query extensions and descriptive annotations can be applied to normalized schemas as well as partly or fully denormalized schemas.
    
 
    
@@ -1055,7 +1055,7 @@ 
    2.2 Example D
 2022
 
 
-...
+…
 
 
 
@@ -1265,8 +1265,8 @@ 
    2.2 Example D
 
    
 
    2.3 Example Use Cases
    
 
    
-
    Example 5: In the example model, one prominent use case is the relation of customers to products. The first question that is likely to be asked is: "Which customers bought which products?"
    
-
    This leads to the second more quantitative question: "Who bought how much of what?"
    
+
    Example 5: In the example model, one prominent use case is the relation of customers to products. The first question that is likely to be asked is: “Which customers bought which products?”
    
+
    This leads to the second more quantitative question: “Who bought how much of what?”
    
 
    The answer to the second question typically is visualized as a cross-table:
    
 
    
 
@@ -1593,7 +1593,7 @@ 
    \(B=γ(v,p_2)\).
 
  • Return \(B\).
    • 
 
-
    This notation is extended to the case of an empty path \(e\) by setting \(\Gamma(A,e)=A\) with null values removed. Note the collections returned by \(\Gamma\) and \(γ\) never contain the null value. Also, every instance \(u\) in \(\Gamma(A,p)\) occurs also in \(A\) or nested into \(A\), therefore an algorithmic step like "Add a dynamic property to each \(u\) in \(\Gamma(A,p)\)" effectively changes \(A\).
    
+
    This notation is extended to the case of an empty path \(e\) by setting \(\Gamma(A,e)=A\) with null values removed. Note the collections returned by \(\Gamma\) and \(γ\) never contain the null value. Also, every instance \(u\) in \(\Gamma(A,p)\) occurs also in \(A\) or nested into \(A\), therefore an algorithmic step like “Add a dynamic property to each \(u\) in \(\Gamma(A,p)\)” effectively changes \(A\).
    
 
    3.2 Basic Aggregation
    
 
    3.2.1 Transformation aggregate
    3.2.1.1 Aggregation Algorithm
    
@@ -2386,7 +2386,7 @@ 
    OData-URL for details.
    
 
    Where useful navigations exist it is beneficial to expose those as explicit navigation properties in the model, but the ability to pose queries that span entity sets not related by an association provides a mechanism for advanced consumers to use more flexible join conditions.
    
 
    
-
    Example 47: if Sale had a string property ProductID instead of the navigation property Product, a "join" between Sales and Products could be accessed via the $crossjoin resource
    
+
    Example 47: if Sale had a string property ProductID instead of the navigation property Product, a “join” between Sales and Products could be accessed via the $crossjoin resource
    
 
    GET /service/$crossjoin(Products,Sales)
                          ?$expand=Products($select=Name),Sales($select=Amount)
                          &$filter=Products/ID eq Sales/ProductID
    
@@ -2551,7 +2551,7 @@ 
    </EntityContainer>
    
 
 
    5.5 Hierarchies
    
-
    A hierarchy is an arrangement of entities whose values are represented as being "above", "below", or "at the same level as" one another. A hierarchy can be leveled or recursive.
    
+
    A hierarchy is an arrangement of entities whose values are represented as being “above”, “below”, or “at the same level as” one another. A hierarchy can be leveled or recursive.
    5.5.1 Leveled Hierarchy
    A leveled hierarchy has a fixed number of levels each of which is represented by a grouping property. The values of a lower-level property depend on the property value of the level above.
    A leveled hierarchy can be defined for a collection of instances of an entity or complex type and is described with the term LeveledHierarchy that lists the properties used to form the hierarchy.
    
@@ -2699,7 +2699,7 @@ 
    }
 
 
    
-
    Example 57: the lowest-level organizations including their superordinate's ID
    
+
    Example 57: the lowest-level organizations including their superordinate’s ID
    
 
    GET /service/SalesOrganizations?$filter=Aggregation.isleaf(
   HierarchyNodes=$root/SalesOrganizations,
   HierarchyQualifier='SalesOrgHierarchy',
@@ -2842,7 +2842,7 @@ 
    \(o\) of expressions that could also be passed as a $orderby system query option. If \(o\) is present, the transformation stable-sorts \(H'\) by \(o\).
    
 
    The instances in the input set are related to one node (if \(p\) is single-valued) or multiple nodes (if \(p\) is collection-valued) in the recursive hierarchy. Given a node \(x\), denote by \(\hat F(x)\) the collection of all instances in the input set that are related to \(x\); these collections can overlap. For each \(u\) in \(\hat F(x)\), the output set contains one instance that comprises the properties of \(u\) and additional properties that identify the node \(x\). These additional properties are independent of \(u\) and are bundled into an instance called \(σ(x)\). For example, if a sale \(u\) is related to two sales organizations and hence contained in both \(\hat F(x_1)\) and \(\hat F(x_2)\), the output set will contain two instances \((u,σ(x_1))\) and \((u,σ(x_2))\) and \(σ(x_i)\) contributes a navigation property SalesOrganization.
    
 
    A transformation \(F(x)\) is defined below such that \(\hat F(x)\) is the output set of \(F(x)\) applied to the input set of the traverse transformation.
    
-
    Given a node \(x\), the formulas below contain the transformation \(\Pi_G(σ(x))\) in order to inject the properties of \(σ(x)\) into the instances in \(\hat F(x)\); this uses the function \(\Pi_G\) that is defined in the simple grouping section. Further, \(G\) is a list of data aggregation paths that shall be present in the output set, and \(σ\) is a function that maps each hierarchy node \(x\) to an instance of the input type containing the paths from \(G\). As a consequence of the following definitions, only single-valued properties and "final segments from \(G\)" are nested into \(σ(x)\), therefore the behavior of \(\Pi_G(σ(x))\) is well-defined.
    
+
    Given a node \(x\), the formulas below contain the transformation \(\Pi_G(σ(x))\) in order to inject the properties of \(σ(x)\) into the instances in \(\hat F(x)\); this uses the function \(\Pi_G\) that is defined in the simple grouping section. Further, \(G\) is a list of data aggregation paths that shall be present in the output set, and \(σ\) is a function that maps each hierarchy node \(x\) to an instance of the input type containing the paths from \(G\). As a consequence of the following definitions, only single-valued properties and “final segments from \(G\)” are nested into \(σ(x)\), therefore the behavior of \(\Pi_G(σ(x))\) is well-defined.
    
 
    The definition of \(σ(x)\) makes use of a function \(a(ε,t,x)\), which returns a sparsely populated instance \(u\) in which only the path \(t\) has a value, namely \(u[t]=x\).
    
 
    Three cases are distinguished:
    
 
      
@@ -2940,7 +2940,7 @@ 
      \(S\) is not specified, then the result is effectively like in the standard case, except for the presence of the Aggregation.UpPath annotations.
      
 
      6.3 Grouping with rolluprecursive
      
-
      Recall that simple grouping partitions the input set and applies a transformation sequence to each partition. By contrast, grouping with rolluprecursive, informally speaking, transforms the input set into overlapping portions (like "US" and "US East"), one for each node \(x\) of a recursive hierarchy. The transformation \(F(x)\), defined below, outputs the portion whose node identifiers are among the descendants of \(x\) (including \(x\) itself). A transformation sequence is then applied to each portion, and they are made distinguishable in the output set through injection of information about the node \(x\), which is achieved through the transformation \(\Pi_G(σ(x))\) defined in the traverse section.
      
+
      Recall that simple grouping partitions the input set and applies a transformation sequence to each partition. By contrast, grouping with rolluprecursive, informally speaking, transforms the input set into overlapping portions (like “US” and “US East”), one for each node \(x\) of a recursive hierarchy. The transformation \(F(x)\), defined below, outputs the portion whose node identifiers are among the descendants of \(x\) (including \(x\) itself). A transformation sequence is then applied to each portion, and they are made distinguishable in the output set through injection of information about the node \(x\), which is achieved through the transformation \(\Pi_G(σ(x))\) defined in the traverse section.
      
 
      As defined above, \(H\), \(Q\) and \(p\) are the first three parameters of rolluprecursive, \(S\) is an optional fourth parameter. Let \(H'\) be the output set of the transformation sequence \(S\) applied to \(H\), or \(H'=H\) if \(S\) is not specified.
      
 
      Navigation properties specified in \(p\) are expanded by default.
      
 
      Let \(T\) be a transformation sequence, \(P_1\) stand in for zero or more property paths and \(P_2\) for zero or more rollup or rolluprecursive operators or property paths. The transformation \({\tt groupby}((P_1,{\tt rolluprecursive}(H,Q,p,S),P_2),T)\) is computed by the following algorithm, which invokes itself recursively if the number of rolluprecursive operators in the first argument of the groupby transformation, which is called \(M\), is greater than one. Let \(N\) be the recursion depth of the algorithm, starting with 1.
      
@@ -3016,7 +3016,7 @@ 
      }
    
 
 
    
-
    ⚠ Example 67: When requesting a sub-hierarchy consisting of the US East sales organization and its ancestors, the total sales amounts can either include the descendants outside this sub-hierarchy ("actual totals") or can exclude them ("visual totals").
    
+
    ⚠ Example 67: When requesting a sub-hierarchy consisting of the US East sales organization and its ancestors, the total sales amounts can either include the descendants outside this sub-hierarchy (“actual totals”) or can exclude them (“visual totals”).
    
 
    Actual totals are computed when rolluprecursive is restricted to the sub-hierarchy by setting the optional parameter \(S\) to an ancestors transformation:
    
 
    GET /service/Sales?$apply=groupby((rolluprecursive(
     $root/SalesOrganizations,SalesOrgHierarchy,SalesOrganization/ID,
@@ -3094,7 +3094,7 @@ 
        { "Name": "Sue" }
   ]
 }
    
-
    Note that "Sue" appears only once although the customer base contains two different Sues.
    
+
    Note that “Sue” appears only once although the customer base contains two different Sues.
    
 
 
    Aggregation is also possible across related entities.
    
 
    
@@ -3109,8 +3109,8 @@ 
      ]
 }
    
 
    Since groupby expands navigation properties in grouping properties by default, this is the same result as if the request would include a $expand=Customer($select=Name). The groupby removes all other properties.
    
-
    Note that "Luc" does not appear in the aggregated result as he hasn't bought anything and therefore there are no sales entities that refer/navigate to Luc.
    
-
    However, even though both Sues bought products, only one "Sue" appears in the aggregate result. Including properties that guarantee the right level of uniqueness in the grouping can repair that.
    
+
    Note that “Luc” does not appear in the aggregated result as he hasn’t bought anything and therefore there are no sales entities that refer/navigate to Luc.
    
+
    However, even though both Sues bought products, only one “Sue” appears in the aggregate result. Including properties that guarantee the right level of uniqueness in the grouping can repair that.
    
 
 
    
 
    Example 71:
    
@@ -3275,7 +3275,7 @@ 
          "TotalSales": { "Total@type": "Decimal", "Total":  4 } }
   ]
 }
    
-
    Applying outerjoin instead would return an additional entity for product with ID "Pencil" and TotalSales having a null value.
    
+
    Applying outerjoin instead would return an additional entity for product with ID “Pencil” and TotalSales having a null value.
    
 
 
    
 
    Example 80:
    
@@ -3755,7 +3755,7 @@ 
    }
    
 
 
    
-
    Example 103: concatenation of two different groupings "biggest sale per customer" and "biggest sale per product", made distinguishable by a dynamic property:
    
+
    Example 103: concatenation of two different groupings “biggest sale per customer” and “biggest sale per product”, made distinguishable by a dynamic property:
    
 
    GET /service/Sales?$apply=concat(
     groupby((Customer),topcount(1,Amount))/compute('Customer' as per),
     groupby((Product),topcount(1,Amount))/compute('Product' as per))
@@ -3869,7 +3869,7 @@ 
    7.9 Aggregation in Recursive Hierarchies
    
 
    If aggregation along a recursive hierarchy does not apply to the entire hierarchy, transformations ancestors and descendants may be used to restrict it as needed.
    
 
    
-
    Example 107: Total sales amounts for sales orgs in 'US' in the SalesOrgHierarchy defined in Hierarchy Examples
    
+
    Example 107: Total sales amounts for sales orgs in ‘US’ in the SalesOrgHierarchy defined in Hierarchy Examples
    
 
    GET /service/Sales?$apply=
     descendants(
         $root/SalesOrganizations,SalesOrgHierarchy,SalesOrganization/ID,
@@ -4107,7 +4107,7 @@ 
    
+
    Aggregation of sales amounts along the sales organization hierarchy could be restricted to those organizations linked with product category “Cereals” or a descendant of it, and the ancestors of those organizations:
    
 
    GET /service/Sales?$apply=groupby((rolluprecursive(
     $root/SalesOrganizations,SalesOrgHierarchy,
     SalesOrganization/ID,
@@ -4149,7 +4149,7 @@ 
    \(T\) of ancestors and operates on its input set of sales organizations. This would determine descendants of sales organizations for "Cereals" and their ancestor sales organizations, so US East would appear in the result.
    
+
    works differently: descendants is the parameter \(T\) of ancestors and operates on its input set of sales organizations. This would determine descendants of sales organizations for “Cereals” and their ancestor sales organizations, so US East would appear in the result.
    
 
    
 
    7.10 Maintaining Recursive Hierarchies
    
 
    Besides changes to the structural properties of the entities in a hierarchical collection, hierarchy maintenance involves changes to the parent-child relationships.
    
@@ -4324,12 +4324,12 @@ 
    }
    
 
 
    7.11 Transformation Sequences
    
-
    Applying aggregation first covers the most prominent use cases. The slightly more sophisticated question "how much money is earned with small sales" requires filtering the base set before applying the aggregation. To enable this type of question several transformations can be specified in $apply in the order they are to be applied, separated by a forward slash.
    
+
    Applying aggregation first covers the most prominent use cases. The slightly more sophisticated question “how much money is earned with small sales” requires filtering the base set before applying the aggregation. To enable this type of question several transformations can be specified in $apply in the order they are to be applied, separated by a forward slash.
    
 
    
 
    Example 119:
    
 
    GET /service/Sales?$apply=filter(Amount le 1)
     /aggregate(Amount with sum as Total)
    
-
    means "filter first, then aggregate", and results in
    
+
    means “filter first, then aggregate”, and results in
    
 
    {
   "@context": "$metadata#Sales(Total)",
   "value": [
@@ -4467,35 +4467,35 @@ 
    [OData-ABNF]
    
 
    ABNF components: OData ABNF Construction Rules Version 4.01 and OData ABNF Test Cases.
    
-See link in "Related work" section on cover page.
    
+See link in “Related work” section on cover page.
    
 
    [OData-Agg-ABNF]
    
 
    OData Aggregation ABNF Construction Rules Version 4.0.
    
-See link in "Additional artifacts" section on cover page.
    
+See link in “Additional artifacts” section on cover page.
    
 
    [OData-CSDL]
    
 
    OData Common Schema Definition Language (CSDL) JSON Representation Version 4.01.
    
-See link in "Related work" section on cover page.
    
+See link in “Related work” section on cover page.
    
 
    OData Common Schema Definition Language (CSDL) XML Representation Version 4.01.
    
-See link in "Related work" section on cover page.
    
+See link in “Related work” section on cover page.
    
 
    [OData-JSON]
    
 
    OData JSON Format Version 4.01.
    
-See link in "Related work" section on cover page.
    
+See link in “Related work” section on cover page.
    
 
    [OData-Protocol]
    
 
    OData Version 4.01. Part 1: Protocol.
    
-See link in "Related work" section on cover page.
    
+See link in “Related work” section on cover page.
    
 
    [OData-URL]
    
 
    OData Version 4.01. Part 2: URL Conventions.
    
-See link in "Related work" section on cover page.
    
+See link in “Related work” section on cover page.
    
 
    [OData-VocAggr]
    
 
    OData Aggregation Vocabulary.
    
-See link in "Additional artifacts" section on cover page.
    
+See link in “Additional artifacts” section on cover page.
    
 
    [OData-VocCore]
    
 
    OData Core Vocabulary.
    
-See link in "Related work" section on cover page.
    
+See link in “Related work” section on cover page.
    
 
    [RFC2119]
    
-
    Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997
    
+
    Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997
    
 https://www.rfc-editor.org/info/rfc2119.
    
 
    [RFC8174]
    
-
    Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017
    
+
    Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017
    
 https://www.rfc-editor.org/info/rfc8174.
    
 
    
 
    Appendix B. Acknowledgments
    
@@ -4604,7 +4604,7 @@ 
     Remove actions and functions (except set transformations) on aggregated entities, adapted section "Actions and Functions on Aggregated Entities"
+
    
@@ -4617,14 +4617,14 @@ 
    Appendix D. Notices
    
 
    Copyright © OASIS Open 2023. All Rights Reserved.
    
-
    All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.
    
+
    All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the “OASIS IPR Policy”). The full Policy may be found at the OASIS website.
    
 
    This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.
    
 
    The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
    
-
    This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
    
+
    This document and the information contained herein is provided on an “AS IS” basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
    
 
    As stated in the OASIS IPR Policy, the following three paragraphs in brackets apply to OASIS Standards Final Deliverable documents (Committee Specification, Candidate OASIS Standard, OASIS Standard, or Approved Errata).
    
 
    [OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Standards Final Deliverable, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this deliverable.]
    
 
    [OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this OASIS Standards Final Deliverable by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this OASIS Standards Final Deliverable. OASIS may include such claims on its website, but disclaims any obligation to do so.]
    
-
    [OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this OASIS Standards Final Deliverable or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Standards Final Deliverable, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.]
    
-
    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. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark/ for above guidance.
    
+
    [OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this OASIS Standards Final Deliverable or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS’ procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Standards Final Deliverable, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.]
    
+
    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. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark/ for above guidance.
    
 
 
diff --git a/docs/odata-data-aggregation-ext/odata-data-aggregation-ext.md b/docs/odata-data-aggregation-ext/odata-data-aggregation-ext.md
index a2d9a7578..02e65d81f 100644
--- a/docs/odata-data-aggregation-ext/odata-data-aggregation-ext.md
+++ b/docs/odata-data-aggregation-ext/odata-data-aggregation-ext.md
@@ -67,7 +67,7 @@ This specification adds basic grouping and aggregation functionality (e.g. sum,
 #### 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://www.oasis-open.org/committees/tc_home.php?wg_abbrev=odata#technical.
 
-TC members should send comments on this specification to the TC's email list. Others should send comments to the TC's public comment list, after subscribing to it by following the instructions at the "[Send A Comment](https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=odata)" button on the TC's web page at https://www.oasis-open.org/committees/odata/.
+TC members should send comments on this specification to the TC's email list. Others should send comments to the TC's public comment list, after subscribing to it by following the instructions at the "Send A Comment" button on the TC's web page at https://www.oasis-open.org/committees/odata/.
 
 This specification is provided under the [RF on RAND Terms Mode](https://www.oasis-open.org/policies-guidelines/ipr/#RF-on-RAND-Mode) of the [OASIS IPR Policy](https://www.oasis-open.org/policies-guidelines/ipr/), 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).
 
@@ -256,7 +256,7 @@ All other text is normative unless otherwise labeled.
 Here is a customized command line which will generate HTML from this markdown file (named `odata-data-aggregation-ext-v4.0-cs03.md`). Line breaks are added for readability only:
 
 ```
-pandoc -f gfm+tex_math_dollars+fenced_divs
+pandoc -f gfm+tex_math_dollars+fenced_divs+smart
        -t html
        -o odata-data-aggregation-ext-v4.0-cs03.html
        -c styles/markdown-styles-v1.7.3b.css
diff --git a/docs/odata-json-format/odata-json-format.html b/docs/odata-json-format/odata-json-format.html
index 231313fb6..0abeee3e8 100644
--- a/docs/odata-json-format/odata-json-format.html
+++ b/docs/odata-json-format/odata-json-format.html
@@ -138,12 +138,12 @@ 
 
    Abstract:
    
 
    The Open Data Protocol (OData) for representing and interacting with structured content is comprised of a set of specifications. The core specification for the protocol is in OData Version 4.02 Part 1: Protocol. This document extends the core specification by defining representations for OData requests and responses using a JSON format.
    
 
    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://www.oasis-open.org/committees/tc_home.php?wg_abbrev=odata#technical.
    
-
    TC members should send comments on this specification to the TC's email list. Others should send comments to the TC's public comment list, after subscribing to it by following the instructions at the "Send A Comment" button on the TC's web page at https://www.oasis-open.org/committees/odata/.
    
-
    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.
    
+
    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://www.oasis-open.org/committees/tc_home.php?wg_abbrev=odata#technical.
    
+
    TC members should send comments on this specification to the TC’s email list. Others should send comments to the TC’s public comment list, after subscribing to it by following the instructions at the “Send A Comment” button on the TC’s web page at https://www.oasis-open.org/committees/odata/.
    
+
    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.
    
+
    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-JSON-Format-v4.02]
    
@@ -151,7 +151,7 @@ 
    Citation format:
    
 
    Notices
    
 
    Copyright © OASIS Open 2023. 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.
    
+
    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.
    
 
    
 
    Table of Contents
    
@@ -318,7 +318,7 @@ 
    
 
    Here is a customized command line which will generate HTML from this markdown file (named odata-json-format-v4.02-csd01.md). Line breaks are added for readability only:
    
-
    pandoc -f gfm+tex_math_dollars+fenced_divs
+
    pandoc -f gfm+tex_math_dollars+fenced_divs+smart
        -t html
        -o odata-json-format-v4.02-csd01.html
        -c styles/markdown-styles-v1.7.3b.css
@@ -335,8 +335,8 @@ 
    2 JSON Format Design
    
 
    JSON, as described in RFC8259 defines a text format for serializing structured data. Objects are serialized as an unordered collection of name/value pairs.
    
 
    JSON does not define any semantics around the name/value pairs that make up an object, nor does it define an extensibility mechanism for adding control information to a payload.
    
-
    OData's JSON format extends JSON by defining general conventions for name/value pairs that annotate a JSON object, property or array. OData defines a set of canonical name/value pairs for control information such as ids, types, and links, and instance annotations MAY be used to add domain-specific information to the payload.
    
-
    A key feature of OData's JSON format is to allow omitting predictable parts of the wire format from the actual payload. To reconstitute this data on the receiving end, expressions are used to compute missing links, type information, and other control data. These expressions (together with the data on the wire) can be used by the client to compute predictable payload pieces as if they had been included on the wire directly.
    
+
    OData’s JSON format extends JSON by defining general conventions for name/value pairs that annotate a JSON object, property or array. OData defines a set of canonical name/value pairs for control information such as ids, types, and links, and instance annotations MAY be used to add domain-specific information to the payload.
    
+
    A key feature of OData’s JSON format is to allow omitting predictable parts of the wire format from the actual payload. To reconstitute this data on the receiving end, expressions are used to compute missing links, type information, and other control data. These expressions (together with the data on the wire) can be used by the client to compute predictable payload pieces as if they had been included on the wire directly.
    
 
    Control information is used in JSON to capture instance metadata that cannot be predicted (e.g. the next link of a collection) as well as a mechanism to provide values where a computed value would be wrong (e.g. if the media read link of one particular entity does not follow the standard URL conventions). Computing values from metadata expressions is compute intensive and some clients might opt for a larger payload size to avoid computational complexity; to accommodate for this the Accept header allows the client to control the amount of control information added to the response.
    
 
    To optimize streaming scenarios, there are a few restrictions that MAY be imposed on the sequence in which name/value pairs appear within JSON objects. For details on the ordering requirements see Payload Ordering Constraints.
    
 
    
@@ -389,7 +389,7 @@ 
    editLink: the link used to edit/update the entity, if the entity is updatable and the id does not represent a URL that can be used to edit the entity
 
  • navigationLink: the link used to retrieve the values of a navigation property
    • 
 
  • associationLink: the link used to describe the relationship between this entity and related entities
    • 
-
  • type: the type of the containing object or targeted property if the type of the object or targeted property cannot be heuristically determined from the data value, see section "Control Information: type (odata.type)".
    • 
+
  • type: the type of the containing object or targeted property if the type of the object or targeted property cannot be heuristically determined from the data value, see section “Control Information: type (odata.type)”.
    • 
 
 
    Media entities and stream properties may in addition contain the following control information:
    
 
      
@@ -419,7 +419,7 @@ 
      metadata parameter to specify the amount of metadata included in the response.
      
 
      Requests and responses MUST include the IEEE754Compatible parameter if Edm.Int64 and Edm.Decimal numbers are represented as strings.
      
-
      Requests and responses MAY add the streaming parameter with a value of true or false, see section "Payload Ordering Constraints".
      
+
      Requests and responses MAY add the streaming parameter with a value of true or false, see section “Payload Ordering Constraints”.
      
 
      4.2 Message Body
      
 
      Each message body is represented as a single JSON object. This object is either the representation of an entity, an entity reference or a complex type instance, or it contains a name/value pair whose name MUST be value and whose value is the correct representation for a primitive value, a collection of primitive values, a collection of complex values, a collection of entities, or a collection of objects that represent changes to a previous result.
      
 
      Client libraries MUST retain the order of objects within an array in JSON responses.
      
@@ -479,7 +479,7 @@ 
      
 
      Note that in OData 4.0 the streaming format parameter was prefixed with odata.. Payloads with an OData-Version header equal to 4.0 MUST include the odata. prefix. Payloads with an OData-Version header equal to 4.01 or greater SHOULD NOT include the odata. prefix.
      
 
      4.5 Control Information
      
-
      In addition to the "pure data" a message body MAY contain annotations and control information that is represented as name/value pairs whose names start with @.
      
+
      In addition to the “pure data” a message body MAY contain annotations and control information that is represented as name/value pairs whose names start with @.
      
 
      In requests and responses with an OData-Version header with a value of 4.0 control information names are prefixed with @odata., e.g. @odata.context. In requests and responses without such a header the odata. prefix SHOULD be omitted, e.g. @context.
      
 
      In some cases, control information is required in request payloads; this is called out in the following subsections.
      
 
      Receivers that encounter unknown annotations in any namespace or unknown control information MUST NOT stop processing and MUST NOT signal an error.
      
@@ -502,7 +502,7 @@ 
      OData-Protocol.
      
 
      4.5.3 Control Information: type (odata.type)
      
 
      The type control information specifies the type of a JSON object or name/value pair. Its value is a URI that identifies the type of the property or object. For built-in primitive types the value is the unqualified name of the primitive type. For payloads described by an OData-Version header with a value of 4.0, this name MUST be prefixed with the hash symbol (#); for non-OData 4.0 payloads, built-in primitive type values SHOULD be represented without the hash symbol, but consumers of 4.01 or greater payloads MUST support values with or without the hash symbol. For all other types, the URI may be absolute or relative to the type of the containing object. The root type may be absolute or relative to the root context URL.
      
-
      If the URI references a metadata document (that is, it's not just a fragment), it MAY refer to a specific version of that metadata document using the $schemaversion system query option defined in OData-Protocol.
      
+
      If the URI references a metadata document (that is, it’s not just a fragment), it MAY refer to a specific version of that metadata document using the $schemaversion system query option defined in OData-Protocol.
      
 
      For non-built in primitive types, the URI contains the namespace-qualified or alias-qualified type, specified as a URI fragment. For properties that represent a collection of values, the fragment is the namespace-qualified or alias-qualified element type enclosed in parentheses and prefixed with Collection. The namespace or alias MUST be defined or the namespace referenced in the metadata document of the service, see OData-CSDLJSON or OData-CSDLXML.
      
 
      The type control information MUST appear in requests and in responses with minimal or full metadata, if the type cannot be heuristically determined, as described below, and one of the following is true:
      
 
        
@@ -592,7 +592,7 @@ 
        4.5.12 Control Information: media* (odata.media*)
        
 
        For media entities and stream properties at least one of the control information mediaEditLink and mediaReadLink MUST be included in responses if they don't follow standard URL conventions as defined in OData-URL, sections 4.6 Addressing a property and 4.14 Addressing the Media Stream of a Media Entity, or if metadata=full is requested.
        
 
        The mediaEditLink control information contains a URL that can be used to update the binary stream associated with the media entity or stream property. It MUST be included for updatable streams if it differs from standard URL conventions relative to the edit link of the entity.
        
-
        The mediaReadLink control information contains a URL that can be used to read the binary stream associated with the media entity or stream property. It MUST be included if its value differs from the value of the associated mediaEditLink, if present, or if it doesn't follow standard URL conventions relative to the read link of the entity and the associated mediaEditLink is not present.
        
+
        The mediaReadLink control information contains a URL that can be used to read the binary stream associated with the media entity or stream property. It MUST be included if its value differs from the value of the associated mediaEditLink, if present, or if it doesn’t follow standard URL conventions relative to the read link of the entity and the associated mediaEditLink is not present.
        
 
        The mediaContentType control information MAY be included; its value SHOULD match the media type of the binary stream represented by the mediaReadLink URL. This is only a hint; the actual media type will be included in the Content-Type header when the resource is requested.
        
 
        The mediaEtag control information MAY be included; its value is the ETag of the binary stream represented by this media entity or stream property.
        
 
        The media* control information is not written in responses if metadata=none is requested.
        
@@ -822,7 +822,7 @@ 
        }
    
 
 
    7.5 Untyped Value
    
-
    OData 4.01 adds the built-in abstract types Edm.Untyped and Collection(Edm.Untyped)that services can use to advertise in metadata that there is a property of a particular name present, but there is no type to describe the structure of the property's values.
    
+
    OData 4.01 adds the built-in abstract types Edm.Untyped and Collection(Edm.Untyped)that services can use to advertise in metadata that there is a property of a particular name present, but there is no type to describe the structure of the property’s values.
    
 
    The value of an Edm.Untyped property MAY be a primitive value, a structural value, or a collection. If a collection, it may contain any combination of primitive values, structural values, and collections.
    
 
    The value of a property of type Collection(Edm.Untyped)MUST be a collection, and it MAY contain any combination of primitive values, structural values, and collections.
    
 
    Untyped values are the only place where a collection can directly contain a collection, or a collection can contain a mix of primitive values, structural values, and collections.
    
@@ -924,7 +924,7 @@ 
    8.5 Bin
 
  • modify the name of an existing category
    • 
 
  • assign an existing product with the id 42 to the category
    • 
 
  • assign an existing product 57 to the category and update its name
    • 
-
  • create a new product named "Wedges" and assign it to the category
    • 
+
  • create a new product named Wedges and assign it to the category
    • 
 
 
    At the end of the request, the updated category contains exactly the three specified products.
    
 
    PATCH http://host/service/Categories(6) HTTP/1.1
@@ -1062,7 +1062,7 @@ 
    streaming=true content-type parameter is set, it MUST come before the value name/value pair. If the response represents a partial result, the count name/value pair MUST appear in the first partial response, and it MAY appear in subsequent partial responses (in which case it may vary from response to response).
    
 
    The value of the value name/value pair is a JSON array where each element is representation of an entity or a representation of an entity reference. An empty collection is represented as an empty JSON array.
    
-
    Functions or actions that are bound to this collection of entities are advertised in the "wrapper object" in the same way as functions or actions are advertised in the object representing a single entity.
    
+
    Functions or actions that are bound to this collection of entities are advertised in the “wrapper object” in the same way as functions or actions are advertised in the object representing a single entity.
    
 
    The nextLink control information MUST be included in a response that represents a partial result.
    
 
    
 
    Example 28:
    
@@ -1101,7 +1101,7 @@ 
    1
 
    
 
    
 
    15 Delta Payload
    
-
    The non-format specific aspects of the delta handling are described in the section "Requesting Changes" in OData-Protocol.
    
+
    The non-format specific aspects of the delta handling are described in the section “Requesting Changes” in OData-Protocol.
    
 
    15.1 Delta Responses
    
 
    Responses from a delta request are returned as a JSON object.
    
 
    The JSON object for a delta response to a single entity is either an added, changed, or deleted entity.
    
@@ -1113,11 +1113,11 @@ 
    15.
 
    
 
    Example 33: a 4.01 delta response with five changes, in order of occurrence
    
 
      
-
    1. ContactName for customer 'BOTTM' was changed to "Susan Halvenstern"
      2. 
-
    2. Order 10643 was removed from customer 'ALFKI'
      3. 
-
    3. Order 10645 was added to customer 'BOTTM'
      4. 
+
    4. ContactName for customer BOTTM was changed to Susan Halvenstern
      5. 
+
    5. Order 10643 was removed from customer ALFKI
      6. 
+
    6. Order 10645 was added to customer BOTTM
      7. 
 
    7. The shipping information for order 10643 was updated
      8. 
-
    8. Customer 'ANTON' was deleted
      9. 
+
    9. Customer ANTON was deleted
      10. 
 
    
 
    {
   "@context": "http://host/service/$metadata#Customers/$delta",
@@ -1173,16 +1173,16 @@ 
    
 
    Example 34: 4.01 delta response customers with expanded orders represented inline as a delta
    
 
      
-
    1. Customer 'BOTTM':
+
    2. Customer BOTTM:
 
        
-
      1. ContactName was changed to "Susan Halvenstern"
        2. 
+
      2. ContactName was changed to Susan Halvenstern
        3. 
 
      3. Order 10645 was added
        4. 
 
      3. 
-
    3. Customer 'ALFKI':
+
    4. Customer ALFKI:
 
        
 
      1. Order 10643 was removed
        2. 
 
      5. 
-
    5. Customer 'ANTON' was deleted
      6. 
+
    6. Customer ANTON was deleted
      7. 
 
    
 
    {
   "@context": "http://host/service/$metadata#Customers/$delta",
@@ -1238,15 +1238,15 @@ 
    15.3 D
 
    The representation of deleted-entity objects differs between OData 4.0 and OData 4.01.
    
 
    In OData 4.0 payloads the deleted-entity object MUST include the following properties, regardless of the specified metadata value:
    
 
      
-
    • Control information context - The context URL fragment MUST be #{entity-set}/$deletedEntity, where {entity-set} is the entity set of the deleted entity
      • 
-
    • id - The id of the deleted entity (same as the id returned or computed when calling GET on resource), which may be absolute or relative
      • 
+
    • Control information context — The context URL fragment MUST be #{entity-set}/$deletedEntity, where {entity-set} is the entity set of the deleted entity
      • 
+
    • id — The id of the deleted entity (same as the id returned or computed when calling GET on resource), which may be absolute or relative
      • 
 
    
 
    In OData 4.0 payloads the deleted-entity object MAY include the following optional property, regardless of the specified metadata value, and MAY include annotations:
    
 
      
-
    • reason - either deleted, if the entity was deleted (destroyed), or changed if the entity was removed from membership in the result (i.e., due to a data change).
      • 
+
    • reason — either deleted, if the entity was deleted (destroyed), or changed if the entity was removed from membership in the result (i.e., due to a data change).
      • 
 
    
 
    
-
    Example 36: deleted entity in OData 4.0 response - note that id is a property, not control information
    
+
    Example 36: deleted entity in OData 4.0 response — note that id is a property, not control information
    
 
    {
   "@context":"#Customers/$deletedEntity",
   "reason":"deleted",
@@ -1256,7 +1256,7 @@ 
    15.3 D
 
    In OData 4.01 payloads the deleted-entity object MUST include the following properties, regardless of the specified metadata value:
    
 
      
 
    • Control information removed, whose value is an object that MAY contain a property named reason. If present, the value of reason MUST be either deleted if the entity was deleted (destroyed), or changed if the entity was removed from membership in the result either due to change in value such that the entity no longer matches the defining query or because the entity was removed from the collection. The object MAY include annotations, and clients SHOULD NOT error due to the presence of additional properties that MAY be defined by future versions of this specification. For ordered payloads, the control information removed MUST immediately follow the context control information, if present, otherwise it MUST be the first property in the deleted entity.
      • 
-
    • Control information id or all of the entity's key fields. The id control information MUST appear if any of the entity's key fields are omitted from the response or the entity-id is not identical to the canonical URL of the entity. For ordered payloads, the control information id, if present, MUST immediately follow the control information removed.
      • 
+
    • Control information id or all of the entity’s key fields. The id control information MUST appear if any of the entity’s key fields are omitted from the response or the entity-id is not identical to the canonical URL of the entity. For ordered payloads, the control information id, if present, MUST immediately follow the control information removed.
      • 
 
    
 
    For full metadata the context control information MUST be included. It also MUST be included if the entity set of the deleted entity cannot be determined from the surrounding context.
    
 
    The deleted-entity object MAY include additional properties of the entity, as well as annotations, and MAY include related entities, related deleted entities, or a delta or full representation of a related collection of entities, to represent related entities that have been modified or deleted.
    
@@ -1284,9 +1284,9 @@ 
    
 
    Deleted links within a delta response are represented as deleted-link objects.
    
@@ -1297,28 +1297,28 @@ 
    15.6 Update a Collection of Entities
    
 
    The body of a PATCH request to a URL identifying a collection of entities is a JSON object. It MUST contain the context control information with a string value of #$delta, and it MUST contain an array-valued property named value containing all added, changed, or deleted entities, as well as added or deleted links between entities.
    
 
    
 
    Example 39: 4.01 delta response customers with expanded orders represented inline as a delta
    
 
      
-
    1. Add customer 'EASTC'
      2. 
-
    2. Change ContactName of customer 'AROUT'
      3. 
-
    3. Delete customer 'ANTON'
      4. 
-
    4. Change customer 'ALFKI':
+
    5. Add customer EASTC
      6. 
+
    6. Change ContactName of customer AROUT
      7. 
+
    7. Delete customer ANTON
      8. 
+
    8. Change customer ALFKI:
 
        
 
      1. Create order 11011
        2. 
 
      2. Add link to existing order 10692
        3. 
 
      3. Change ShippedDate of related order 10835
        4. 
 
      4. Delete link to order 10643
        5. 
 
      9. 
-
    9. Add link between customer 'ANATR' and order 10643
      10. 
-
    10. Delete link between customer 'DUMON' and order 10311
      11. 
+
    11. Add link between customer ANATR and order 10643
      12. 
+
    12. Delete link between customer DUMON and order 10311
      13. 
 
    
 
    {
   "@context": "#$delta",
@@ -1583,7 +1583,7 @@ 
    19.1 Batc
 }
    
 
    
 
    19.2 Referencing New Entities
    
-
    The entity returned by a preceding request can be referenced in the request URL of subsequent requests. If the Location header in the response contains a relative URL, clients MUST be able to resolve it relative to the request's URL even if that contains such a reference.
    
+
    The entity returned by a preceding request can be referenced in the request URL of subsequent requests. If the Location header in the response contains a relative URL, clients MUST be able to resolve it relative to the request’s URL even if that contains such a reference.
    
 
    
 
    Example 49: a batch request that contains the following operations in the order listed:
    
 
    
 
    
 
    19.6 Asynchronous Batch Requests
    
-
    A batch request that specifies the respond-async preference MAY be executed asynchronously. This means that the "outer" batch request is executed asynchronously; this preference does not automatically cascade down to the individual requests within the batch. After successful execution of the batch request the response to the batch request is returned in the body of a response to an interrogation request against the status monitor resource URL, see section "Asynchronous Requests" in OData-Protocol.
    
+
    A batch request that specifies the respond-async preference MAY be executed asynchronously. This means that the “outer” batch request is executed asynchronously; this preference does not automatically cascade down to the individual requests within the batch. After successful execution of the batch request the response to the batch request is returned in the body of a response to an interrogation request against the status monitor resource URL, see section “Asynchronous Requests” in OData-Protocol.
    
 
    A service MAY return interim results to an asynchronously executing batch. It does this by responding with 200 OK to a GET request to the monitor resource and including a nextLink control information in the JSON batch response, thus signaling that the response is only a partial result. A subsequent GET request to the next link MAY result in a 202 Accepted response with a location header pointing to a new status monitor resource.
    
 
    
 
    Example 52: referencing the example 47 above again, assume that the request is sent with the respond-async preference. This results in a 202 response pointing to a status monitor resource:
    
 
    HTTP/1.1 202 Accepted
 Location: http://service-root/async-monitor-0
 Retry-After: ###
    
-
    When interrogating the monitor URL only the first request in the batch has finished processing and all the remaining requests are still being processed. The service signals that asynchronous processing is "finished" and returns a partial result with the first response and a next link. The client did not explicitly accept application/http, so the response is "unwrapped" and only indicates with the AsyncResult header that it is a response to a status monitor resource:
    
+
    When interrogating the monitor URL only the first request in the batch has finished processing and all the remaining requests are still being processed. The service signals that asynchronous processing is “finished” and returns a partial result with the first response and a next link. The client did not explicitly accept application/http, so the response is “unwrapped” and only indicates with the AsyncResult header that it is a response to a status monitor resource:
    
 
    HTTP/1.1 200 OK
 AsyncResult: 200
 OData-Version: 4.01
@@ -1782,7 +1782,7 @@ 
    
 
    20 Instance Annotations
    
 
    Annotations are an extensibility mechanism that allows services and clients to include information other than the raw data in the request or response.
    
-
    Annotations are name/value pairs that have an at (@) and a dot (.) as part of the name. The part after the "at" sign (@) is the annotation identifier. It consists of the namespace or alias of the schema that defines the term, followed by a dot (.), followed by the name of the term, optionally followed by a hash (#) and a qualifier. The namespace or alias MUST be defined in the metadata document, see OData-CSDLJSON or OData-CSDLXML
    
+
    Annotations are name/value pairs that have an at (@) and a dot (.) as part of the name. The part after the “at” sign (@) is the annotation identifier. It consists of the namespace or alias of the schema that defines the term, followed by a dot (.), followed by the name of the term, optionally followed by a hash (#) and a qualifier. The namespace or alias MUST be defined in the metadata document, see OData-CSDLJSON or OData-CSDLXML
    
 
    The annotation identifier odata is reserved for future extensions of the protocol and format. Instance annotations MUST have a namespace or alias that is different from odata.
    
 
    Annotations can be applied to any name/value pair in a JSON payload that represents a value of any type from the entity data model. Clients should never error due to an unexpected annotation in a JSON payload.
    
 
    Annotations are always expressed as name/value pairs. For entity data model constructs represented as JSON objects the annotation name/value pairs are placed within the object; for constructs represented as JSON arrays or primitives they are placed next to the annotated model construct. When annotating a payload that represents a single primitive or collection value, the annotations for the value appear next to the value property and are not prefixed with a property name.
    
@@ -1804,15 +1804,15 @@ 
    20.1 Annotate a JSON Object
    
 
    When annotating a name/value pair for which the value is represented as a JSON object, each annotation is placed within the object and represented as a single name/value pair.
    
-
    The name always starts with the "at" sign (@), followed by the annotation identifier.
    
+
    The name always starts with the “at” sign (@), followed by the annotation identifier.
    
 
    The value MUST be an appropriate value for the annotation.
    
 
    20.2 Annotate a JSON Array or Primitive
    
 
    When annotating a name/value pair for which the value is represented as a JSON array or primitive value, each annotation that applies to this name/value pair MUST be represented as a single name/value pair and placed immediately prior to the annotated name/value pair, with the exception of the nextLink or collectionAnnotations control information, which can appear immediately before or after the annotated collection.
    
-
    The name is the same as the name of the property or name/value pair being annotated, followed by the "at" sign (@), followed by the annotation identifier.
    
+
    The name is the same as the name of the property or name/value pair being annotated, followed by the “at” sign (@), followed by the annotation identifier.
    
 
    The value MUST be an appropriate value for the annotation.
    
 
    20.3 Annotate a Primitive Value within a JSON Array
    
 
    Individual primitive elements within a JSON array can be annotated by applying the collectionAnnotations control information to the array containing the primitive member.
    
-
    The control information must come with other annotations or control information immediately before or after the collection valued property. The name of the property representing the control information is the same as the name of the collection-valued property, followed by the "at" sign (@), followed by the collectionAnnotations identifier.
    
+
    The control information must come with other annotations or control information immediately before or after the collection valued property. The name of the property representing the control information is the same as the name of the collection-valued property, followed by the “at” sign (@), followed by the collectionAnnotations identifier.
    
 
    
 
    21 Error Handling
    
 
    OData requests may return a well formed error response, an in-stream error, or error information within a success payload.
    
@@ -1970,49 +1970,49 @@ 
    [OData-ABNF]
    
 
    ABNF components: OData ABNF Construction Rules Version 4.02 and OData ABNF Test Cases.
    
-See link in "Related work" section on cover page.
    
+See link in “Related work” section on cover page.
    
 
    [OData-CSDL]
    
 
    OData Common Schema Definition Language (CSDL) JSON Representation Version 4.02.
    
-See link in "Related work" section on cover page.
    
+See link in “Related work” section on cover page.
    
 
    OData Common Schema Definition Language (CSDL) XML Representation Version 4.02.
    
-See link in "Related work" section on cover page.
    
+See link in “Related work” section on cover page.
    
 
    [OData-Protocol]
    
 
    OData Version 4.02. Part 1: Protocol.
    
-See link in "Related work" section on cover page.
    
+See link in “Related work” section on cover page.
    
 
    [OData-URL]
    
 
    OData Version 4.02. Part 2: URL Conventions.
    
-See link in "Related work" section on cover page.
    
+See link in “Related work” section on cover page.
    
 
    [OData-VocCap]
    
 
    OData Vocabularies Version 4.0: Capabilities Vocabulary.
    
-See link in "Related work" section on cover page.
    
+See link in “Related work” section on cover page.
    
 
    [OData-VocCore]
    
 
    OData Vocabularies Version 4.0: Core Vocabulary.
    
-See link in "Related work" section on cover page.
    
+See link in “Related work” section on cover page.
    
 
    [RFC2119]
    
-
    Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997
    
+
    Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997
    
 https://www.rfc-editor.org/info/rfc2119.
    
 
    [RFC3986]
    
-
    Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", IETF RFC3986, January 2005 https://tools.ietf.org/html/rfc3986.
    
+
    Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, IETF RFC3986, January 2005 https://tools.ietf.org/html/rfc3986.
    
 
    [RFC3987]
    
-
    Duerst, M. and, M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005 https://tools.ietf.org/html/rfc3987.
    
+
    Duerst, M. and, M. Suignard, “Internationalized Resource Identifiers (IRIs)”, RFC 3987, January 2005 https://tools.ietf.org/html/rfc3987.
    
 
    [RFC4648]
    
-
    Josefsson, S,, "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006 https://tools.ietf.org/html/rfc4648.
    
+
    Josefsson, S,, “The Base16, Base32, and Base64 Data Encodings”, RFC 4648, October 2006 https://tools.ietf.org/html/rfc4648.
    
 
    [RFC5646]
    
-
    Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009 http://tools.ietf.org/html/rfc5646.
    
+
    Phillips, A., Ed., and M. Davis, Ed., “Tags for Identifying Languages”, BCP 47, RFC 5646, September 2009 http://tools.ietf.org/html/rfc5646.
    
 
    [RFC7493]
    
-
    Bray, T., Ed., "The I-JSON Message Format", RFC7493, March 2015 https://tools.ietf.org/html/rfc7493.
    
+
    Bray, T., Ed., “The I-JSON Message Format”, RFC7493, March 2015 https://tools.ietf.org/html/rfc7493.
    
 
    [RFC7946]
    
-
    Howard Butler, Martin Daly, Alan Doyle, Sean Gillies, Stefan Hagen and Tim Schaub, "The GeoJSON Format", RFC 7946, August 2016. http://tools.ietf.org/html/rfc7946.
    
+
    Howard Butler, Martin Daly, Alan Doyle, Sean Gillies, Stefan Hagen and Tim Schaub, “The GeoJSON Format”, RFC 7946, August 2016. http://tools.ietf.org/html/rfc7946.
    
 
    [RFC8174]
    
-
    Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017
    
+
    Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017
    
 https://www.rfc-editor.org/info/rfc8174.
    
 
    [RFC8259]
    
-
    Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 8259, December 2017 http://tools.ietf.org/html/rfc8259.
    
+
    Bray, T., Ed., “The JavaScript Object Notation (JSON) Data Interchange Format”, RFC 8259, December 2017 http://tools.ietf.org/html/rfc8259.
    
 
    A.2 Informative References
    
 
    [ECMAScript]
    
 
    ECMAScript 2023 Language Specification, 14th Edition, June 2023. Standard ECMA-262. https://www.ecma-international.org/publications-and-standards/standards/ecma-262/.
    
 
    [GeoJSON-2008]
    
-
    Butler, H., Daly, M., Doyle, A., Gillies, S., Schaub, T., and C. Schmidt, "The GeoJSON Format Specification", June 2008 http://geojson.org/geojson-spec.html.
    
+
    Butler, H., Daly, M., Doyle, A., Gillies, S., Schaub, T., and C. Schmidt, “The GeoJSON Format Specification”, June 2008 http://geojson.org/geojson-spec.html.
    
 
    
 
    Appendix B. Safety, Security and Privacy Considerations
    
 
    This specification raises no security issues.
    
@@ -2115,14 +2115,14 @@ 
    Appendix E. Notice
 
 
 
    Copyright © OASIS Open 2023. All Rights Reserved.
    
-
    All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.
    
+
    All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the “OASIS IPR Policy”). The full Policy may be found at the OASIS website.
    
 
    This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.
    
 
    The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
    
-
    This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
    
+
    This document and the information contained herein is provided on an “AS IS” basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
    
 
    As stated in the OASIS IPR Policy, the following three paragraphs in brackets apply to OASIS Standards Final Deliverable documents (Committee Specification, Candidate OASIS Standard, OASIS Standard, or Approved Errata).
    
 
    [OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Standards Final Deliverable, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this deliverable.]
    
 
    [OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this OASIS Standards Final Deliverable by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this OASIS Standards Final Deliverable. OASIS may include such claims on its website, but disclaims any obligation to do so.]
    
-
    [OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this OASIS Standards Final Deliverable or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Standards Final Deliverable, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.]
    
-
    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. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark/ for above guidance.
    
+
    [OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this OASIS Standards Final Deliverable or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS’ procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Standards Final Deliverable, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.]
    
+
    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. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark/ for above guidance.
    
 
 
diff --git a/docs/odata-json-format/odata-json-format.md b/docs/odata-json-format/odata-json-format.md
index 4eb96a011..5c77e4c8c 100644
--- a/docs/odata-json-format/odata-json-format.md
+++ b/docs/odata-json-format/odata-json-format.md
@@ -58,7 +58,7 @@ The Open Data Protocol (OData) for representing and interacting with structured
 #### 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://www.oasis-open.org/committees/tc_home.php?wg_abbrev=odata#technical.
 
-TC members should send comments on this specification to the TC's email list. Others should send comments to the TC's public comment list, after subscribing to it by following the instructions at the "[Send A Comment](https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=odata)" button on the TC's web page at https://www.oasis-open.org/committees/odata/.
+TC members should send comments on this specification to the TC's email list. Others should send comments to the TC's public comment list, after subscribing to it by following the instructions at the "Send A Comment" button on the TC's web page at https://www.oasis-open.org/committees/odata/.
 
 This specification is provided under the [RF on RAND Terms Mode](https://www.oasis-open.org/policies-guidelines/ipr/#RF-on-RAND-Mode) of the [OASIS IPR Policy](https://www.oasis-open.org/policies-guidelines/ipr/), 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).
 
@@ -239,7 +239,7 @@ All other text is normative unless otherwise labeled.
 Here is a customized command line which will generate HTML from this markdown file (named `odata-json-format-v4.02-csd01.md`). Line breaks are added for readability only:
 
 ```
-pandoc -f gfm+tex_math_dollars+fenced_divs
+pandoc -f gfm+tex_math_dollars+fenced_divs+smart
        -t html
        -o odata-json-format-v4.02-csd01.html
        -c styles/markdown-styles-v1.7.3b.css
@@ -1714,7 +1714,7 @@ Example 22: submit a partial update request to:
 - modify the name of an existing category
 - assign an existing product with the id 42 to the category
 - assign an existing product 57 to the category and update its name
-- create a new product named "Wedges" and assign it to the category
+- create a new product named `Wedges` and assign it to the category
 
 At the end of the request, the updated category contains exactly the
 three specified products.
@@ -2120,11 +2120,11 @@ or deleted links.
 Example 33: a 4.01 delta response with five changes, in order of
 occurrence
 
-  1. `ContactName` for customer 'BOTTM' was changed to "Susan Halvenstern"
-  2. Order 10643 was removed from customer 'ALFKI'
-  3. Order 10645 was added to customer 'BOTTM'
+  1. `ContactName` for customer `BOTTM` was changed to `Susan Halvenstern`
+  2. Order 10643 was removed from customer `ALFKI`
+  3. Order 10645 was added to customer `BOTTM`
   4. The shipping information for order 10643 was updated
-  5. Customer 'ANTON' was deleted
+  5. Customer `ANTON` was deleted
 
 ```json
 {
@@ -2232,12 +2232,12 @@ links](#DeletedLink).
 Example 34: 4.01 delta response customers with expanded orders
 represented inline as a delta
 
-  1. Customer 'BOTTM':
-     1. `ContactName` was changed to "Susan Halvenstern"
+  1. Customer `BOTTM`:
+     1. `ContactName` was changed to `Susan Halvenstern`
      2. Order 10645 was added
-  2. Customer 'ALFKI':
+  2. Customer `ALFKI`:
      1. Order 10643 was removed
-  3. Customer 'ANTON' was deleted
+  3. Customer `ANTON` was deleted
 
 ```json
 {
@@ -2325,10 +2325,10 @@ In OData 4.0 payloads the deleted-entity object MUST include the
 following properties, regardless of the specified
 [`metadata`](#ControllingtheAmountofControlInformationinResponses) value:
 
-- Control information [`context`](#ControlInformationcontextodatacontext) - The context URL fragment MUST be
+- Control information [`context`](#ControlInformationcontextodatacontext) --- The context URL fragment MUST be
   `#{entity-set}/$deletedEntity`, where
   `{entity-set}` is the entity set of the deleted entity
-- `id` - The [id](#ControlInformationidodataid) of the deleted entity
+- `id` --- The [id](#ControlInformationidodataid) of the deleted entity
   (same as the [id](#ControlInformationidodataid)
   returned or computed when calling GET on resource), which may be
   absolute or [relative](#RelativeURLs)
@@ -2338,12 +2338,12 @@ following optional property, regardless of the specified
 [`metadata`](#ControllingtheAmountofControlInformationinResponses) value, and MAY include
 [annotations](#InstanceAnnotations):
 
-- `reason` - either `deleted`, if the entity was deleted (destroyed),
+- `reason` --- either `deleted`, if the entity was deleted (destroyed),
   or `changed` if the entity was removed from membership in the
   result (i.e., due to a data change).
 
 ::: example
-Example 36: deleted entity in OData 4.0 response - note that `id` is
+Example 36: deleted entity in OData 4.0 response --- note that `id` is
 a property, not control information
 ```json
 {
@@ -2438,13 +2438,13 @@ The link object MUST include the following properties, regardless of the specifi
   the context URL fragment MUST be `#{entity-set}/$link`,
   where `{entity-set}` is the entity set containing the source
   entity
-- `source` - The [id](#ControlInformationidodataid) of the entity from which
+- `source` --- The [id](#ControlInformationidodataid) of the entity from which
   the relationship is defined, which may be absolute or
   [relative](#RelativeURLs)
-- `relationship` - The path from the source object to the navigation property which MAY
+- `relationship` --- The path from the source object to the navigation property which MAY
   traverse one or more complex properties, type cast segments, or members
   of ordered collections
-- `target` - The [id](#ControlInformationidodataid) of the related entity,
+- `target` --- The [id](#ControlInformationidodataid) of the related entity,
   which may be absolute or [relative](#RelativeURLs)
 
 ## 15.5 Deleted Link
@@ -2462,16 +2462,16 @@ path in the initial request, unless either of the following is true:
   `source` and `relationship`.
 
 The deleted-link object MUST include the following properties, regardless of the specified [`metadata`](#ControllingtheAmountofControlInformationinResponses) value, and MAY include [annotations](#InstanceAnnotations):
-- [`context`](#ControlInformationcontextodatacontext) - the context URL fragment MUST be
+- [`context`](#ControlInformationcontextodatacontext) --- the context URL fragment MUST be
   `#{entity-set}/$deletedLink`, where
   `{entity-set}` is the entity set containing the source entity
-- `source` - The [id](#ControlInformationidodataid) of the entity from which
+- `source` --- The [id](#ControlInformationidodataid) of the entity from which
   the relationship is defined, which may be absolute or
   [relative](#RelativeURLs)
-- `relationship` - The path from the source object to the navigation property which MAY
+- `relationship` --- The path from the source object to the navigation property which MAY
   traverse one or more complex properties, type cast segments, or members
   of ordered collections
-- `target` - The [id](#ControlInformationidodataid) of the related entity for
+- `target` --- The [id](#ControlInformationidodataid) of the related entity for
 multi-valued navigation properties, which may be absolute or
 [relative](#RelativeURLs). For delta payloads
 that do not specify an `OData-Version` header value of `4.0`,
@@ -2492,16 +2492,16 @@ entities, as well as [added](#AddedLink) or
 ::: example
 Example 39: 4.01 delta response customers with expanded orders represented
 inline as a delta
-  1. Add customer 'EASTC'
-  2. Change `ContactName` of customer 'AROUT'
-  3. Delete customer 'ANTON'
-  4. Change customer 'ALFKI':
+  1. Add customer `EASTC`
+  2. Change `ContactName` of customer `AROUT`
+  3. Delete customer `ANTON`
+  4. Change customer `ALFKI`:
      1. Create order 11011
      2. Add link to existing order 10692
      3. Change `ShippedDate` of related order 10835
      4. Delete link to order 10643
-  5. Add link between customer 'ANATR' and order 10643
-  6. Delete link between customer 'DUMON' and order 10311
+  5. Add link between customer `ANATR` and order 10643
+  6. Delete link between customer `DUMON` and order 10311
 ```json
 {
   "@context": "#$delta",
diff --git a/docs/odata-protocol/odata-protocol.html b/docs/odata-protocol/odata-protocol.html
index a2ec11f21..4a2ba23ef 100644
--- a/docs/odata-protocol/odata-protocol.html
+++ b/docs/odata-protocol/odata-protocol.html
@@ -141,12 +141,12 @@ 
    
 
    Abstract:
    
 
    The Open Data Protocol (OData) enables the creation of REST-based data services, which allow resources, identified using Uniform Resource Locators (URLs) and defined in an Entity Data Model (EDM), to be published and edited by Web clients using simple HTTP messages. This document defines the core semantics and facilities of the protocol.
    
 
    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://www.oasis-open.org/committees/tc_home.php?wg_abbrev=odata#technical.
    
-
    TC members should send comments on this specification to the TC's email list. Others should send comments to the TC's public comment list, after subscribing to it by following the instructions at the "Send A Comment" button on the TC's web page at https://www.oasis-open.org/committees/odata/.
    
-
    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.
    
+
    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://www.oasis-open.org/committees/tc_home.php?wg_abbrev=odata#technical.
    
+
    TC members should send comments on this specification to the TC’s email list. Others should send comments to the TC’s public comment list, after subscribing to it by following the instructions at the “Send A Comment” button on the TC’s web page at https://www.oasis-open.org/committees/odata/.
    
+
    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.
    
+
    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-v4.02-Part1]
    
@@ -154,7 +154,7 @@ 
    Citation format:
    
 
    Notices
    
 
    Copyright © OASIS Open 2023. 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.
    
+
    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.
    
 
    
 
    Table of Contents
    
@@ -307,7 +307,7 @@ 
    Table of Contents
    
 
  • 11.2.4 Requesting Individual Properties
 
    • 
 
  • 11.2.5 Specifying Properties to Return
 
 
    
 
    3 Data Model
    
-
    This section provides a high-level description of the Entity Data Model (EDM): the abstract data model that is used to describe the data exposed by an OData service. An OData Metadata Document is a representation of a service's data model exposed for client consumption.
    
+
    This section provides a high-level description of the Entity Data Model (EDM): the abstract data model that is used to describe the data exposed by an OData service. An OData Metadata Document is a representation of a service’s data model exposed for client consumption.
    
 
    The central concepts in the EDM are entities, relationships, entity sets, actions, and functions.
    
 
    Entities are instances of entity types (e.g. Customer, Employee, etc.).
    
 
    Entity types are named structured types with a key. They define the named properties and relationships of an entity. Entity types may derive by single inheritance from other entity types.
    
 
    The key of an entity type is formed from a subset of the primitive properties (e.g. CustomerId, OrderId, LineId, etc.) of the entity type.
    
 
    Complex types are keyless named structured types consisting of a set of properties. These are value types whose instances cannot be referenced outside of their containing entity. Complex types are commonly used as property values in an entity or as parameters to operations.
    
-
    Properties declared as part of a structured type's definition are called declared properties. Instances of structured types may contain additional undeclared dynamic properties. A dynamic property cannot have the same name as a declared property. Entity or complex types which allow clients to persist additional undeclared properties are called open types.
    
+
    Properties declared as part of a structured type’s definition are called declared properties. Instances of structured types may contain additional undeclared dynamic properties. A dynamic property cannot have the same name as a declared property. Entity or complex types which allow clients to persist additional undeclared properties are called open types.
    
 
    Relationships from one entity to another are represented as navigation properties. Navigation properties are generally defined as part of an entity type, but can also appear on entity instances as undeclared dynamic navigation properties. Each relationship has a cardinality.
    
 
    Enumeration types are named primitive types whose values are named constants with underlying integer values.
    
 
    Type definitions are named primitive types with fixed facet values such as maximum length or precision. Type definitions can be used in place of primitive typed properties, for example, within property definitions.
    
-
    Entity sets are named collections of entities (e.g. Customers is an entity set containing Customer entities). An entity's key uniquely identifies the entity within an entity set. If multiple entity sets use the same entity type, the same combination of key values can appear in more than one entity set and identifies different entities, one per entity set where this key combination appears. Each of these entities has a different entity-id. Entity sets provide entry points into the data model.
    
+
    Entity sets are named collections of entities (e.g. Customers is an entity set containing Customer entities). An entity’s key uniquely identifies the entity within an entity set. If multiple entity sets use the same entity type, the same combination of key values can appear in more than one entity set and identifies different entities, one per entity set where this key combination appears. Each of these entities has a different entity-id. Entity sets provide entry points into the data model.
    
 
    Operations allow the execution of custom logic on parts of a data model. Functions are operations that do not have side effects and may support further composition, for example, with additional filter operations, functions or an action. Actions are operations that allow side effects, such as data modification, and cannot be further composed in order to avoid non-deterministic behavior. Actions and functions are either bound to a type, enabling them to be called as members of an instance of that type, or unbound, in which case they are called as static operations. Action imports and function imports enable unbound actions and functions to be called from the service root.
    
 
    Singletons are named entities which can be accessed as direct children of the entity container. A singleton may also be a member of an entity set.
    
 
    An OData resource is anything in the model that can be addressed (an entity set, entity, property, or operation).
    
@@ -565,20 +565,20 @@ 
    4 Service M
 
    An OData service exposes two well-defined resources that describe its data model; a service document and a metadata document.
    
 
    The service document lists entity sets, functions, and singletons that can be retrieved. Clients can use the service document to navigate the model in a hypermedia-driven fashion.
    
 
    The metadata document describes the types, sets, functions and actions understood by the OData service. Clients can use the metadata document to understand how to query and interact with entities in the service.
    
-
    In addition to these two "fixed" resources, an OData service consists of dynamic resources. The URLs for many of these resources can be computed from the information in the metadata document.
    
+
    In addition to these two “fixed” resources, an OData service consists of dynamic resources. The URLs for many of these resources can be computed from the information in the metadata document.
    
 
    See Requesting Data and Data Modification for details.
    
 
    4.1 Entity-Ids and Entity References
    
 
    Whereas entities within an entity set are uniquely identified by their key values, entities are also uniquely identified by a durable, opaque, globally unique entity-id. The entity-id MUST be an IRI as defined in RFC3987 and MAY be expressed in payloads, headers, and URLs as a relative reference as appropriate. While the client MUST be prepared to accept any IRI, services MUST use valid URIs in this version of the specification since there is currently no lossless representation of an IRI in the EntityId header.
    
 
    Services are strongly encouraged to use the canonical URL for an entity as defined in OData-URL as its entity-id, but clients cannot assume the entity-id can be used to locate the entity unless the Core.DereferenceableIDs term is applied to the entity container, nor can the client assume any semantics from the structure of the entity-id. The canonical resource $entity provides a general mechanism for resolving an entity-id into an entity representation.
    
 
    Services that use the standard URL conventions for entity-ids annotate their entity container with the term Core.ConventionalIDs, see OData-VocCore.
    
-
    Entity references refer to an entity using the entity's entity-id.
    
+
    Entity references refer to an entity using the entity’s entity-id.
    
 
    4.2 Read URLs and Edit URLs
    
 
    The read URL of an entity is the URL that can be used to read the entity.
    
 
    The edit URL of an entity is the URL that can be used to update or delete the entity.
    
 
    The edit URL of a property is the edit URL of the entity with appended segment(s) containing the path to the property.
    
 
    Services are strongly encouraged to use the canonical URL for an entity as defined in OData-URL for both the read URL and the edit URL of an entity, with a cast segment to the type of the entity appended to the canonical URL if the type of the entity is derived from the declared type of the entity set. However, clients cannot assume this convention and must use the links specified in the payload according to the appropriate format as the two URLs may be different from one another, or one or both of them may differ from convention.
    
 
    4.3 Transient Entities
    
-
    Transient entities are instances of an entity type that are "calculated on the fly" and only exist within a single payload. They cannot be reread or updated and consequently possess neither a stable entity-id nor a read URL or an update URL.
    
+
    Transient entities are instances of an entity type that are “calculated on the fly” and only exist within a single payload. They cannot be reread or updated and consequently possess neither a stable entity-id nor a read URL or an update URL.
    
 
    4.4 Default Namespaces
    
 
    References to actions, functions, and types within a URL typically requires prefixing the name of the action, function, or type with the namespace or alias in which it is defined. This namespace qualification enables differentiating between similarly named elements across schema, or between properties and bound functions, actions, or types with the same name.
    
 
    Services MAY define one or more default namespaces through the Core.DefaultNamespace term defined in OData-VocCore. Functions, actions and types in a default namespace can be referenced in URLs with or without namespace or alias qualification.
    
@@ -618,7 +618,7 @@ 
    6 Extensi
 
    The OData protocol supports both user- and version-driven extensibility through a combination of versioning, convention, and explicit extension points.
    
 
    6.1 Query Option Extensibility
    
 
    Query options within the request URL can control how a particular request is processed by the service.
    
-
    OData-defined system query options are optionally prefixed with "$". Services may support additional custom query options not defined in the OData specification, but they MUST NOT begin with the "$" or "@" character and MUST NOT conflict with any OData-defined system query options defined in the OData version supported by the service.
    
+
    OData-defined system query options are optionally prefixed with “$”. Services may support additional custom query options not defined in the OData specification, but they MUST NOT begin with the “$” or “@” character and MUST NOT conflict with any OData-defined system query options defined in the OData version supported by the service.
    
 
    OData services SHOULD NOT require any query options to be specified in a request. Services SHOULD fail any request that contains query options that they do not understand and MUST fail any request that contains unsupported OData query options defined in the version of this specification supported by the service.
    
 
    In many cases OData services return URLs to identify resources that are later requested by clients. Where possible, interoperability is enhanced by providing all identifying information in the path portion of the URL. However, clients should be prepared for such URLs to include custom query options and propagate any such custom query options in future requests to the identified resource.
    
 
    6.2 Payload Extensibility
    
@@ -646,7 +646,7 @@ 
    7 Formats
    
 
    In the case that both the Accept header and the $format system query option are specified on a request, the value specified in the $format query option MUST be used.
    
 
    If the service does not support the requested format, it replies with a 406 Not Acceptable error response.
    
 
    Services SHOULD advertise their supported formats in the metadata document by annotating their entity container with the term Capabilities.SupportedFormats, as defined in OData-VocCap, listing all available formats and combinations of supported format parameters.
    
-
    The media types for the JSON and XML representation of the metadata document are described in section "Metadata Document Request".
    
+
    The media types for the JSON and XML representation of the metadata document are described in section “Metadata Document Request”.
    
 
    The format specification OData-JSON describes the media type and the format parameters for non-metadata requests and responses.
    
 
    For non-metadata requests, if neither the Accept header nor the $format query option are specified, the service MAY respond to requests in any format.
    
 
    Client libraries MUST retain the order of objects within an array in JSON responses, and elements in document order for XML responses, including CSDL documents.
    
@@ -657,16 +657,16 @@ 
    8.1 Com
 
    The following headers are common between OData requests and responses.
    
 
    8.1.1 Header Content-Type
    
 
    The format of a non-empty individual request or response body, alone or within a batch, MUST be specified in the Content-Type header of a request or response. The exception to this is if the body represents the media stream of a media entity or stream property, in which case the Content-Type header SHOULD be present.
    
-
    The specified format MAY include format parameters. Clients MUST be prepared for the service to return custom format parameters not defined in OData and SHOULD NOT expect that such format parameters can be ignored. Custom format parameters MUST NOT start with "odata" and services MUST NOT require generic OData consumers to understand custom format parameters in order to correctly interpret the payload.
    
+
    The specified format MAY include format parameters. Clients MUST be prepared for the service to return custom format parameters not defined in OData and SHOULD NOT expect that such format parameters can be ignored. Custom format parameters MUST NOT start with odata and services MUST NOT require generic OData consumers to understand custom format parameters in order to correctly interpret the payload.
    
 
    See OData-JSON for format-specific details about format parameters within the Content-Type header.
    
 
    8.1.2 Header Content-Encoding
    
 
    As defined in RFC7231, the Content-Encoding header field is used as a modifier to the media-type (as indicated in the Content-Type). When present, its value indicates what additional content codings have been applied to the entity-body. A service MAY specify a list of acceptable content codings using an annotation with term Capabilities.AcceptableEncodings, see OData-VocCap.
    
-
    If the Content-Encoding header is specified on an individual request or response within a batch, then it specifies the encoding for that individual request or response. Individual requests or responses that don't include the Content-Encoding header inherit the encoding of the overall batch request or response.
    
+
    If the Content-Encoding header is specified on an individual request or response within a batch, then it specifies the encoding for that individual request or response. Individual requests or responses that don’t include the Content-Encoding header inherit the encoding of the overall batch request or response.
    
 
    8.1.3 Header Content-Language
    
 
    As defined in RFC7231, a request or response can include a Content-Language header to indicate the natural language of the intended audience for the enclosed message body. OData does not add any additional requirements over HTTP for including Content-Language. OData services can annotate model elements whose content depends on the content language with the term Core.IsLanguageDependent, see OData-VocCore.
    
-
    If the Content-Language header is specified on an individual request or response within a batch, then it specifies the language for that individual request or response. Individual requests or responses that don't include the Content-Language header inherit the language of the overall batch request or response.
    
+
    If the Content-Language header is specified on an individual request or response within a batch, then it specifies the language for that individual request or response. Individual requests or responses that don’t include the Content-Language header inherit the language of the overall batch request or response.
    
 
    8.1.4 Header Content-Length
    
-
    As defined in RFC7230, a request or response SHOULD include a Content-Length header when the message's length can be determined prior to being transferred. OData does not add any additional requirements over HTTP for writing Content-Length.
    
+
    As defined in RFC7230, a request or response SHOULD include a Content-Length header when the message’s length can be determined prior to being transferred. OData does not add any additional requirements over HTTP for writing Content-Length.
    
 
    If the Content-Length header is specified on an individual request or response within a batch, then it specifies the length for that individual request or response.
    
 
    8.1.5 Header OData-Version
    
 
    OData clients SHOULD use the OData-Version header on a request to specify the version of the protocol used to generate the request payload.
    
@@ -674,7 +674,7 @@ 
    OData-MaxVersion, if specified, and the maximum version of the protocol that the service understands.
    
 
    OData services MUST include the OData-Version header on a response to specify the version of the protocol used to generate the response payload. The client MUST interpret the response payload according to the rules defined in the specified version of the protocol. Request and response payloads are independent and may have different OData-Version headers according to the above rules.
    
 
    For more details, see Versioning.
    
-
    If the OData-Version header is specified on an individual request or response within a batch, then it specifies the OData version for that individual request or response. Individual requests or responses that don't include the OData-Version header inherit the OData version of the overall batch request or response. This OData version does not typically vary within a batch.
    
+
    If the OData-Version header is specified on an individual request or response within a batch, then it specifies the OData version for that individual request or response. Individual requests or responses that don’t include the OData-Version header inherit the OData version of the overall batch request or response. This OData version does not typically vary within a batch.
    
 
    8.2 Request Headers
    
 
    In addition to the Common Headers, the client may specify any combination of the following request headers.
    
 
    8.2.1 Header Accept
    
@@ -683,13 +683,13 @@ 
    8.2.1 Hea
 
    If a media type specified in the Accept header includes a charset format parameter and the request also contains an Accept-Charset header, then the Accept-Charset header MUST be used.
    
 
    If the media type specified in the Accept header does not include a charset format parameter, then the Content-Type header of the response MUST NOT contain a charset format parameter.
    
 
    The service SHOULD NOT add any format parameters to the Content-Type parameter not specified in the Accept header.
    
-
    If the Accept header is specified on an individual request within a batch, then it specifies the acceptable formats for that individual request. Requests within a batch that don't include the Accept header inherit the acceptable formats of the overall batch request.
    
+
    If the Accept header is specified on an individual request within a batch, then it specifies the acceptable formats for that individual request. Requests within a batch that don’t include the Accept header inherit the acceptable formats of the overall batch request.
    
 
    8.2.2 Header Accept-Charset
    
 
    As defined in RFC7231, the client MAY specify the set of accepted character sets with the Accept-Charset header.
    
-
    If the Accept-Charset header is specified on an individual request within a batch, then it specifies the acceptable character sets for that individual request. Requests within a batch that don't include the Accept-Charset header inherit the acceptable character sets of the overall batch request.
    
+
    If the Accept-Charset header is specified on an individual request within a batch, then it specifies the acceptable character sets for that individual request. Requests within a batch that don’t include the Accept-Charset header inherit the acceptable character sets of the overall batch request.
    
 
    8.2.3 Header Accept-Language
    
 
    As defined in RFC7231, the client MAY specify the set of accepted natural languages with the Accept-Language header.
    
-
    If the Accept-Language header is specified on an individual request within a batch, then it specifies the acceptable languages for that individual request. Requests within a batch that don't include the Accept-Language header inherit the acceptable languages of the overall batch request.
    
+
    If the Accept-Language header is specified on an individual request within a batch, then it specifies the acceptable languages for that individual request. Requests within a batch that don’t include the Accept-Language header inherit the acceptable languages of the overall batch request.
    
 
    8.2.4 Header If-Match
    
 
    As defined in RFC7232, a client MAY include an If-Match header in a request to GET, POST, PUT, PATCH or DELETE. The value of the If-Match request header MUST be an ETag value previously retrieved for the resource, or * to match any value.
    
 
    If an operation on an existing resource requires an ETag, (see term Core.OptimisticConcurrency in OData-VocCore and property OptimisticConcurrencyControl of type Capabilities.NavigationPropertyRestriction in OData-VocCap) and the client does not specify an If-Match request header in a Data Modification Request or in an Action Request invoking an action bound to the resource, the service responds with a 428 Precondition Required and MUST ensure that no observable change occurs as a result of the request.
    
@@ -704,8 +704,8 @@ 
    8.2.6 Header Isolation (OData-Isolation)
    
 
    The Isolation header specifies the isolation of the current request from external changes. The only supported value for this header is snapshot.
    
-
    If the service doesn't support Isolation:snapshot and this header was specified on the request, the service MUST NOT process the request and MUST respond with 412 Precondition Failed.
    
-
    Snapshot isolation guarantees that all data returned for a request, including multiple requests within a batch or results retrieved across multiple pages, will be consistent as of a single point in time. Only data modifications made within the request (for example, by a data modification request within the same batch) are visible. The effect is as if the request generates a "snapshot" of the committed data as it existed at the start of the request.
    
+
    If the service doesn’t support Isolation:snapshot and this header was specified on the request, the service MUST NOT process the request and MUST respond with 412 Precondition Failed.
    
+
    Snapshot isolation guarantees that all data returned for a request, including multiple requests within a batch or results retrieved across multiple pages, will be consistent as of a single point in time. Only data modifications made within the request (for example, by a data modification request within the same batch) are visible. The effect is as if the request generates a “snapshot” of the committed data as it existed at the start of the request.
    
 
    The Isolation header may be specified on a single or batch request. If it is specified on a batch then the value is applied to all statements within the batch.
    
 
    Next links returned within a snapshot return results within the same snapshot as the initial request; the client is not required to repeat the header on each individual page request.
    
 
    The Isolation header has no effect on links other than the next link. Navigation links, read links, and edit links return the current version of the data.
    
@@ -717,7 +717,7 @@ 
    OData-Version less than or equal to the specified OData-MaxVersion.
    
 
    If OData-MaxVersion is not specified, then the service SHOULD return responses with the same OData version over time and interpret the request as having an OData-MaxVersion equal to the maximum OData version supported by the service at its initial publication.
    
-
    If the OData-MaxVersion header is specified on an individual request within a batch, then it specifies the maximum OData version for that individual request. Individual requests that don't include the OData-MaxVersion header inherit the maximum OData version of the overall batch request or response. The maximum OData version does not typically vary within a batch.
    
+
    If the OData-MaxVersion header is specified on an individual request within a batch, then it specifies the maximum OData version for that individual request. Individual requests that don’t include the OData-MaxVersion header inherit the maximum OData version of the overall batch request or response. The maximum OData version does not typically vary within a batch.
    
 
    For more details, see Versioning.
    
 
    8.2.8 Header Prefer
    
 
    The Prefer header, as defined in RFC7240, allows clients to request certain behavior from the service. The service MUST ignore preference values that are either not supported or not known by the service.
    
@@ -726,7 +726,7 @@ 
    8.2.8 Hea
 
    8.2.8.1 Preference allow-entityreferences (odata.allow-entityreferences)
    
 
    The allow-entityreferences preference indicates that the service is allowed to return entity references in place of entities that have previously been returned, with at least the properties requested, in the same response (for example, when serializing the expanded results of many-to-many relationships). The service MUST NOT return entity references in place of requested entities if allow-entityreferences has not been specified in the request, unless explicitly defined by other rules in this document. The syntax of the allow-entityreferences preference is defined in OData-ABNF.
    
 
    In the case the service applies the allow-entityreferences preference it MUST include a Preference-Applied response header containing the allow-entityreferences preference to indicate that entity references MAY be returned in place of entities that have previously been returned.
    
-
    If the allow-entityreferences preference is specified on an individual request within a batch, then it specifies the preference for that individual request. Individual requests within a batch that don't include the allow-entityreferences preference inherit the preference of the overall batch request.
    
+
    If the allow-entityreferences preference is specified on an individual request within a batch, then it specifies the preference for that individual request. Individual requests within a batch that don’t include the allow-entityreferences preference inherit the preference of the overall batch request.
    
 
    Note: The allow-entityreferences preference was named odata.allow-entityreferences in OData version 4.0. Services that support the allow-entityreferences preference SHOULD also support odata.allow-entityreferences for OData 4.0 clients and clients SHOULD use odata.allow-entityreferences for compatibility with OData 4.0 services.
    
 
    8.2.8.2 Preference callback (odata.callback)
    
 
    For scenarios in which links returned by the service are used by the client to poll for additional information, the client can specify the callback preference to request that the service notify the client when data is available.
    
@@ -772,7 +772,7 @@ 
    
-
    Example 5: a Prefer header requesting that all annotations defined under the "display" namespace (recursively) be returned
    
+
    Example 5: a Prefer header requesting that all annotations defined under the display namespace (recursively) be returned
    
 
    Prefer: include-annotations="display.*"
    
 
    • 
 
    
@@ -780,12 +780,12 @@ 
    
-
    Example 7: a Prefer header requesting that all annotations defined under the "display" namespace (recursively) with the qualifier "tablet" be returned
    
+
    Example 7: a Prefer header requesting that all annotations defined under the display namespace (recursively) with the qualifier tablet be returned
    
 
    Prefer: include-annotations="display.*#tablet"
    
 
    
 
    The include-annotations preference is only a hint to the service. The service MAY ignore the preference and is free to decide whether or not to return annotations not specified in the include-annotations preference.
    
 
    In the case that the client has specified the include-annotations preference in the request, the service SHOULD include a Preference-Applied response header containing the include-annotations preference to specify the annotations actually included, where applicable, in the response. This value may differ from the annotations requested in the Prefer header of the request.
    
-
    If the include-annotations preference is specified on an individual request within a batch, then it specifies the preference for that individual request. Individual requests within a batch that don't include the include-annotations preference inherit the preference of the overall batch request.
    
+
    If the include-annotations preference is specified on an individual request within a batch, then it specifies the preference for that individual request. Individual requests within a batch that don’t include the include-annotations preference inherit the preference of the overall batch request.
    
 
    Note: The include-annotations preference was named odata.include-annotations in OData version 4.0. Services that support theinclude-annotationspreference SHOULD also support odata.include-annotations for OData 4.0 clients and clients SHOULD use odata.include-annotations for compatibility with OData 4.0 services. If both include-annotations and odata.include-annotations preferences are specified in the same request, the value of the include-annotations preference SHOULD be used.
    
 
    8.2.8.5 Preference maxpagesize (odata.maxpagesize)
    
 
    The maxpagesize preference is used to request that each collection within the response contain no more than the number of items specified as the positive integer value of this preference. The syntax of the maxpagesize preference is defined in OData-ABNF.
    
@@ -886,7 +886,7 @@ 
    Data Service Request has been accepted and has not yet completed executing asynchronously. The asynchronous handling of requests is defined in the sections on Asynchronous Requests and Asynchronous Batch Requests.
    
 
    9.1.4 Response Code 204 No Content
    
 
    A request returns 204 No Content if the requested resource has the null value, or if the service applies a return=minimal preference. In this case, the response body MUST be empty.
    
-
    As defined in RFC7231, a Data Modification Request that responds with 204 No Content MAY include an ETag header with a value reflecting the result of the data modification if and only if the client can reasonably "know" the new representation of the resource without actually receiving it. For a PUT request this means that the response body of a corresponding 200 OK or 201 Created response would have been identical to the request body, i.e. no server-side modification of values sent in the request body, no server-calculated values etc. For a PATCH request this means that the response body of a corresponding 200 OK or 201 Created response would have consisted of all values sent in the request body, plus (for values not sent in the request body) server-side values corresponding to the ETag value sent in the If-Match header of the PATCH request, i.e. the previous values "known" to the client.
    
+
    As defined in RFC7231, a Data Modification Request that responds with 204 No Content MAY include an ETag header with a value reflecting the result of the data modification if and only if the client can reasonably “know” the new representation of the resource without actually receiving it. For a PUT request this means that the response body of a corresponding 200 OK or 201 Created response would have been identical to the request body, i.e. no server-side modification of values sent in the request body, no server-calculated values etc. For a PATCH request this means that the response body of a corresponding 200 OK or 201 Created response would have consisted of all values sent in the request body, plus (for values not sent in the request body) server-side values corresponding to the ETag value sent in the If-Match header of the PATCH request, i.e. the previous values “known” to the client.
    
 
    9.1.5 Response Code 3xx Redirection
    
 
    As per RFC7231, a 3xx Redirection indicates that further action needs to be taken by the client in order to fulfill the request. In this case, the response SHOULD include a Location header, as appropriate, with the URL from which the result can be obtained; it MAY include a Retry-After header.
    
 
    9.1.6 Response Code 304 Not Modified
    
@@ -927,7 +927,7 @@ 
    9.5
 
    Services MAY include the header OData-Error as a trailing header if supported by the transport protocol (e.g. HTTP/1.1 with chunked transfer encoding, or HTTP/2).
    
 
    
 
    10 Context URL
    
-
    The context URL describes the content of the payload. It consists of the canonical metadata document URL and a fragment identifying the relevant portion of the metadata document. The context URL makes response payloads "self-contained", allowing a recipient to retrieve metadata, resolve references, and construct canonical links omitted from response payloads in certain optimized formats.
    
+
    The context URL describes the content of the payload. It consists of the canonical metadata document URL and a fragment identifying the relevant portion of the metadata document. The context URL makes response payloads “self-contained”, allowing a recipient to retrieve metadata, resolve references, and construct canonical links omitted from response payloads in certain optimized formats.
    
 
    Request payloads generally do not require context URLs as the type of the payload can generally be determined from the request URL.
    
 
    For details on how the context URL is used to describe a payload, see the relevant sections in the particular format.
    
 
    The following subsections describe how the context URL is constructed for each category of payload by providing a context URL template. The context URL template uses the following terms:
    
@@ -1052,17 +1052,17 @@ 
    
-
    Example 20: resource URL and corresponding context URL - select and expand
    
+
    Example 20: resource URL and corresponding context URL — select and expand
    
 
    http://host/service/Customers?$select=Name&$expand=Address/Country
 http://host/service/$metadata#Customers(Name,Address/Country())
    
 
    
 
    
-
    Example 21: resource URL and corresponding context URL -- expand $ref
    
+
    Example 21: resource URL and corresponding context URL — expand $ref
    
 
    http://host/service/Customers?$expand=Orders/$ref
 http://host/service/$metadata#Customers
    
 
    
 
    
-
    Example 22: resource URL and corresponding context URL -- expand with $levels
    
+
    Example 22: resource URL and corresponding context URL — expand with $levels
    
 
    http://host/service/Employees/Sales.Manager?$select=DirectReports
         &$expand=DirectReports($select=FirstName,LastName;$levels=4)
 http://host/service/$metadata
@@ -1238,7 +1238,7 @@ 
    server-driven paging:
    
 
      
-
    • $apply -- defined in OData-Aggregation
      • 
+
    • $apply — defined in OData-Aggregation
      • 
 
    • $compute
      • 
 
    • $search
      • 
 
    • $filter
      • 
@@ -1255,7 +1255,7 @@ 
      11.2.2 Requesting Individual Entities
      
 
      To retrieve an individual entity, the client makes a GET request to a URL that identifies the entity, e.g. its read URL.
      
-
      The read URL can be obtained from a response payload containing that instance, for example as a readLink or editLink in an OData-JSON payload. In addition, services MAY support conventions for constructing a read URL using the entity's key value(s), as described in OData-URL.
      
+
      The read URL can be obtained from a response payload containing that instance, for example as a readLink or editLink in an OData-JSON payload. In addition, services MAY support conventions for constructing a read URL using the entity’s key value(s), as described in OData-URL.
      
 
      The set of structural or navigation properties to return may be specified through $select or $expandsystem query options.
      
 
      Clients MUST be prepared to receive additional properties in an entity or complex type instance that are not advertised in metadata, even for types not marked as open.
      
 
      Properties that are not available, for example due to permissions, are not returned. In this case, the Core.Permissions annotation, defined in OData-VocCore MUST be returned for the property with a value of None.
      
@@ -1267,7 +1267,7 @@ 
      Appending /$value to an entity that is not a media entity returns 400 Bad Request.
      
 
      Attempting to retrieve the media stream from a single-valued navigation property referencing a media entity whose value is null returns 404 Not Found.
      
 
      11.2.4 Requesting Individual Properties
      
-
      To retrieve an individual property, the client issues a GET request to the property URL. The property URL is the entity read URL with "/" and the property name appended.
      
+
      To retrieve an individual property, the client issues a GET request to the property URL. The property URL is the entity read URL with / and the property name appended.
      
 
      For complex typed properties, the path can be further extended with the name of an individual property of the complex type.
      
 
      See OData-URL for details.
      
 
      If the property is single-valued and has the null value, the service responds with 204 No Content.
      
@@ -1279,7 +1279,7 @@ 
      11.2.4.1 Requesting Stream Properties
      
 
      If the property being requested has type Edm.Stream (see OData-URL, section 9), the media type of the response is the media type of the stream, subject to content type negotiation based on the Accept header of the request. The response body is the octet-stream that represents the raw value of the stream property with that media type.
      
 
      Note this response format disregards any $format system query option.
      
-
      11.2.4.2 Requesting a Property's Raw Value using $value
      
+
      11.2.4.2 Requesting a Property’s Raw Value using $value
      
 
      To retrieve the raw value of a primitive type property, the client sends a GET request to the property value URL. See the OData-URL document for details.
      
 
      The Content-Type of the response is determined using the Accept header and the $format system query option.
      
 
      The default format for Edm.Binary is the format specified by the Core.MediaType annotation of this property (see OData-VocCore) if this annotation is present. If not annotated, the format cannot be predicted by the client.
      
@@ -1483,7 +1483,7 @@ 
      function parameters, or within a $compute, $filter or $orderby expression. Parameters aliases are names beginning with an at sign (@).
      
 
      Actual parameter values are specified as query options in the query part of the request URL. The query option name is the name of the parameter alias, and the query option value is the value to be used for the specified parameter alias.
      
 
      
-
      Example 48: returns all employees whose Region property matches the string parameter value "WA"
      
+
      Example 48: returns all employees whose Region property matches the string parameter value WA
      
 
      GET http://host/service.svc/Employees?$filter=Region eq @p1&@p1='WA'
      
 
      
 
      Parameter aliases allow the same value to be used multiple times in a request and may be used to reference primitive, structured, or collection values.
      
@@ -1554,32 +1554,32 @@ 
      11.2.6.6 System Query Option $search
      
 
      The $search system query option restricts the result to include only those items matching the specified search expression. The definition of what it means to match is dependent upon the implementation.
      
 
      
-
      Example 58: return all Products that match the search term "bike"
      
+
      Example 58: return all Products that match the search term bike
      
 
      GET http://host/service/Products?$search=bike
      
 
      
 
      The search expression can contain phrases, enclosed in double-quotes.
      
 
      
-
      Example 59: return all Products that match the phrase "mountain bike"
      
+
      Example 59: return all Products that match the phrase mountain bike
      
 
      GET http://host/service/Products?$search="mountain bike"
      
 
      
 
      The upper-case keyword NOT restricts the set of entities to those that do not match the specified term.
      
 
      
-
      Example 60: return all Products that do not match "clothing"
      
+
      Example 60: return all Products that do not match clothing
      
 
      GET http://host/service/Products?$search=NOT clothing
      
 
      
 
      Multiple terms within a search expression are separated by a space (implicit AND) or the upper-case keyword AND, indicating that all such terms must be matched.
      
 
      
-
      Example 61: return all Products that match both "mountain" and "bike"
      
+
      Example 61: return all Products that match both mountain and bike
      
 
      GET http://host/service/Products?$search=mountain AND bike
      
 
      
 
      The upper-case keyword OR is used to return entities that satisfy either the immediately preceding or subsequent expression.
      
 
      
-
      Example 62: return all Products that match either "mountain" or "bike"
      
+
      Example 62: return all Products that match mountain or bike
      
 
      GET http://host/service/Products?$search=mountain OR bike
      
 
      
 
      Parentheses within the search expression group together multiple expressions.
      
 
      
-
      Example 63: return all Products that match either "mountain" or "bike" and do not match clothing
      
+
      Example 63: return all Products that match mountain or bike and do not match clothing
      
 
      GET http://host/service/Products?$search=(mountain OR bike) AND NOT clothing
      
 
      
 
      The operations within a search expression MUST be evaluated in the following order: grouping operator, NOT operator, AND operator, OR operator
      
@@ -1598,7 +1598,7 @@ 
      GET http://host/service/Suppliers(MainSupplier)/Addresses/0
    
 
    
 
-
    To request related entities according to a particular relationship, the client issues a GET request to the source entity's request URL, followed by a forward slash and the name of the navigation property representing the relationship.
    
+
    To request related entities according to a particular relationship, the client issues a GET request to the source entity’s request URL, followed by a forward slash and the name of the navigation property representing the relationship.
    
 
    If the navigation property does not exist on the entity indicated by the request URL, the service returns 404 Not Found.
    
 
    If the relationship terminates on a collection, the response MUST be the format-specific representation of the collection of related entities. If no entities are related, the response is the format-specific representation of an empty collection.
    
 
    If the relationship terminates on a single entity, the response MUST be the format-specific representation of the related single entity. If no entity is related, the service returns 204 No Content.
    
@@ -1679,9 +1679,9 @@ 
    Core.SchemaVersion annotation, defined in OData-VocCore, of a previous request to the metadata document, or * in order to specify the current version of the metadata.
    
 
    If specified, the service MUST process the request according to the specified version of the metadata.
    
 
    Clients can retrieve the current version of the metadata by making a metadata document request with a $schemaversion system query option value of *, and SHOULD include the value from the returned Core.SchemaVersion annotation in the $schemaversion system query option of subsequent requests.
    
-
    If the $schemaversion system query option is not specified in a request for the metadata document, the service MUST return a version of the metadata with no breaking changes over time, and the processing of all other requests that omit the $schemaversion system query option MUST be compatible with that "unversioned" schema. For more information on breaking changes, see Model Versioning.
    
-
    If the $schemaversion system query option is specified on an individual request within a batch, then it specifies the version of the schema to apply to that individual request. Individual requests within a batch that don't include the $schemaversion system query option inherit the schema version of the overall batch request.
    
-
    If the $schemaversion system query option is specified, but the version of the schema doesn't exist, the request is answered with a response code 404 Not Found. The response body SHOULD provide additional information.
    
+
    If the $schemaversion system query option is not specified in a request for the metadata document, the service MUST return a version of the metadata with no breaking changes over time, and the processing of all other requests that omit the $schemaversion system query option MUST be compatible with that “unversioned” schema. For more information on breaking changes, see Model Versioning.
    
+
    If the $schemaversion system query option is specified on an individual request within a batch, then it specifies the version of the schema to apply to that individual request. Individual requests within a batch that don’t include the $schemaversion system query option inherit the schema version of the overall batch request.
    
+
    If the $schemaversion system query option is specified, but the version of the schema doesn’t exist, the request is answered with a response code 404 Not Found. The response body SHOULD provide additional information.
    
 
    11.3 Requesting Changes
    
 
    Services advertise their change-tracking capabilities by annotating entity sets with the Capabilities.ChangeTracking term defined in OData-VocCap.
    
 
    Any GET request to retrieve one or more entities MAY allow change-tracking.
    
@@ -1738,7 +1738,7 @@ 
    Preference-Applied header if it does not return a representation.
    
 
    If one or more of these query options are present and the service returns a representation, then the service MUST apply the specified query options. If it cannot apply the specified query options appropriately, it MUST NOT fail the request solely due to the presence of these query options and instead MUST return 204 No Content.
    
 
    11.4.2 Create an Entity
    
-
    To create an entity in a collection, the client sends a POST request to that collection's URL. The POST body MUST contain a single valid entity representation.
    
+
    To create an entity in a collection, the client sends a POST request to that collection’s URL. The POST body MUST contain a single valid entity representation.
    
 
    The entity representation MAY include references to existing entities as well as content for new related entities, but MUST NOT contain content for existing related entities. The result of the operation is the entity with relationships to all included references to existing entities as well as all related entities created inline. If the key properties for an entity include key properties of a directly related entity, those related entities MUST be included either as references to existing entities or as content for new related entities.
    
 
    An entity may also be created as the result of an Upsert operation.
    
 
    If the target URL for the collection is a navigation link, the new entity is automatically linked to the entity containing the navigation link.
    
@@ -1784,17 +1784,17 @@ 
-
    A request to create an entity that includes related entities, represented using the appropriate inline representation, is referred to as a "deep insert".
    
+
    A request to create an entity that includes related entities, represented using the appropriate inline representation, is referred to as a “deep insert”.
    
 
    Media entities MUST contain the base64url-encoded representation of their media stream as a virtual property $value when nested within a deep insert.
    
 
    Each included related entity is processed observing the rules for creating an entity as if it was posted against the original target URL extended with the navigation path to this related entity.
    
 
    On success, the service MUST create all entities and relate them. If the service responds with 201 Created, the response MUST be expanded to at least the level that was present in the deep-insert request.
    
-
    Clients MAY associate an id with individual nested entities in the request by applying the Core.ContentID term using the namespace or alias defined for the OData-VocCore vocabulary in the service's $metadata document. Services that respond with 201 Created SHOULD annotate the entities in the response using the same Core.ContentID value as specified in the request. Services SHOULD advertise support for deep inserts, including support for returning the Core.ContentID, through the Capabilities.DeepInsertSupport term, defined in OData-VocCap; services that advertise support through Capabilities.DeepInsertSupport MUST return the Core.ContentID for the inserted or updated entities.
    
+
    Clients MAY associate an id with individual nested entities in the request by applying the Core.ContentID term using the namespace or alias defined for the OData-VocCore vocabulary in the service’s $metadata document. Services that respond with 201 Created SHOULD annotate the entities in the response using the same Core.ContentID value as specified in the request. Services SHOULD advertise support for deep inserts, including support for returning the Core.ContentID, through the Capabilities.DeepInsertSupport term, defined in OData-VocCap; services that advertise support through Capabilities.DeepInsertSupport MUST return the Core.ContentID for the inserted or updated entities.
    
 
    The continue-on-error preference is not supported for deep insert operations.
    
 
    On failure, the service MUST NOT create any of the entities.
    
 
    11.4.3 Update an Entity
    
 
    To update an individual entity, the client makes a PATCH or PUT request to a URL that identifies the entity. Services MAY restrict updates only to requests addressing the edit URL of the entity.
    
 
    Services SHOULD support PATCH as the preferred means of updating an entity. PATCH provides more resiliency between clients and services by directly modifying only those values specified by the client.
    
-
    The semantics of PATCH, as defined in RFC5789, is to merge the content in the request payload with the entity's current state, applying the update only to those components specified in the request body. Collection properties and primitive properties provided in the payload corresponding to updatable properties MUST replace the value of the corresponding property in the entity or complex type. Complex properties are updated by applying PATCH semantics recursively, see also section 11.4.9.3. Missing properties of the containing entity or complex property, including dynamic properties, MUST NOT be directly altered unless as a side effect of changes resulting from the provided properties.
    
+
    The semantics of PATCH, as defined in RFC5789, is to merge the content in the request payload with the entity’s current state, applying the update only to those components specified in the request body. Collection properties and primitive properties provided in the payload corresponding to updatable properties MUST replace the value of the corresponding property in the entity or complex type. Complex properties are updated by applying PATCH semantics recursively, see also section 11.4.9.3. Missing properties of the containing entity or complex property, including dynamic properties, MUST NOT be directly altered unless as a side effect of changes resulting from the provided properties.
    
 
    Services MAY additionally support PUT but should be aware of the potential for data-loss in round-tripping properties that the client may not know about in advance, such as open or added properties, or properties not specified in metadata. Services that support PUT MUST replace all values of structural properties with those specified in the request body. Missing non-key, updatable structural properties not defined as dependent properties within a referential constraint MUST be set to their default values. Omitting a non-nullable property with no service-generated or default value from a PUT request results in a 400 Bad Request error. Missing dynamic structural properties MUST be removed or set to null.
    
 
    For requests with an OData-Version header with a value of 4.01 or greater, the media stream of a media entity can be updated by specifying the base64url-encoded representation of the media stream as a virtual property $value.
    
 
    Updating a dependent property that is tied to a key property of the principal entity through a referential constraint updates the relationship to point to the entity with the specified key value. If there is no such entity, the update fails.
    
@@ -1808,7 +1808,7 @@ 
    1
 
    Upon successful completion the service responds with either 200 OK and a representation of the updated entity, or 204 No Content. The client may request that the response SHOULD include a body by specifying a Prefer header with a value of return=representation, or by specifying the system query options $select or $expand. If the service uses ETags for optimistic concurrency control, the entities in the response MUST include ETags.
    
 
    
 
    Update requests with an OData-Version header with a value of 4.0 MUST NOT contain related entities as inline content. Such requests MAY contain binding information for navigation properties. For single-valued navigation properties this replaces the relationship. For collection-valued navigation properties this adds to the relationship.
    
-
    Payloads with an OData-Version header with a value of 4.01 or greater MAY include nested entities and entity references that specify the full set of to be related entities, or a nested delta payload representing the related entities that have been added, removed, or changed. Such a request is referred to as a "deep update". If the nested collection is represented identical to an expanded navigation property, then the set of nested entities and entity references specified in a successful update request represents the full set of entities to be related according to that relationship and MUST NOT include added links, deleted links, or deleted entities.
    
+
    Payloads with an OData-Version header with a value of 4.01 or greater MAY include nested entities and entity references that specify the full set of to be related entities, or a nested delta payload representing the related entities that have been added, removed, or changed. Such a request is referred to as a “deep update”. If the nested collection is represented identical to an expanded navigation property, then the set of nested entities and entity references specified in a successful update request represents the full set of entities to be related according to that relationship and MUST NOT include added links, deleted links, or deleted entities.
    
 
    
 
    Example 78: using the JSON format, a 4.01 PATCH request can update a manager entity. Following the update, the manager has three direct reports; two existing employees and one new employee named Suzanne Brown. The LastName of employee 6 is updated to Smith.
    
 
    {
@@ -1838,7 +1838,7 @@ 
    
 
 
 
 
    Added section about fundamentals of input and output sets
     Algorithmic descriptions of transformations
     Added join and outerjoin transformations, replaced expand by addnested
     Added transformations orderby, skip, top, nest
     Added transformations for recursive hierarchies, updated related filter functions
     Added functions evaluable on a collection, introduced keyword $these
     Merged section 4 “Representation of Aggregated Instances” into section 3
     Remove actions and functions (except set transformations) on aggregated entities, adapted section “Actions and Functions on Aggregated Entities”    		
 
    
 
    
 Committee Specification 03