From c7b586edb13797f573e2c312fa9ef77e5434574b Mon Sep 17 00:00:00 2001
From: D024504 The The The first argument MUST be of type RFC6570 defines three kinds of template parameters: simple values, lists of values, and key-value maps. Simple values are represented as labeled element expressions that evaluate to a single primitive value. The literal representation of this value according to OData-ABNF is used to fill the corresponding template parameter. The It MAY contain The The The The The The first argument MUST be of type RFC6570 defines three kinds of template parameters: simple values, lists of values, and key-value maps. Simple values are represented as labeled element expressions that evaluate to a single primitive value. The literal representation of this value according to OData-ABNF is used to fill the corresponding template parameter. Requests and responses with a JSON message body MUST have a Requests MAY add the Requests MAY add the Responses MUST include the Requests and responses MUST include the Requests and responses MAY add the In OData 4.01 payloads the deleted-entity object MUST include the following properties, regardless of the specified Control information Control information Control information For full metadata the 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. Parameter aliases can be used in place of literal values in entity keys, function parameters, or within a Parameter aliases can be used in place of literal values in entity keys, function parameters, or within a 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" is equivalent to a request with the In metadata document requests, the values In metadata document requests, the values The The value of the 14.4.4.2 Function
-odata.fillUriTemplate
odata.fillUriTemplate
client-side function takes two or more expressions as arguments and returns a value of type Edm.String.
odata.fillUriTemplate
client-side function takes two or more expressions as arguments and returns a value of type Edm.String
.Edm.String
and specifies a URI template according to RFC6570, the other arguments MUST be labeled element expressions. Each labeled element expression specifies the template parameter name as its name and evaluates to the template parameter value.
edmx:Edmx
element is the root element of a CSDL XML document. It MUST contain the Version
attribute and it MUST contain exactly one edmx:DataServices
element.edmx:Reference
elements to reference other CSDL documents. Attribute
-Version
Version
attribute specifies the OData protocol version of the service. For OData 4.0 responses the value of this attribute MUST be 4.0.
For OData 4.01 responses the value of this attribute MUST be 4.01.
Services MUST return an OData 4.0 response if the request was made with an OData-MaxVersion
header with a value of 4.0
.Version
attribute specifies the OData protocol version of the service. For OData 4.0 responses the value of this attribute MUST be 4.0
. For OData 4.01 responses the value of this attribute MUST be 4.01
. Services MUST return an OData 4.0 response if the request was made with an OData-MaxVersion
header with a value of 4.0
. Element
edmx:DataServices
edmx:DataServices
element MUST contain one or more edm:Schema
elements which define the schemas exposed by the OData service.14.4.4.2 Function
-odata.fillUriTemplate
odata.fillUriTemplate
client-side function takes two or more expressions as arguments and returns a value of type Edm.String.
odata.fillUriTemplate
client-side function takes two or more expressions as arguments and returns a value of type Edm.String
.Edm.String
and specifies a URI template according to RFC6570, the other arguments MUST be labeled element expressions. Each labeled element expression specifies the template parameter name as its name and evaluates to the template parameter value.4.1 Header Content-Type
Content-Type
header value of application/json
.charset
parameter to the content type. Allowed values are UTF-8
, UTF-16
, and UTF-32
. If no charset
parameter is present, UTF-8
MUST be assumed.charset
parameter to the content type. Allowed values are UTF-8
, UTF-16
, and UTF-32
. If no charset
parameter is present, UTF-8
MUST be assumed.metadata
parameter to specify the amount of metadata included in the response.IEEE754Compatible
parameter if Edm.Int64
and Edm.Decimal
numbers are represented as strings.streaming
parameter with a value of true
or false
, see section "Payload Ordering Constraints".15.3 D
metadata
value:
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.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
.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
.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.11.2.6.1.3 Parameter Aliases
-$compute
,
$filter
or $orderby
expression. Parameters aliases are names beginning with an at sign (@
).$compute
, $filter
or $orderby
expression. Parameters aliases are names beginning with an at sign (@
).GET http://host/service/Orders?$format=json
Accept
header set to application/json
; it requests the set of Order entities represented using the JSON media type with minimal metadata, as defined in OData-JSON.application/xml
and application/json
, along with their subtypes and parameterized variants, as well as the format-specific abbreviations xml
and json,
are reserved for this specification.application/xml
and application/json
, along with their subtypes and parameterized variants, as well as the format-specific abbreviations xml
and json
, are reserved for this specification.11.2.12 System Query Option
$schemaversion
$schemaversion
system query option MAY be included in any request. For a metadata document request the value of the $schemaversion
system query option addresses a specific schema version. For all other request types the value specifies the version of the schema against which the request is made. The syntax of the $schemaversion
system query option is defined in OData-ABNF.$schemaversion
system query option MUST be a version of the schema as returned in the 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.404 Not Found
. The response body SHOULD provide additional information.
Services advertise their change-tracking capabilities by annotating entity sets with the Capabilities
.ChangeTracking
term defined in OData-VocCap.
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.
Clients request that the service track changes to a result by specifying the track-changes
preference on a request. If supported for the request, the service includes a Preference-Applied
header in the response containing the track-changes
preference and includes a delta link in a result for a single entity, and on the last page of results for a collection of entities in place of the next link.
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.
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
.
{
"@type":"#Northwind.Manager",
"FirstName" : "Patricia",
"DirectReports": [
{
- "@id": "Employees(5}"
+ "@id": "Employees(5)"
},
{
- "@id": "Employees(6}",
+ "@id": "Employees(6)",
"LastName": "Smith"
},
{
@@ -2440,7 +2440,7 @@ continue-on-error
preference is specified with an explicit or implicit value of true
.
All requests in a change set represent a single change unit so a service MUST successfully process and apply all the requests in the change set or else apply none of them. It is up to the service implementation to define rollback semantics to undo any requests within a change set that may have been applied before another request in that same change set failed and thereby apply this all-or-nothing requirement. The service MAY execute the requests within a change set in any order and MAY return the responses to the individual requests in any order. If a request specifies a request identifier, the service MUST include the Content-ID
header with the request identifier in the corresponding response so clients can correlate requests and responses.
11.7.7.5 Multipart Batch Response
-A multipart response to a batch request MUST contain a Content-Type
header with value multipart/mixed.
+A multipart response to a batch request MUST contain a Content-Type
header with value multipart/mixed
.
The body of a multipart response to a multipart batch request MUST structurally match one-to-one with the multipart batch request body, such that the same multipart message structure defined for requests is used for responses. There are three exceptions to this rule:
- When a request within a change set fails, the change set response is not represented using the
multipart/mixed
media type. Instead, a single response, using the application/http
media type, is returned that applies to all requests in the change set and MUST be a valid OData error response.
diff --git a/docs/odata-protocol/odata-protocol.md b/docs/odata-protocol/odata-protocol.md
index e19e97d36..bc321407a 100644
--- a/docs/odata-protocol/odata-protocol.md
+++ b/docs/odata-protocol/odata-protocol.md
@@ -3212,7 +3212,7 @@ a `null` literal that can be used in comparisons.
Parameter aliases can be used in place of literal values in entity keys,
[function parameters](#InvokingaFunction), or within a
-[`$compute`](#SystemQueryOptioncompute)`,`
+[`$compute`](#SystemQueryOptioncompute),
[`$filter`](#SystemQueryOptionfilter) or
[`$orderby`](#SystemQueryOptionorderby) expression. Parameters aliases
are names beginning with an at sign (`@`).
@@ -3757,7 +3757,7 @@ using the JSON media type with minimal metadata, as defined in
In [metadata document requests](#MetadataDocumentRequest), the values
`application/xml` and `application/json`, along with their subtypes and
parameterized variants, as well as the format-specific abbreviations
-`xml` and `json,` are reserved for this specification.
+`xml` and `json`, are reserved for this specification.
### 11.2.12 System Query Option `$schemaversion`
@@ -3809,7 +3809,7 @@ body SHOULD provide additional information.
Services advertise their change-tracking capabilities by annotating
entity sets with the
-[`Capabilities`.`ChangeTracking`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Capabilities.V1.md#ChangeTracking)
+[`Capabilities.ChangeTracking`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Capabilities.V1.md#ChangeTracking)
term defined in [OData-VocCap](#ODataVocCap).
Any `GET` request to retrieve one or more entities MAY allow
@@ -4372,17 +4372,17 @@ 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.`
+`Suzanne Brown`. The `LastName` of employee 6 is updated to `Smith`.
```json
{
"@type":"#Northwind.Manager",
"FirstName" : "Patricia",
"DirectReports": [
{
- "@id": "Employees(5}"
+ "@id": "Employees(5)"
},
{
- "@id": "Employees(6}",
+ "@id": "Employees(6)",
"LastName": "Smith"
},
{
@@ -6057,7 +6057,7 @@ response so clients can correlate requests and responses.
#### 11.7.7.5 Multipart Batch Response
A multipart response to a batch request MUST contain a `Content-Type`
-header with value `multipart/mixed.`
+header with value `multipart/mixed`.
The body of a multipart response to a multipart batch request MUST
structurally match one-to-one with the multipart batch request body,
diff --git a/docs/odata-url-conventions/odata-url-conventions.html b/docs/odata-url-conventions/odata-url-conventions.html
index bc10c47c6..f38c5e9b7 100644
--- a/docs/odata-url-conventions/odata-url-conventions.html
+++ b/docs/odata-url-conventions/odata-url-conventions.html
@@ -1725,9 +1725,9 @@