diff --git a/.github/workflows/pdf.yml b/.github/workflows/pdf.yml index 65dddd807..42054800b 100644 --- a/.github/workflows/pdf.yml +++ b/.github/workflows/pdf.yml @@ -9,7 +9,7 @@ jobs: strategy: matrix: - node-version: [18.x] + node-version: [20.x] steps: - uses: actions/checkout@v3 diff --git a/.vscode/settings.json b/.vscode/settings.json index 84e8e54ef..8ff1b738e 100644 --- a/.vscode/settings.json +++ b/.vscode/settings.json @@ -4,6 +4,7 @@ "asec", "CSDL", "ETag", + "matchespattern", "odata", "pandoc", "subasec", diff --git a/docs/odata-csdl-json/odata-csdl-json.html b/docs/odata-csdl-json/odata-csdl-json.html index b73cb87a6..a7b177eda 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

@@ -191,9 +191,17 @@

Table of Contents

  • 3.1 Nominal Types
  • 3.2 Structured Types
  • 3.3 Primitive Types
  • -
  • 3.4 Built-In Abstract Types
  • -
  • 3.5 Built-In Types for defining Vocabulary Terms
  • -
  • 3.6 Annotations
  • +
  • 3.4 Type Facets +
  • +
  • 3.5 Built-In Abstract Types
  • +
  • 3.6 Built-In Types for defining Vocabulary Terms
  • +
  • 3.7 Annotations
  • 4 CSDL JSON Document
  • 4 CSDL XML Document

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

    15.3 Qualified Name

    @@ -3069,7 +3082,7 @@

    </edmx:Reference> <edmx:DataServices> <Schema Namespace="ODataDemo"> - <EntityType Name="Product" HasStream="true"> + <EntityType Name="Product"> <Key> <PropertyRef Name="ID" /> </Key> @@ -3240,43 +3253,43 @@

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

    +

    Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, “URI Template”, RFC 6570, DOI 10.17487/RFC6570, March 2012.
    +https://www.rfc-editor.org/info/rfc6570.

    [RFC8174]
    -

    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.

    +

    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.

    [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.
    http://www.w3.org/TR/2006/REC-xml11-20060816. Latest version available at http://www.w3.org/TR/xml11/.

    @@ -3291,245 +3304,249 @@
    [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


    @@ -3641,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 9b70b1e11..be85d2dfc 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). @@ -111,9 +111,15 @@ For complete copyright information please see the full Notices section in an App - [3.1 Nominal Types](#NominalTypes) - [3.2 Structured Types](#StructuredTypes) - [3.3 Primitive Types](#PrimitiveTypes) - - [3.4 Built-In Abstract Types](#BuiltInAbstractTypes) - - [3.5 Built-In Types for defining Vocabulary Terms](#BuiltInTypesfordefiningVocabularyTerms) - - [3.6 Annotations](#Annotations) + - [3.4 Type Facets](#TypeFacets) + - [3.4.1 MaxLength](#MaxLength) + - [3.4.2 Precision](#Precision) + - [3.4.3 Scale](#Scale) + - [3.4.4 Unicode](#Unicode) + - [3.4.5 SRID](#SRID) + - [3.5 Built-In Abstract Types](#BuiltInAbstractTypes) + - [3.6 Built-In Types for defining Vocabulary Terms](#BuiltInTypesfordefiningVocabularyTerms) + - [3.7 Annotations](#Annotations) - [4 CSDL XML Document](#CSDLXMLDocument) - [4.1 Reference](#Reference) - [4.2 Included Schema](#IncludedSchema) @@ -129,14 +135,8 @@ For complete copyright information please see the full Notices section in an App - [6.5 Key](#Key) - [7 Structural Property](#StructuralProperty) - [7.1 Type](#Type) - - [7.2 Type Facets](#TypeFacets) - - [7.2.1 Nullable](#Nullable) - - [7.2.2 MaxLength](#MaxLength) - - [7.2.3 Precision](#Precision) - - [7.2.4 Scale](#Scale) - - [7.2.5 Unicode](#Unicode) - - [7.2.6 SRID](#SRID) - - [7.2.7 Default Value](#DefaultValue) + - [7.2 Nullable](#Nullable) + - [7.3 Default Value](#DefaultValue) - [8 Navigation Property](#NavigationProperty) - [8.1 Navigation Property Type](#NavigationPropertyType) - [8.2 Nullable Navigation Property](#NullableNavigationProperty) @@ -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 @@ -558,7 +558,207 @@ representation of primitive type values in URLs and [OData-JSON](#ODataJSON) for the representation in requests and responses. -## 3.4 Built-In Abstract Types +## 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](#StructuralProperty), +action or function [parameter](#Parameter), action or function [return type](#ReturnType), or [term](#Term). + +For single-valued model elements the facets apply to the value of the +model element. For collection-valued model elements the facets apply to the items +in the collection. + +### 3.4.1 MaxLength + +A positive integer value specifying the maximum length of a binary, +stream or string value. For binary or stream values this is the octet +length of the binary data, for string values it is the character length +(number of code points for Unicode). + +If no maximum length is specified, clients SHOULD expect arbitrary +length. + + +::: {.varxml .rep} +### Type Facet Attributes +### Attribute `MaxLength` + +The value of `MaxLength` is a positive integer or the symbolic value +`max` as a shorthand for the maximum length supported for the type by +the service. + +Note: the symbolic value `max` is only allowed in OData 4.0 responses; +it is deprecated in OData 4.01. While clients MUST be prepared for this +symbolic value, OData 4.01 and greater services MUST NOT return the +symbolic value `max` and MAY instead specify the concrete maximum length +supported for the type by the service or omit the attribute 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 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`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Measures.V1.md#DurationGranularity), +see [OData-VocMeasures](#ODataVocMeasures). + + + +::: {.varxml .rep} +### Attribute `Precision` + +The value of `Precision` is a number. + +If not specified for a decimal value, the decimal value has +unspecified precision. + +If not specified for a temporal value, the temporal value has a +precision of zero. +::: + +::: {.varxml .example} +Example 2: [`Precision`](#Precision) facet applied to the +`DateTimeOffset` type +```xml + +``` +::: + +### 3.4.3 Scale + +A non-negative integer value specifying the maximum number of digits +allowed to the right of the decimal point, or one of the symbolic values +`floating` or `variable`. + +The value `floating` means that the decimal value represents a +decimal floating-point number whose number of significant digits is the +value of the [`Precision`](#Precision) facet. OData 4.0 responses MUST +NOT specify the value `floating`. + +The value `variable` means that the number of digits to the right of the +decimal point can vary from zero to the value of the +[`Precision`](#Precision) facet. + +An integer value means that the number of digits to the right of the +decimal point may vary from zero to the value of the `Scale` facet, and +the number of digits to the left of the decimal point may vary from one +to the value of the `Precision` facet minus the value of the `Scale` +facet. If `Precision` is equal to `Scale`, a single zero MUST precede +the decimal point. + +The value of `Scale` MUST be less than or equal to the value of +[`Precision`](#Precision). + +Note: if the underlying data store allows negative scale, services may +use a [`Precision`](#Precision) with the absolute value of the negative +scale added to the actual number of significant decimal digits, and +client-provided values may have to be rounded before being stored. + + + + + + +::: {.varxml .rep} +### Attribute `Scale` + +The value of `Scale` is a number or one of the symbolic values +`floating` or `variable`. + +Services SHOULD use lower-case values; clients SHOULD accept values in a +case-insensitive manner. + +If not specified, the `Scale` facet defaults to zero. +::: + +::: {.varxml .example} +Example 3: [`Precision`](#Precision)`=3` and `Scale=2`. +Allowed values: 1.23, 0.23, 3.14 and 0.7, not allowed values: 123, 12.3 +(the [`Nullable`](#Nullable) attribute can be ignored in these examples) +```xml + +``` +::: + +::: {.varxml .example} +Example 4: `Precision=2` equals `Scale`. +Allowed values: 0.23, 0.7, not allowed values: 1.23, 1.2 +```xml + +``` +::: + +::: {.varxml .example} +Example 5: `Precision=3` and a variable `Scale`. +Allowed values: 0.123, 1.23, 0.23, 0.7, 123 and 12.3, not allowed +values: 12.34, 1234 and 123.4 due to the limited precision. +```xml + +``` +::: + +::: {.varxml .example} +Example 6: `Precision=7` and a floating `Scale`. +Allowed values: -1.234567e3, 1e-101, 9.999999e96, not allowed values: +1e-102 and 1e97 due to the limited precision. +```xml + +``` +::: + +### 3.4.4 Unicode + +For a string-typed model element the `Unicode` facet indicates whether the it +might contain and accept string values with Unicode characters (code +points) beyond the ASCII character set. The value `false` indicates that +the it will only contain and accept string values with characters +limited to the ASCII character set. + +If no value is specified, the `Unicode` facet defaults to `true`. + + +::: {.varxml .rep} +### Attribute `Unicode` + +The value of `Unicode` is one of the Boolean literals `true` or `false`. +Absence of the attribute means `true`. +::: + +### 3.4.5 SRID + +For a geometry- or geography-typed model element the `SRID` facet identifies which +spatial reference system is applied to its values. + +The value of the `SRID` facet MUST be a non-negative integer or the +special value `variable`. If no value is specified, the facet defaults +to `0` for `Geometry` types or `4326` for `Geography` types. + +The valid values of the `SRID` facet and their meanings are as defined +by the European Petroleum Survey Group [EPSG](#_EPSG). + + +::: {.varxml .rep} +### Attribute `SRID` + +The value of `SRID` is a number or the symbolic value `variable`. +::: + +## 3.5 Built-In Abstract Types The following built-in abstract types can be used within a model: - `Edm.PrimitiveType` @@ -596,15 +796,13 @@ be used anywhere a corresponding concrete type can be used, except: - cannot be used as the underlying type of a type definition or enumeration type. - `Collection(Edm.PrimitiveType)` - - cannot be used as the type of a property or term. - - cannot be used as the type of a parameter or the return type of - an action or function. + - cannot be used. - `Collection(Edm.Untyped)` - cannot be returned in a payload with an `OData-Version` header of `4.0`. Services should treat untyped properties as dynamic properties in `4.0` payloads. -## 3.5 Built-In Types for defining Vocabulary Terms +## 3.6 Built-In Types for defining Vocabulary Terms [Vocabulary terms](#VocabularyandAnnotation) can, in addition, use - `Edm.AnnotationPath` @@ -619,7 +817,7 @@ 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](#PathExpressions)" for details. -## 3.6 Annotations +## 3.7 Annotations Many parts of the model can be decorated with additional information using [annotations](#Annotation). Annotations are identified by their @@ -639,7 +837,7 @@ combination of term and qualifier. ::: {.varxml .rep} -### Element `edmx:Edmx` +### Element `edmx:Edmx` The `edmx:Edmx` element is the root element of a CSDL XML document. It MUST contain the `Version` attribute and it MUST contain exactly one @@ -648,15 +846,15 @@ MUST contain the `Version` attribute and it MUST contain exactly one It MAY contain [`edmx:Reference`](#Reference) elements to reference other CSDL documents. -### Attribute `Version` +### Attribute `Version` The `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 +`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` +### Element `edmx:DataServices` The `edmx:DataServices` element MUST contain one or more [`edm:Schema`](#Schema) elements which define the schemas exposed by the @@ -664,7 +862,7 @@ OData service. ::: ::: {.varxml .example} -Example 2: +Example 7: ```xml @@ -703,7 +901,7 @@ referenced schema document. ::: {.varxml .rep} -### Element `edmx:Reference` +### Element `edmx:Reference` The `edmx:Reference` element specifies external CSDL documents referenced by the referencing document. The child elements @@ -718,7 +916,7 @@ MUST contain at least one [`edmx:Include`](#IncludedSchema) or It MAY contain [`edm:Annotation`](#Annotation) elements. -### Attribute `Uri` +### Attribute `Uri` The value of `Uri` is an absolute or relative URI; relative URIs are relative to the `xml:base` attribute, see @@ -726,7 +924,7 @@ relative to the `xml:base` attribute, see ::: ::: {.varxml .example} -Example 3: references to other CSDL documents +Example 8: references to other CSDL documents ```xml Element `edmx:Include` +### Element `edmx:Include` The `edmx:Include` element specifies a schema to include from the referenced CSDL document. It MUST provide the `Namespace` attribute and @@ -793,19 +991,19 @@ it MAY provide the `Alias` attribute. It MAY contain [`edm:Annotation`](#Annotation) elements. -### Attribute `Namespace` +### Attribute `Namespace` The value of `Namespace` is the namespace of a schema defined in the referenced CSDL document. -### Attribute `Alias` +### Attribute `Alias` The value of `Alias` is a [simple identifier](#SimpleIdentifier) that can be used in qualified names instead of the namespace. ::: ::: {.varxml .example} -Example 4: references to entity models containing definitions of +Example 9: references to entity models containing definitions of vocabulary terms ```xml @@ -868,7 +1066,7 @@ not to inspect the referenced document. ::: {.varxml .rep} -### Element `edmx:IncludeAnnotations` +### Element `edmx:IncludeAnnotations` The `edmx:IncludeAnnotations` element specifies the annotations to include from the referenced CSDL document. If no @@ -880,21 +1078,21 @@ The `edmx:IncludeAnnotations` element MUST provide the `TermNamespace` attribute, and it MAY provide the `Qualifier` and `TargetNamespace` attribute. -### Attribute `TermNamespace` +### Attribute `TermNamespace` The value of `TermNamespace` is a namespace. -### Attribute `Qualifier` +### Attribute `Qualifier` The value of `Qualifier` is a [simple identifier](#SimpleIdentifier). -### Attribute `TargetNamespace` +### Attribute `TargetNamespace` The value of `TargetNamespace` is a namespace. ::: ::: {.varxml .example} -Example 5: reference documents that contain annotations +Example 10: reference documents that contain annotations ```xml Element `edm:Schema` +### Element `edm:Schema` The `edm:Schema` element defines a schema. It MUST contain the `Namespace` attribute and it MAY @@ -969,7 +1167,7 @@ It MAY contain elements [`edm:Action`](#Action), [`edm:Function`](#Function), [`edm:Term`](#Term), or [`edm:TypeDefinition`](#TypeDefinition). -### Attribute `Namespace` +### Attribute `Namespace` The value of `Namespace` is the namespace of the schema ::: @@ -1000,13 +1198,13 @@ The alias MUST NOT be one of the reserved values `Edm`, `odata`, ::: {.varxml .rep} -### Attribute `Alias` +### Attribute `Alias` The value of `Alias` is a [simple identifier](#SimpleIdentifier). ::: ::: {.varxml .example} -Example 6: schema `org.example` with an alias and a description for the +Example 11: schema `org.example` with an alias and a description for the schema ```xml @@ -1021,7 +1219,7 @@ schema ::: {.varxml .rep} -### Element `edm:Annotations` +### Element `edm:Annotations` The `edm:Annotations` element is used to apply a group of annotations to a single model element. It MUST contain the `Target` attribute and it @@ -1029,18 +1227,18 @@ MAY contain the `Qualifier` attribute. It MUST contain at least one [`edm:Annotation`](#Annotation) element. -### Attribute `Target` +### Attribute `Target` The value of `Target` is a path expression identifying the [annotation target](#Target). It MUST resolve to a model element in scope. -### Attribute `Qualifier` +### Attribute `Qualifier` The value of `Qualifier` is a [simple identifier](#SimpleIdentifier). ::: ::: {.varxml .example} -Example 7: annotations should only be applied to tablet devices +Example 12: annotations should only be applied to tablet devices ```xml @@ -1076,7 +1274,7 @@ types. ::: {.varxml .rep} -### Element `edm:EntityType` +### Element `edm:EntityType` The `edm:EntityType` element MUST contain the `Name` attribute, and it MAY contain the [`BaseType`](#DerivedEntityType), @@ -1091,13 +1289,13 @@ It MAY contain one [`edm:Key`](#Key) element. It MAY contain [`edm:Annotation`](#Annotation) elements. -### Attribute `Name` +### Attribute `Name` The value of `Name` is the entity type's name. ::: ::: {.varxml .example} -Example 8: a simple entity type +Example 13: a simple entity type ```xml @@ -1125,13 +1323,13 @@ base type. ::: {.varxml .rep} -### Attribute `BaseType` +### Attribute `BaseType` The value of `BaseType` is the qualified name of the base type. ::: ::: {.varxml .example} -Example 9: a derived entity type based on the previous example +Example 14: a derived entity type based on the previous example ```xml @@ -1159,7 +1357,7 @@ type. ::: {.varxml .rep} -### Attribute `Abstract` +### Attribute `Abstract` The value of `Abstract` is one of the Boolean literals `true` or `false`. Absence of the attribute means `false`. @@ -1183,7 +1381,7 @@ properties on instances of any structured type, see ::: {.varxml .rep} -### Attribute `OpenType` +### Attribute `OpenType` The value of `OpenType` is one of the Boolean literals `true` or `false`. Absence of the attribute means `false`. @@ -1212,7 +1410,7 @@ see [OData-VocCore](#ODataVocCore). ::: {.varxml .rep} -### Attribute `HasStream` +### Attribute `HasStream` The value of `HasStream` is one of the Boolean literals `true` or `false`. Absence of the attribute means `false`. @@ -1299,29 +1497,29 @@ special encoding and are a standard constituent of expressions anyway. ::: {.varxml .rep} -### Element `edm:Key` +### Element `edm:Key` The `edm:Key` element MUST contain at least one `edm:PropertyRef` element. -### Element `edm:PropertyRef` +### Element `edm:PropertyRef` The `edm:PropertyRef` element MUST contain the `Name` attribute and MAY contain the `Alias` attribute. -### Attribute `Name` +### Attribute `Name` The value of `Name` is a path expression leading to a primitive property. The names of the properties in the path are joined together by forward slashes. -### Attribute `Alias` +### Attribute `Alias` The value of `Alias` is a [simple identifier](#SimpleIdentifier). ::: ::: {.varxml .example} -Example 10: entity type with a simple key +Example 15: entity type with a simple key ```xml @@ -1334,7 +1532,7 @@ Example 10: entity type with a simple key ::: ::: {.varxml .example} -Example 11: entity type with a simple key referencing a property of a +Example 16: entity type with a simple key referencing a property of a [complex type](#ComplexType) ```xml @@ -1353,7 +1551,7 @@ Example 11: entity type with a simpl ::: ::: {.varxml .example} -Example 12: entity type with a composite key +Example 17: entity type with a composite key ```xml @@ -1367,7 +1565,7 @@ Example 12: entity type with a composite key ::: ::: example -Example 13 (based on [example 11](#complexkey)): requests to an entity set `Categories` +Example 18 (based on [example 16](#complexkey)): requests to an entity set `Categories` of type `Category` must use the alias ``` GET http://host/service/Categories(EntityInfoID=1) @@ -1375,7 +1573,7 @@ GET http://host/service/Categories(EntityInfoID=1) ::: ::: example -Example 14 (based on [example 11](#complexkey)): in a query part the value assigned to +Example 19 (based on [example 16](#complexkey)): in a query part the value assigned to the name attribute must be used ``` GET http://example.org/OData.svc/Categories?$filter=Info/ID le 100 @@ -1415,23 +1613,23 @@ that differ only in case. ::: {.varxml .rep} -### Element `edm:Property` +### Element `edm:Property` The `edm:Property` element MUST contain the `Name` and the `Type` -attribute, and it MAY contain the facet attributes +attribute, and it MAY contain the attributes [`Nullable`](#Nullable), [`MaxLength`](#MaxLength), [`Unicode`](#Unicode), [`Precision`](#Precision), [`Scale`](#Scale), [`SRID`](#SRID), and [`DefaultValue`](#DefaultValue). It MAY contain [`edm:Annotation`](#Annotation) elements. -### Attribute `Name` +### Attribute `Name` The value of `Name` is the property's name. ::: ::: {.varxml .example} -Example 15: complex type with two properties +Example 20: complex type with two properties ```xml Attribute `Type` +### Attribute `Type` For single-valued properties the value of `Type` is the qualified name of the property's type. @@ -1473,29 +1671,21 @@ item type, followed by a closing parenthesis `)`. ::: ::: {.varxml .example} -Example 16: property `Units` that can have zero or more strings as its +Example 21: property `Units` that can have zero or more strings as its value ```xml ``` ::: -## 7.2 Type Facets - -Facets modify or constrain the acceptable values of a property. - -For single-valued properties the facets apply to the value of the -property. For collection-valued properties the facets apply to the items -in the collection. - -### 7.2.1 Nullable +## 7.2 Nullable A Boolean value specifying whether the property can have the value `null`. ::: {.varxml .rep} -### Attribute `Nullable` +### Attribute `Nullable` The value of `Nullable` is one of the Boolean literals `true` or `false`. @@ -1503,7 +1693,7 @@ The value of `Nullable` is one of the Boolean literals `true` or For single-valued properties the value `true` means that the property allows the `null` value. -For collection-valued properties the property value will always be a +For collection-valued properties the value will always be a collection that MAY be empty. In this case the `Nullable` attribute applies to items of the collection and specifies whether the collection MAY contain `null` values. @@ -1519,198 +1709,9 @@ cannot assume any default value. Clients SHOULD be prepared for this situation even in OData 4.01 responses. ::: -### 7.2.2 MaxLength - -A positive integer value specifying the maximum length of a binary, -stream or string value. For binary or stream values this is the octet -length of the binary data, for string values it is the character length -(number of code points for Unicode). - -If no maximum length is specified, clients SHOULD expect arbitrary -length. - - -::: {.varxml .rep} -### Attribute `MaxLength` - -The value of `MaxLength` is a positive integer or the symbolic value -`max` as a shorthand for the maximum length supported for the type by -the service. - -Note: the symbolic value `max` is only allowed in OData 4.0 responses; -it is deprecated in OData 4.01. While clients MUST be prepared for this -symbolic value, OData 4.01 and greater services MUST NOT return the -symbolic value `max` and MAY instead specify the concrete maximum length -supported for the type by the service or omit the attribute entirely. -::: - -### 7.2.3 Precision - -For a decimal value: the maximum number of significant decimal digits of -the property'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 properties and 7 for -temporal properties. 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 properties will reduce -the risk for unintended data loss. - -Note: duration properties supporting a granularity less than seconds -(e.g. minutes, hours, days) can be annotated with term -[`Measures.DurationGranularity`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Measures.V1.md#DurationGranularity), -see [OData-VocMeasures](#ODataVocMeasures). +## 7.3 Default Value - - -::: {.varxml .rep} -### Attribute `Precision` - -The value of `Precision` is a number. - -If not specified for a decimal property, the decimal property has -arbitrary precision. - -If not specified for a temporal property, the temporal property has a -precision of zero. -::: - -::: {.varxml .example} -Example 17: [`Precision`](#Precision) facet applied to the -`DateTimeOffset` type -```xml - -``` -::: - -### 7.2.4 Scale - -A non-negative integer value specifying the maximum number of digits -allowed to the right of the decimal point, or one of the symbolic values -`floating` or `variable`. - -The value `floating` means that the decimal property represents a -decimal floating-point number whose number of significant digits is the -value of the [`Precision`](#Precision) facet. OData 4.0 responses MUST -NOT specify the value `floating`. - -The value `variable` means that the number of digits to the right of the -decimal point can vary from zero to the value of the -[`Precision`](#Precision) facet. - -An integer value means that the number of digits to the right of the -decimal point may vary from zero to the value of the `Scale` facet, and -the number of digits to the left of the decimal point may vary from one -to the value of the `Precision` facet minus the value of the `Scale` -facet. If `Precision` is equal to `Scale`, a single zero MUST precede -the decimal point. - -The value of `Scale` MUST be less than or equal to the value of -[`Precision`](#Precision). - -Note: if the underlying data store allows negative scale, services may -use a [`Precision`](#Precision) with the absolute value of the negative -scale added to the actual number of significant decimal digits, and -client-provided values may have to be rounded before being stored. - - - - - - -::: {.varxml .rep} -### Attribute `Scale` - -The value of `Scale` is a number or one of the symbolic values -`floating` or `variable`. - -Services SHOULD use lower-case values; clients SHOULD accept values in a -case-insensitive manner. - -If not specified, the `Scale` facet defaults to zero. -::: - -::: {.varxml .example} -Example 18: [`Precision`](#Precision)`=3` and `Scale=2`. -Allowed values: 1.23, 0.23, 3.14 and 0.7, not allowed values: 123, 12.3 -```xml - -``` -::: - -::: {.varxml .example} -Example 19: `Precision=2` equals `Scale`. -Allowed values: 0.23, 0.7, not allowed values: 1.23, 1.2 -```xml - -``` -::: - -::: {.varxml .example} -Example 20: `Precision=3` and a variable `Scale`. -Allowed values: 0.123, 1.23, 0.23, 0.7, 123 and 12.3, not allowed -values: 12.34, 1234 and 123.4 due to the limited precision. -```xml - -``` -::: - -::: {.varxml .example} -Example 21: `Precision=7` and a floating `Scale`. -Allowed values: -1.234567e3, 1e-101, 9.999999e96, not allowed values: -1e-102 and 1e97 due to the limited precision. -```xml - -``` -::: - -### 7.2.5 Unicode - -For a string property the `Unicode` facet indicates whether the property -might contain and accept string values with Unicode characters (code -points) beyond the ASCII character set. The value `false` indicates that -the property will only contain and accept string values with characters -limited to the ASCII character set. - -If no value is specified, the `Unicode` facet defaults to `true`. - - -::: {.varxml .rep} -### Attribute `Unicode` - -The value of `Unicode` is one of the Boolean literals `true` or `false`. -Absence of the attribute means `true`. -::: - -### 7.2.6 SRID - -For a geometry or geography property the `SRID` facet identifies which -spatial reference system is applied to values of the property on type -instances. - -The value of the `SRID` facet MUST be a non-negative integer or the -special value `variable`. If no value is specified, the facet defaults -to `0` for `Geometry` types or `4326` for `Geography` types. - -The valid values of the `SRID` facet and their meanings are as defined -by the European Petroleum Survey Group [EPSG](#_EPSG). - - -::: {.varxml .rep} -### Attribute `SRID` - -The value of `SRID` is a number or the symbolic value `variable`. -::: - -### 7.2.7 Default Value - -A primitive or enumeration property MAY define a default value that is +A primitive- or enumeration-typed property MAY define a default value that is used if the property is not explicitly represented in an annotation or the body of a request or response. @@ -1718,7 +1719,7 @@ If no value is specified, the client SHOULD NOT assume a default value. ::: {.varxml .rep} -### Attribute `DefaultValue` +### Attribute `DefaultValue` Default values of type `Edm.String` MUST be represented according to the XML escaping rules for character data in attribute values. Values of @@ -1755,7 +1756,7 @@ that differ only in case. ::: {.varxml .rep} -### Element `edm:NavigationProperty` +### Element `edm:NavigationProperty` The `edm:NavigationProperty` element MUST contain the `Name` and `Type` attributes, and it MAY contain the attributes @@ -1769,7 +1770,7 @@ child element [`edm:OnDelete`](#OnDeleteAction). It MAY contain [`edm:Annotation`](#Annotation) elements. -### Attribute `Name` +### Attribute `Name` The value of `Name` is the navigation property's name. ::: @@ -1820,7 +1821,7 @@ supports inserting items into a specific ordinal position. ::: {.varxml .rep} -### Attribute `Type` +### Attribute `Type` For single-valued navigation properties the value of `Type` is the qualified name of the navigation property's type. @@ -1841,7 +1842,7 @@ property, a collection is allowed to have zero items. ::: {.varxml .rep} -### Attribute `Nullable` +### Attribute `Nullable` The value of `Nullable` is one of the Boolean literals `true` or `false`. Absence of the attribute means `true`. @@ -1881,7 +1882,7 @@ partner navigation property. ::: {.varxml .rep} -### Attribute `Partner` +### Attribute `Partner` The value of `Partner` is the path to the of the partner navigation property. @@ -1956,7 +1957,7 @@ can also be reached via a non-containment navigation path. ::: {.varxml .rep} -### Attribute `ContainsTarget` +### Attribute `ContainsTarget` The value of `ContainsTarget` is one of the Boolean literals `true` or `false`. Absence of the attribute means `false`. @@ -1974,10 +1975,10 @@ the target of the navigation). The type of the dependent property MUST match the type of the principal property, or both types MUST be complex types. -If the principle property references an entity, then the dependent +If the principal property references an entity, then the dependent property must reference the same entity. -If the principle property's value is a complex type instance, then the +If the principal property's value is a complex type instance, then the dependent property's value must be a complex type instance with the same properties, each with the same values. @@ -1990,14 +1991,14 @@ property MUST NOT be nullable. ::: {.varxml .rep} -### Element `edm:ReferentialConstraint` +### Element `edm:ReferentialConstraint` The `edm:ReferentialConstraint` element MUST contain the attributes `Property` and `ReferencedProperty`. It MAY contain [`edm:Annotation`](#Annotation) elements. -### Attribute `Property` +### Attribute `Property` The `Property` attribute specifies the property that takes part in the referential constraint on the dependent structured type. Its value MUST @@ -2007,7 +2008,7 @@ dependent structured type. The names of the properties in the path are joined together by forward slashes. The path is relative to the dependent structured type declaring the navigation property. -### Attribute `ReferencedProperty` +### Attribute `ReferencedProperty` The `ReferencedProperty` attribute specifies the corresponding property of the principal entity type. Its value MUST be a path expression @@ -2075,13 +2076,13 @@ not predictable by the client and could vary per entity. ::: {.varxml .rep} -### Element `edm:OnDelete` +### Element `edm:OnDelete` The `edm:OnDelete` element MUST contain the `Action` attribute. It MAY contain [`edm:Annotation`](#Annotation) elements. -### Attribute `Action` +### Attribute `Action` The value of `Action` is one of the values `Cascade`, `None`, `SetNull`, or `SetDefault`. @@ -2131,7 +2132,7 @@ types. ::: {.varxml .rep} -### Element `edm:ComplexType` +### Element `edm:ComplexType` The `edm:ComplexType` element MUST contain the `Name` attribute, and it MAY contain the [`BaseType`](#DerivedComplexType), @@ -2144,7 +2145,7 @@ properties of the complex type. It MAY contain [`edm:Annotation`](#Annotation) elements. -### Attribute `Name` +### Attribute `Name` The value of `Name` is the complex type's name. ::: @@ -2187,7 +2188,7 @@ The rules for annotations of derived complex types are described in ::: {.varxml .rep} -### Attribute `BaseType` +### Attribute `BaseType` The value of `BaseType` is the qualified name of the base type. ::: @@ -2199,7 +2200,7 @@ instances. ::: {.varxml .rep} -### Attribute `Abstract` +### Attribute `Abstract` The value of `Abstract` is one of the Boolean literals `true` or `false`. Absence of the attribute means `false`. @@ -2223,7 +2224,7 @@ properties on instances of any structured type, see ::: {.varxml .rep} -### Attribute `OpenType` +### Attribute `OpenType` The value of `OpenType` is one of the Boolean literals `true` or `false`. Absence of the attribute means `false`. @@ -2252,7 +2253,7 @@ one enumeration member at a time. ::: {.varxml .rep} -### Element `edm:EnumType` +### Element `edm:EnumType` The `edm:EnumType` element MUST contain the Name attribute, and it MAY contain the [`UnderlyingType`](#UnderlyingIntegerType) and @@ -2263,7 +2264,7 @@ elements defining the members of the enumeration type. It MAY contain [`edm:Annotation`](#Annotation) elements. -### Attribute `Name` +### Attribute `Name` The value of `Name` is the enumeration type's name. ::: @@ -2289,7 +2290,7 @@ If not explicitly specified, `Edm.Int32` is used as the underlying type. ::: {.varxml .rep} -### Attribute `UnderlyingType` +### Attribute `UnderlyingType` The value of `UnderlyingType` is the qualified name of the underlying type. @@ -2306,7 +2307,7 @@ selected simultaneously. ::: {.varxml .rep} -### Attribute `IsFlags` +### Attribute `IsFlags` The value of `IsFlags` is one of the Boolean literals `true` or `false`. Absence of the attribute means `false`. @@ -2358,18 +2359,18 @@ values. ::: {.varxml .rep} -### Element `edm:Member` +### Element `edm:Member` The `edm:Member` element MUST contain the `Name` attribute and it MAY contain the `Value` attribute. It MAY contain [`edm:Annotation`](#Annotation) elements. -### Attribute `Name` +### Attribute `Name` The value of `Name` is the enumeration member's name. -### Attribute `Value` +### Attribute `Value` If the [`IsFlags`](#FlagsEnumerationType) attribute has a value of `false`, either all members MUST specify an integer value for the @@ -2429,14 +2430,14 @@ definition is used, and whether they can be overridden. ::: {.varxml .rep} -### Element `edm:TypeDefinition` +### Element `edm:TypeDefinition` The `edm:TypeDefinition` element MUST contain the `Name` and [`UnderlyingType`](#UnderlyingPrimitiveType) attributes. It MAY contain [`edm:Annotation`](#Annotation) elements. -### Attribute `Name` +### Attribute `Name` The value of `Name` is the type definition's name. ::: @@ -2469,7 +2470,7 @@ MUST NOT be another type definition. ::: {.varxml .rep} -### Attribute `UnderlyingType` +### Attribute `UnderlyingType` The value of `UnderlyingType` is the qualified name of the underlying type. @@ -2531,7 +2532,7 @@ An unbound action MAY have the same name as a bound action. ::: {.varxml .rep} -### Element `edm:Action` +### Element `edm:Action` The `edm:Action` element MUST contain the `Name` attribute and it MAY contain the [`IsBound`](#BoundorUnboundActionorFunctionOverloads) and @@ -2542,7 +2543,7 @@ MAY contain [`edm:Parameter`](#Parameter) elements. It MAY contain [`edm:Annotation`](#Annotation) elements. -### Attribute `Name` +### Attribute `Name` The value of `Name` is the action's name. ::: @@ -2597,7 +2598,7 @@ they specify the same underlying type. ::: {.varxml .rep} -### Element `edm:Function` +### Element `edm:Function` The `edm:Function` element MUST contain the `Name` attribute and it MAY contain the [`IsBound`](#BoundorUnboundActionorFunctionOverloads) and @@ -2608,7 +2609,7 @@ contain [`edm:Parameter`](#Parameter) elements. It MAY contain [`edm:Annotation`](#Annotation) elements. -### Attribute `Name` +### Attribute `Name` The value of `Name` is the action's name. ::: @@ -2620,7 +2621,7 @@ explicitly indicated, it is unbound. Bound actions or functions are invoked on resources matching the type of the binding parameter. The binding parameter can be of any type, and it -MAY be [nullable](#Nullable). +MAY be nullable. Unbound actions are invoked from the entity container through an [action import](#ActionImport). @@ -2631,7 +2632,7 @@ or from the entity container through a [function import](#FunctionImport). ::: {.varxml .rep} -### Attribute `IsBound` +### Attribute `IsBound` The value of `IsBound` is one of the Boolean literals `true` or `false`. Absence of the attribute means `false`. @@ -2658,7 +2659,7 @@ entity type that should be returned from the type cast. ::: {.varxml .rep} -### Attribute `EntitySetPath` +### Attribute `EntitySetPath` The value of `EntitySetPath` is the entity set path. ::: @@ -2675,7 +2676,7 @@ the type returned by the composable function. ::: {.varxml .rep} -### Attribute `IsComposable` +### Attribute `IsComposable` The value of `IsComposable` is one of the Boolean literals `true` or `false`. Absence of the attribute means `false`. @@ -2686,7 +2687,7 @@ The value of `IsComposable` is one of the Boolean literals `true` or The return type of an action or function overload MAY be any type in scope, or a collection of any type in scope. -The facets [`Nullable`](#Nullable), [`MaxLength`](#MaxLength), +The facets [`MaxLength`](#MaxLength), [`Precision`](#Precision), [`Scale`](#Scale), and [`SRID`](#SRID) can be used as appropriate to specify value restrictions of the return type, as well as the [`Unicode`](#Unicode) facet for 4.01 and greater payloads. @@ -2697,7 +2698,7 @@ returned collection. ::: {.varxml .rep} -### Element `edm:ReturnType` +### Element `edm:ReturnType` The `edm:ReturnType` element MUST contain the `Type` attribute, and it MAY contain the attributes `Nullable`, [`MaxLength`](#MaxLength), @@ -2706,7 +2707,7 @@ MAY contain the attributes `Nullable`, [`MaxLength`](#MaxLength), It MAY contain [`edm:Annotation`](#Annotation) elements. -### Attribute `Type` +### Attribute `Type` For single-valued return types the value of `Type` is the qualified name of the return type. @@ -2715,7 +2716,7 @@ For collection-valued return types the value of `Type` is the character sequence `Collection(` followed by the qualified name of the return item type, followed by a closing parenthesis `)`. -### Attribute `Nullable` +### Attribute `Nullable` The value of `Nullable` is one of the Boolean literals `true` or `false`. Absence of the attribute means `true`. @@ -2761,7 +2762,7 @@ the collection. ::: {.varxml .rep} -### Element `edm:Parameter` +### Element `edm:Parameter` The `edm:Parameter` element MUST contain the `Name` and the `Type` attribute, and it MAY contain the attributes `Nullable`, @@ -2770,11 +2771,11 @@ attribute, and it MAY contain the attributes `Nullable`, It MAY contain [`edm:Annotation`](#Annotation) elements. -### Attribute `Name` +### Attribute `Name` The value of `Name` is the parameter's name. -### Attribute `Type` +### Attribute `Type` For single-valued parameters the value of `Type` is the qualified name of the parameter. @@ -2783,7 +2784,7 @@ 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` +### Attribute `Nullable` The value of `Nullable` is one of the Boolean literals `true` or `false`. Absence of the attribute means `true`. @@ -2870,7 +2871,7 @@ in an entity model as a top level resource. ::: {.varxml .rep} -### Element `edm:EntityContainer` +### Element `edm:EntityContainer` The `edm:EntityContainer` MUST contain one or more [`edm:EntitySet`](#EntitySet), [`edm:Singleton`](#Singleton), @@ -2879,7 +2880,7 @@ The `edm:EntityContainer` MUST contain one or more It MAY contain [`edm:Annotation`](#Annotation) elements. -### Attribute `Name` +### Attribute `Name` The value of `Name` is the entity container's name. ::: @@ -2928,7 +2929,7 @@ extending entity containers. ::: {.varxml .rep} -### Attribute `Extends` +### Attribute `Extends` The value of `Extends` is the qualified name of the entity container to be extended. @@ -2967,7 +2968,7 @@ options SHOULD NOT be included in the service document. ::: {.varxml .rep} -### Element `edm:EntitySet` +### Element `edm:EntitySet` The `edm:EntitySet` element MUST contain the attributes `Name` and `EntityType`, and it MAY contain the `IncludeInServiceDocument` @@ -2978,16 +2979,16 @@ It MAY contain It MAY contain [`edm:Annotation`](#Annotation) elements. -### Attribute `Name` +### Attribute `Name` The value of `Name` is the entity set's name. -### Attribute `EntityType` +### Attribute `EntityType` The value of `EntityType` is the qualified name of an entity type in scope. -### Attribute `IncludeInServiceDocument` +### Attribute `IncludeInServiceDocument` The value of `IncludeInServiceDocument` is one of the Boolean literals `true` or `false`. Absence of the attribute means `true`. @@ -3007,7 +3008,7 @@ A singleton MUST reference an instance its entity type. ::: {.varxml .rep} -### Element `edm:Singleton` +### Element `edm:Singleton` The `edm:Singleton` element MUST include the attributes `Name` and `Type`, and it MAY contain the `Nullable` attribute. @@ -3017,16 +3018,16 @@ It MAY contain It MAY contain [`edm:Annotation`](#Annotation) elements. -### Attribute `Name` +### Attribute `Name` The value of `Name` is the singleton's name. -### Attribute `Type` +### Attribute `Type` The value of `Type` is whose value is the [qualified name](#QualifiedName) of an entity type in scope. -### Attribute `Nullable` +### Attribute `Nullable` The value of `Nullable` is one of the Boolean literals `true` or `false`. @@ -3112,16 +3113,16 @@ be any non-containment navigation properties prior to the final segment. ::: {.varxml .rep} -### Element `edm:NavigationPropertyBinding` +### Element `edm:NavigationPropertyBinding` The `edm:NavigationPropertyBinding` element MUST contain the attributes `Path` and `Target`. -### Attribute `Path` +### Attribute `Path` The value of `Path` is a path expression. -### Attribute `Target` +### Attribute `Target` The value of `Target` is a [target path](#TargetPath). ::: @@ -3179,22 +3180,22 @@ to an entity set in scope. ::: {.varxml .rep} -### Element `edm:ActionImport` +### Element `edm:ActionImport` The `edm:ActionImport` element MUST contain the attributes `Name` and `Action`, and it MAY contain the `EntitySet` attribute. It MAY contain [`edm:Annotation`](#Annotation) elements. -### Attribute `Name` +### Attribute `Name` The value of `Name` is the action import's name. -### Attribute `Action` +### Attribute `Action` The value of `Action` is the qualified name of an unbound action. -### Attribute `EntitySet` +### Attribute `EntitySet` The value of `EntitySet` is either the unqualified name of an entity set in the same entity container or a path to an entity set in a different @@ -3227,27 +3228,29 @@ not included. ::: {.varxml .rep} -### Element `edm:FunctionImport` +### 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` +It MAY contain [`edm:Annotation`](#Annotation) elements. + +### Attribute `Name` The value of `Name` is the function import's name. -### Attribute `Function` +### Attribute `Function` The value of `Function` is the qualified name of an unbound function. -### Attribute `EntitySet` +### Attribute `EntitySet` The value of `EntitySet` is either the unqualified name of an entity set in the same entity container or a path to an entity set in a different entity container. -### Attribute `IncludeInServiceDocument` +### Attribute `IncludeInServiceDocument` The value of `IncludeInServiceDocument` is one of the Boolean literals `true` or `false`. Absence of the attribute means `false`. @@ -3351,37 +3354,57 @@ scope. ::: {.varxml .rep} -### Element `edm:Term` +### Element `edm:Term` The `edm:Term` element MUST contain the attributes `Name` and `Type`. It -MAY contain the attributes `BaseTerm` and `AppliesTo`. +MAY contain the attributes `Nullable`, `DefaultValue`, [`BaseTerm`](#SpecializedTerm) and [`AppliesTo`](#Applicability). -It MAY specify values for the [`Nullable`](#Nullable), -[ ]{.apple-converted-space}[`MaxLength`](#MaxLength), -[`Precision`](#Precision), [`Scale`](#Scale), or [`SRID`](#SRID) facet -attributes, as well as the [`Unicode`](#Unicode) facet attribute for -4.01 and greater payloads. These facets and their implications are -described in section 7.2. +The facets [`MaxLength`](#MaxLength), +[`Precision`](#Precision), [`Scale`](#Scale), and [`SRID`](#SRID) can be +used as appropriate, as well as the [`Unicode`](#Unicode) facet attribute for +4.01 and greater payloads. 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`](#Annotation) elements. -### Attribute `Name` +### Attribute `Name` The value of `Name` is the term's name. -### Attribute `Type` +### Attribute `Type` -For single-valued properties the value of `Type` is the qualified name -of the property's 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 `)`. -### Attribute `DefaultValue` +### 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. + +For collection-valued terms the annotation value will always be a +collection that MAY be empty. In this case the `Nullable` attribute +applies to items of the collection and specifies whether the collection +MAY contain `null` values. + +If no value is specified for a single-valued term, the `Nullable` +attribute defaults to `true`. + +In OData 4.01 responses a collection-valued term MUST specify a +value for the `Nullable` attribute. + +If no value is specified for a collection-valued term, the client +cannot assume any default value. Clients SHOULD be prepared for this +situation even in OData 4.01 responses. + +### Attribute `DefaultValue` The value of this attribute determines the value of the term when applied in an [`edm:Annotation`](#Annotation) without providing an @@ -3409,7 +3432,7 @@ reached. ::: {.varxml .rep} -### Attribute `BaseTerm` +### Attribute `BaseTerm` The value of `BaseTerm` is the qualified name of the base term. ::: @@ -3463,7 +3486,7 @@ Symbolic Value|Model Element ::: {.varxml .rep} -### Attribute `AppliesTo` +### Attribute `AppliesTo` The value of `AppliesTo` is a whitespace-separated list of symbolic values from the table above that identify model elements the term is @@ -3504,7 +3527,7 @@ property of the same or a related structured type. ::: {.varxml .rep} -### Element `edm:Annotation` +### Element `edm:Annotation` The `edm:Annotation` element MUST contain the attribute `Term`, and it MAY contain the attribute [`Qualifier`](#Qualifier). @@ -3528,7 +3551,7 @@ targets the model element to be annotated. An `edm:Annotation` element MAY contain [`edm:Annotation`](#Annotation) elements that annotate the annotation. -### Attribute `Term` +### Attribute `Term` The value of `Term` is the qualified name of a [term](#Term) in scope. ::: @@ -3583,7 +3606,7 @@ identifies an annotation. ::: {.varxml .rep} -### Attribute `Qualifier` +### Attribute `Qualifier` Annotation elements that are children of an [`edm:Annotations`](#AnnotationswithExternalTargeting) element MUST NOT @@ -3664,7 +3687,7 @@ term. ::: {.varxml .rep} -### Expression `edm:Binary` +### Expression `edm:Binary` The `edm:Binary` expression evaluates to a primitive binary value. A binary expression MUST be assigned a value conforming to the rule @@ -3690,7 +3713,7 @@ Example 43: base64url-encoded binary value (OData) ::: {.varxml .rep} -### Expression `edm:Bool` +### Expression `edm:Bool` The `edm:Bool` expression evaluates to a primitive Boolean value. A Boolean expression MUST be assigned a Boolean value. @@ -3715,7 +3738,7 @@ Example 44: ::: {.varxml .rep} -### Expression `edm:Date` +### Expression `edm:Date` The `edm:Date` expression evaluates to a primitive date value. A date expression MUST be assigned a value of type `xs:date`, see @@ -3744,7 +3767,7 @@ Example 45: ::: {.varxml .rep} -### Expression `edm:DateTimeOffset` +### Expression `edm:DateTimeOffset` The `edm:DateTimeOffset` expression evaluates to a primitive datetimestamp value with a time-zone offset. A datetimestamp expression @@ -3778,7 +3801,7 @@ Example 46: ::: {.varxml .rep} -### Expression `edm:Decimal` +### Expression `edm:Decimal` The `edm:Decimal` expression evaluates to a primitive decimal value. A decimal expression MUST be assigned a value conforming to the rule @@ -3809,7 +3832,7 @@ Example 48: element notation ::: {.varxml .rep} -### Expression `edm:Duration` +### Expression `edm:Duration` The `edm:Duration` expression evaluates to a primitive duration value. A duration expression MUST be assigned a value of type @@ -3837,7 +3860,7 @@ Example 49: ::: {.varxml .rep} -### Expression `edm:EnumMember` +### Expression `edm:EnumMember` The `edm:EnumMember` expression references a [member](#EnumerationTypeMember) of an [enumeration @@ -3882,7 +3905,7 @@ Example 51: combined value for `IsFlags` enumeration type ::: {.varxml .rep} -### Expression `edm:Float` +### Expression `edm:Float` The `edm:Float` expression evaluates to a primitive floating point (or double) value. A float expression MUST be assigned a value conforming to @@ -3908,7 +3931,7 @@ Example 52: ::: {.varxml .rep} -### Expression `edm:Guid` +### Expression `edm:Guid` The `edm:Guid` expression evaluates to a primitive guid value. A guid expression MUST be assigned a value conforming to the rule `guidValue` @@ -3936,7 +3959,7 @@ Example 53: ::: {.varxml .rep} -### Expression `edm:Int` +### Expression `edm:Int` The `edm:Int` expression evaluates to a primitive integer value. An integer MUST be assigned a value conforming to the rule `int64Value` in @@ -3967,7 +3990,7 @@ Example 55: element notation ::: {.varxml .rep} -### Expression `edm:String` +### Expression `edm:String` The `edm:String` expression evaluates to a primitive string value. A string expression MUST be assigned a value of the type `xs:string`, see @@ -3994,7 +4017,7 @@ Example 56: ::: {.varxml .rep} -### Expression `edm:TimeOfDay` +### Expression `edm:TimeOfDay` The `edm:TimeOfDay` expression evaluates to a primitive time value. A time-of-day expression MUST be assigned a value conforming to the rule @@ -4360,7 +4383,7 @@ that reuse or refer to other terms. ::: {.varxml .rep} -### Expression `edm:AnnotationPath` +### Expression `edm:AnnotationPath` The `edm:AnnotationPath` expression MAY be provided using element notation or attribute notation. @@ -4394,7 +4417,7 @@ the instance(s) identified by the path. ::: {.varxml .rep} -### Expression `edm:ModelElementPath` +### Expression `edm:ModelElementPath` The `edm:ModelElementPath` expression MAY be provided using element notation or attribute notation. @@ -4430,7 +4453,7 @@ not the entitiy or collection of entities identified by the path. ::: {.varxml .rep} -### Expression `edm:NavigationPropertyPath` +### Expression `edm:NavigationPropertyPath` The `edm:NavigationPropertyPath` expression MAY be provided using element notation or attribute notation. @@ -4473,7 +4496,7 @@ identified by the path. ::: {.varxml .rep} -### Expression `edm:PropertyPath` +### Expression `edm:PropertyPath` The `edm:PropertyPath` MAY be provided using either element notation or attribute notation. @@ -4511,7 +4534,7 @@ instances identified by the path. ::: {.varxml .rep} -### Expression `edm:Path` +### Expression `edm:Path` The `edm:Path` expression MAY be provided using element notation or attribute notation. @@ -4562,21 +4585,21 @@ evaluate to comparable values. ::: {.varxml .rep} -### Expressions `edm:And` and `edm:Or` +### Expressions `edm:And` and `edm:Or` The `And` and `Or` logical expressions are represented as elements `edm:And` and `edm:Or` that MUST contain two annotation expressions. It MAY contain [`edm:Annotation`](#Annotation) elements. -### Expression `edm:Not` +### Expression `edm:Not` Negation expressions are represented as an element `edm:Not` that MUST contain a single annotation expression. It MAY contain [`edm:Annotation`](#Annotation) elements. -### Expressions `edm:Eq`, `edm:Ne`, `edm:Gt`, `edm:Ge`, `edm:Lt`, `edm:Le`, `edm:Has`, and `edm:In` +### Expressions `edm:Eq`, `edm:Ne`, `edm:Gt`, `edm:Ge`, `edm:Lt`, `edm:Le`, `edm:Has`, and `edm:In` All comparison expressions are represented as an element that MUST contain two annotation expressions. @@ -4662,14 +4685,14 @@ expressions that evaluate to numeric values. ::: {.varxml .rep} -### Expression `edm:Neg` +### Expression `edm:Neg` Negation expressions are represented as an element `edm:Neg` that MUST contain a single annotation expression. It MAY contain [`edm:Annotation`](#Annotation) elements. -### Expressions `edm:Add`, `edm:Sub`, `edm:Mul`, `edm:Div`, `edm:DivBy`, and `edm:Mod` +### Expressions `edm:Add`, `edm:Sub`, `edm:Mul`, `edm:Div`, `edm:DivBy`, and `edm:Mod` These arithmetic expressions are represented as an element that MUST contain two annotation expressions. @@ -4719,14 +4742,14 @@ function. ::: {.varxml .rep} -### Expression `edm:Apply` +### Expression `edm:Apply` The `edm:Apply` element MUST contain the `Function` attribute and MAY contain annotation expressions as operands for the applied function. It MAY contain more [`edm:Annotation`](#Annotation) elements. -### Attribute `Function` +### Attribute `Function` The value of `Function` is the [qualified name](#QualifiedName) of the client-side function to apply. @@ -4779,7 +4802,7 @@ the member name of the enumeration value. #### 14.4.4.2 Function `odata.fillUriTemplate` The `odata.fillUriTemplate` client-side function takes two or more -expressions as arguments and returns a value of type `Edm.String.` +expressions as arguments and returns a value of type `Edm.String`. The first argument MUST be of type `Edm.String` and specifies a URI template according to [RFC6570](#rfc6570), the other arguments MUST be @@ -4875,14 +4898,14 @@ rules as the `cast` canonical function defined in ::: {.varxml .rep} -### Expression `edm:Cast` +### Expression `edm:Cast` The `edm:Cast` element MUST contain the `Type` attribute and MUST contain exactly one expression. It MAY contain [`edm:Annotation`](#Annotation) elements. -### Attribute `Type` +### Attribute `Type` The value of `Type` is a qualified type name in scope, or the character sequence `Collection(` followed by the qualified name of a type in @@ -4918,7 +4941,7 @@ compatible. ::: {.varxml .rep} -### Expression `edm:Collection` +### Expression `edm:Collection` The `edm:Collection` element contains zero or more child expressions. ::: @@ -4964,7 +4987,7 @@ collection. ::: {.varxml .rep} -### Expression `edm:If` +### Expression `edm:If` The `edm:If` element MUST contain two or three child expressions that MUST use element notation. @@ -4997,7 +5020,7 @@ the specified type, and `false` otherwise. ::: {.varxml .rep} -### Expression `edm:UrlRef` +### Expression `edm:UrlRef` The `edm:UrlRef` expression MAY be provided using element notation or attribute notation. @@ -5038,7 +5061,7 @@ within the schema containing the expression. ::: {.varxml .rep} -### Expression `edm:LabeledElement` +### Expression `edm:LabeledElement` The `edm:LabeledElement` element MUST contain the Name attribute. @@ -5047,7 +5070,7 @@ or element notation. It MAY contain [`edm:Annotation`](#Annotation) elements. -### Attribute `Name` +### Attribute `Name` The value of `Name` is the labeled element's name. ::: @@ -5077,7 +5100,7 @@ expression as its value. ::: {.varxml .rep} -### Expression `edm:LabeledElementReference` +### Expression `edm:LabeledElementReference` The `edm:LabeledElementReference` element MUST contain the qualified name of a labeled element expression in its body. @@ -5102,7 +5125,7 @@ expression MAY be annotated. ::: {.varxml .rep} -### Expression `edm:Null` +### Expression `edm:Null` The `edm:Null` element MAY contain [`edm:Annotation`](#Annotation) elements. @@ -5153,18 +5176,18 @@ expression is equivalent to specifying an empty collection as its value. ::: {.varxml .rep} -### Expression `edm:Record` +### Expression `edm:Record` The `edm:Record` element MAY contain the `Type` attribute and MAY contain `edm:PropertyValue` elements. It MAY contain [`edm:Annotation`](#Annotation) elements. -### Attribute `Type` +### Attribute `Type` The value of `Type` is the qualified name of a structured type in scope. -### Element `edm:PropertyValue` +### Element `edm:PropertyValue` The `edm:PropertyValue` element MUST contain the `Property` attribute, and it MUST contain exactly one expression that MAY be provided using @@ -5172,14 +5195,14 @@ either element notation or attribute notation. It MAY contain [`edm:Annotation`](#Annotation) elements. -### Attribute `Property` +### Attribute `Property` The value of `Property` is the name of a property of the type of the enclosing `edm:Record` expression. ::: ::: {.varxml .example} -Example 87: this annotation "morphs" the entity type from [example 8](#entitytype) into +Example 87: this annotation "morphs" the entity type from [example 13](#entitytype) 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 @@ -5227,7 +5250,7 @@ surrounding expression. ::: {.varxml .rep} -### Expression `edm:UrlRef` +### Expression `edm:UrlRef` The `edm:UrlRef` expression MAY be provided using element notation or attribute notation. @@ -5353,7 +5376,7 @@ Example 90: - + @@ -5609,13 +5632,13 @@ _Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14 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. +_Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012_. +https://www.rfc-editor.org/info/rfc6570. ###### [RFC8174] _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. +https://www.rfc-editor.org/info/rfc8174. ###### [XML-1.1] @@ -5636,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. ------- @@ -5644,167 +5667,169 @@ https://openui5.hana.ondemand.com/1.40.10/#docs/guide/87aac894a40640f89920d7b2a4 # Appendix B. Table of XML Elements and Attributes ::: toc -- [Element `edmx:Edmx`](#ElementedmxEdmx1) - - [Attribute `Version`](#AttributeVersion1.1) -- [Element `edmx:DataServices`](#ElementedmxDataServices2) -- [Element `edmx:Reference`](#ElementedmxReference3) - - [Attribute `Uri`](#AttributeUri3.1) -- [Element `edmx:Include`](#ElementedmxInclude4) - - [Attribute `Namespace`](#AttributeNamespace4.1) - - [Attribute `Alias`](#AttributeAlias4.2) -- [Element `edmx:IncludeAnnotations`](#ElementedmxIncludeAnnotations5) - - [Attribute `TermNamespace`](#AttributeTermNamespace5.1) - - [Attribute `Qualifier`](#AttributeQualifier5.2) - - [Attribute `TargetNamespace`](#AttributeTargetNamespace5.3) -- [Element `edm:Schema`](#ElementedmSchema6) - - [Attribute `Namespace`](#AttributeNamespace6.1) - - [Attribute `Alias`](#AttributeAlias6.2) -- [Element `edm:Annotations`](#ElementedmAnnotations7) - - [Attribute `Target`](#AttributeTarget7.1) - - [Attribute `Qualifier`](#AttributeQualifier7.2) -- [Element `edm:EntityType`](#ElementedmEntityType8) - - [Attribute `Name`](#AttributeName8.1) - - [Attribute `BaseType`](#AttributeBaseType8.2) - - [Attribute `Abstract`](#AttributeAbstract8.3) - - [Attribute `OpenType`](#AttributeOpenType8.4) - - [Attribute `HasStream`](#AttributeHasStream8.5) -- [Element `edm:Key`](#ElementedmKey9) -- [Element `edm:PropertyRef`](#ElementedmPropertyRef10) - - [Attribute `Name`](#AttributeName10.1) - - [Attribute `Alias`](#AttributeAlias10.2) -- [Element `edm:Property`](#ElementedmProperty11) +- [Type Facet Attributes](#TypeFacetAttributes1) + - [Attribute `MaxLength`](#AttributeMaxLength1.1) + - [Attribute `Precision`](#AttributePrecision1.2) + - [Attribute `Scale`](#AttributeScale1.3) + - [Attribute `Unicode`](#AttributeUnicode1.4) + - [Attribute `SRID`](#AttributeSRID1.5) +- [Element `edmx:Edmx`](#ElementedmxEdmx2) + - [Attribute `Version`](#AttributeVersion2.1) +- [Element `edmx:DataServices`](#ElementedmxDataServices3) +- [Element `edmx:Reference`](#ElementedmxReference4) + - [Attribute `Uri`](#AttributeUri4.1) +- [Element `edmx:Include`](#ElementedmxInclude5) + - [Attribute `Namespace`](#AttributeNamespace5.1) + - [Attribute `Alias`](#AttributeAlias5.2) +- [Element `edmx:IncludeAnnotations`](#ElementedmxIncludeAnnotations6) + - [Attribute `TermNamespace`](#AttributeTermNamespace6.1) + - [Attribute `Qualifier`](#AttributeQualifier6.2) + - [Attribute `TargetNamespace`](#AttributeTargetNamespace6.3) +- [Element `edm:Schema`](#ElementedmSchema7) + - [Attribute `Namespace`](#AttributeNamespace7.1) + - [Attribute `Alias`](#AttributeAlias7.2) +- [Element `edm:Annotations`](#ElementedmAnnotations8) + - [Attribute `Target`](#AttributeTarget8.1) + - [Attribute `Qualifier`](#AttributeQualifier8.2) +- [Element `edm:EntityType`](#ElementedmEntityType9) + - [Attribute `Name`](#AttributeName9.1) + - [Attribute `BaseType`](#AttributeBaseType9.2) + - [Attribute `Abstract`](#AttributeAbstract9.3) + - [Attribute `OpenType`](#AttributeOpenType9.4) + - [Attribute `HasStream`](#AttributeHasStream9.5) +- [Element `edm:Key`](#ElementedmKey10) +- [Element `edm:PropertyRef`](#ElementedmPropertyRef11) - [Attribute `Name`](#AttributeName11.1) - - [Attribute `Type`](#AttributeType11.2) - - [Attribute `Nullable`](#AttributeNullable11.3) - - [Attribute `MaxLength`](#AttributeMaxLength11.4) - - [Attribute `Precision`](#AttributePrecision11.5) - - [Attribute `Scale`](#AttributeScale11.6) - - [Attribute `Unicode`](#AttributeUnicode11.7) - - [Attribute `SRID`](#AttributeSRID11.8) - - [Attribute `DefaultValue`](#AttributeDefaultValue11.9) -- [Element `edm:NavigationProperty`](#ElementedmNavigationProperty12) + - [Attribute `Alias`](#AttributeAlias11.2) +- [Element `edm:Property`](#ElementedmProperty12) - [Attribute `Name`](#AttributeName12.1) - [Attribute `Type`](#AttributeType12.2) - [Attribute `Nullable`](#AttributeNullable12.3) - - [Attribute `Partner`](#AttributePartner12.4) - - [Attribute `ContainsTarget`](#AttributeContainsTarget12.5) -- [Element `edm:ReferentialConstraint`](#ElementedmReferentialConstraint13) - - [Attribute `Property`](#AttributeProperty13.1) - - [Attribute `ReferencedProperty`](#AttributeReferencedProperty13.2) -- [Element `edm:OnDelete`](#ElementedmOnDelete14) - - [Attribute `Action`](#AttributeAction14.1) -- [Element `edm:ComplexType`](#ElementedmComplexType15) - - [Attribute `Name`](#AttributeName15.1) - - [Attribute `BaseType`](#AttributeBaseType15.2) - - [Attribute `Abstract`](#AttributeAbstract15.3) - - [Attribute `OpenType`](#AttributeOpenType15.4) -- [Element `edm:EnumType`](#ElementedmEnumType16) + - [Attribute `DefaultValue`](#AttributeDefaultValue12.4) +- [Element `edm:NavigationProperty`](#ElementedmNavigationProperty13) + - [Attribute `Name`](#AttributeName13.1) + - [Attribute `Type`](#AttributeType13.2) + - [Attribute `Nullable`](#AttributeNullable13.3) + - [Attribute `Partner`](#AttributePartner13.4) + - [Attribute `ContainsTarget`](#AttributeContainsTarget13.5) +- [Element `edm:ReferentialConstraint`](#ElementedmReferentialConstraint14) + - [Attribute `Property`](#AttributeProperty14.1) + - [Attribute `ReferencedProperty`](#AttributeReferencedProperty14.2) +- [Element `edm:OnDelete`](#ElementedmOnDelete15) + - [Attribute `Action`](#AttributeAction15.1) +- [Element `edm:ComplexType`](#ElementedmComplexType16) - [Attribute `Name`](#AttributeName16.1) - - [Attribute `UnderlyingType`](#AttributeUnderlyingType16.2) - - [Attribute `IsFlags`](#AttributeIsFlags16.3) -- [Element `edm:Member`](#ElementedmMember17) + - [Attribute `BaseType`](#AttributeBaseType16.2) + - [Attribute `Abstract`](#AttributeAbstract16.3) + - [Attribute `OpenType`](#AttributeOpenType16.4) +- [Element `edm:EnumType`](#ElementedmEnumType17) - [Attribute `Name`](#AttributeName17.1) - - [Attribute `Value`](#AttributeValue17.2) -- [Element `edm:TypeDefinition`](#ElementedmTypeDefinition18) + - [Attribute `UnderlyingType`](#AttributeUnderlyingType17.2) + - [Attribute `IsFlags`](#AttributeIsFlags17.3) +- [Element `edm:Member`](#ElementedmMember18) - [Attribute `Name`](#AttributeName18.1) - - [Attribute `UnderlyingType`](#AttributeUnderlyingType18.2) -- [Element `edm:Action`](#ElementedmAction19) + - [Attribute `Value`](#AttributeValue18.2) +- [Element `edm:TypeDefinition`](#ElementedmTypeDefinition19) - [Attribute `Name`](#AttributeName19.1) -- [Element `edm:Function`](#ElementedmFunction20) + - [Attribute `UnderlyingType`](#AttributeUnderlyingType19.2) +- [Element `edm:Action`](#ElementedmAction20) - [Attribute `Name`](#AttributeName20.1) - - [Attribute `IsBound`](#AttributeIsBound20.2) - - [Attribute `EntitySetPath`](#AttributeEntitySetPath20.3) - - [Attribute `IsComposable`](#AttributeIsComposable20.4) -- [Element `edm:ReturnType`](#ElementedmReturnType21) - - [Attribute `Type`](#AttributeType21.1) - - [Attribute `Nullable`](#AttributeNullable21.2) -- [Element `edm:Parameter`](#ElementedmParameter22) - - [Attribute `Name`](#AttributeName22.1) - - [Attribute `Type`](#AttributeType22.2) - - [Attribute `Nullable`](#AttributeNullable22.3) -- [Element `edm:EntityContainer`](#ElementedmEntityContainer23) +- [Element `edm:Function`](#ElementedmFunction21) + - [Attribute `Name`](#AttributeName21.1) + - [Attribute `IsBound`](#AttributeIsBound21.2) + - [Attribute `EntitySetPath`](#AttributeEntitySetPath21.3) + - [Attribute `IsComposable`](#AttributeIsComposable21.4) +- [Element `edm:ReturnType`](#ElementedmReturnType22) + - [Attribute `Type`](#AttributeType22.1) + - [Attribute `Nullable`](#AttributeNullable22.2) +- [Element `edm:Parameter`](#ElementedmParameter23) - [Attribute `Name`](#AttributeName23.1) - - [Attribute `Extends`](#AttributeExtends23.2) -- [Element `edm:EntitySet`](#ElementedmEntitySet24) + - [Attribute `Type`](#AttributeType23.2) + - [Attribute `Nullable`](#AttributeNullable23.3) +- [Element `edm:EntityContainer`](#ElementedmEntityContainer24) - [Attribute `Name`](#AttributeName24.1) - - [Attribute `EntityType`](#AttributeEntityType24.2) - - [Attribute `IncludeInServiceDocument`](#AttributeIncludeInServiceDocument24.3) -- [Element `edm:Singleton`](#ElementedmSingleton25) + - [Attribute `Extends`](#AttributeExtends24.2) +- [Element `edm:EntitySet`](#ElementedmEntitySet25) - [Attribute `Name`](#AttributeName25.1) - - [Attribute `Type`](#AttributeType25.2) - - [Attribute `Nullable`](#AttributeNullable25.3) -- [Element `edm:NavigationPropertyBinding`](#ElementedmNavigationPropertyBinding26) - - [Attribute `Path`](#AttributePath26.1) - - [Attribute `Target`](#AttributeTarget26.2) -- [Element `edm:ActionImport`](#ElementedmActionImport27) - - [Attribute `Name`](#AttributeName27.1) - - [Attribute `Action`](#AttributeAction27.2) - - [Attribute `EntitySet`](#AttributeEntitySet27.3) -- [Element `edm:FunctionImport`](#ElementedmFunctionImport28) + - [Attribute `EntityType`](#AttributeEntityType25.2) + - [Attribute `IncludeInServiceDocument`](#AttributeIncludeInServiceDocument25.3) +- [Element `edm:Singleton`](#ElementedmSingleton26) + - [Attribute `Name`](#AttributeName26.1) + - [Attribute `Type`](#AttributeType26.2) + - [Attribute `Nullable`](#AttributeNullable26.3) +- [Element `edm:NavigationPropertyBinding`](#ElementedmNavigationPropertyBinding27) + - [Attribute `Path`](#AttributePath27.1) + - [Attribute `Target`](#AttributeTarget27.2) +- [Element `edm:ActionImport`](#ElementedmActionImport28) - [Attribute `Name`](#AttributeName28.1) - - [Attribute `Function`](#AttributeFunction28.2) + - [Attribute `Action`](#AttributeAction28.2) - [Attribute `EntitySet`](#AttributeEntitySet28.3) - - [Attribute `IncludeInServiceDocument`](#AttributeIncludeInServiceDocument28.4) -- [Element `edm:Term`](#ElementedmTerm29) +- [Element `edm:FunctionImport`](#ElementedmFunctionImport29) - [Attribute `Name`](#AttributeName29.1) - - [Attribute `Type`](#AttributeType29.2) - - [Attribute `DefaultValue`](#AttributeDefaultValue29.3) - - [Attribute `BaseTerm`](#AttributeBaseTerm29.4) - - [Attribute `AppliesTo`](#AttributeAppliesTo29.5) -- [Element `edm:Annotation`](#ElementedmAnnotation30) - - [Attribute `Term`](#AttributeTerm30.1) - - [Attribute `Qualifier`](#AttributeQualifier30.2) -- [Expression `edm:Binary`](#ExpressionedmBinary31) -- [Expression `edm:Bool`](#ExpressionedmBool32) -- [Expression `edm:Date`](#ExpressionedmDate33) -- [Expression `edm:DateTimeOffset`](#ExpressionedmDateTimeOffset34) -- [Expression `edm:Decimal`](#ExpressionedmDecimal35) -- [Expression `edm:Duration`](#ExpressionedmDuration36) -- [Expression `edm:EnumMember`](#ExpressionedmEnumMember37) -- [Expression `edm:Float`](#ExpressionedmFloat38) -- [Expression `edm:Guid`](#ExpressionedmGuid39) -- [Expression `edm:Int`](#ExpressionedmInt40) -- [Expression `edm:String`](#ExpressionedmString41) -- [Expression `edm:TimeOfDay`](#ExpressionedmTimeOfDay42) -- [Expression `edm:AnnotationPath`](#ExpressionedmAnnotationPath43) -- [Expression `edm:ModelElementPath`](#ExpressionedmModelElementPath44) -- [Expression `edm:NavigationPropertyPath`](#ExpressionedmNavigationPropertyPath45) -- [Expression `edm:PropertyPath`](#ExpressionedmPropertyPath46) -- [Expression `edm:Path`](#ExpressionedmPath47) -- [Expressions `edm:And`](#ExpressionsedmAnd48) - - [`edm:Or`](#edmOr48.1) -- [Expression `edm:Not`](#ExpressionedmNot49) -- [Expressions `edm:Eq`](#ExpressionsedmEq50) - - [`edm:Ne`](#edmNe50.1) - - [`edm:Gt`](#edmGt50.2) - - [`edm:Ge`](#edmGe50.3) - - [`edm:Lt`](#edmLt50.4) - - [`edm:Le`](#edmLe50.5) - - [`edm:Has`](#edmHas50.6) - - [`edm:In`](#edmIn50.7) -- [Expression `edm:Neg`](#ExpressionedmNeg51) -- [Expressions `edm:Add`](#ExpressionsedmAdd52) - - [`edm:Sub`](#edmSub52.1) - - [`edm:Mul`](#edmMul52.2) - - [`edm:Div`](#edmDiv52.3) - - [`edm:DivBy`](#edmDivBy52.4) - - [`edm:Mod`](#edmMod52.5) -- [Expression `edm:Apply`](#ExpressionedmApply53) - - [Attribute `Function`](#AttributeFunction53.1) -- [Expression `edm:Cast`](#ExpressionedmCast54) - - [Attribute `Type`](#AttributeType54.1) -- [Expression `edm:Collection`](#ExpressionedmCollection55) -- [Expression `edm:If`](#ExpressionedmIf56) -- [Expression `edm:UrlRef`](#ExpressionedmUrlRef57) -- [Expression `edm:LabeledElement`](#ExpressionedmLabeledElement58) - - [Attribute `Name`](#AttributeName58.1) -- [Expression `edm:LabeledElementReference`](#ExpressionedmLabeledElementReference59) -- [Expression `edm:Null`](#ExpressionedmNull60) -- [Expression `edm:Record`](#ExpressionedmRecord61) - - [Attribute `Type`](#AttributeType61.1) -- [Element `edm:PropertyValue`](#ElementedmPropertyValue62) - - [Attribute `Property`](#AttributeProperty62.1) -- [Expression `edm:UrlRef`](#ExpressionedmUrlRef63) + - [Attribute `Function`](#AttributeFunction29.2) + - [Attribute `EntitySet`](#AttributeEntitySet29.3) + - [Attribute `IncludeInServiceDocument`](#AttributeIncludeInServiceDocument29.4) +- [Element `edm:Term`](#ElementedmTerm30) + - [Attribute `Name`](#AttributeName30.1) + - [Attribute `Type`](#AttributeType30.2) + - [Attribute `Nullable`](#AttributeNullable30.3) + - [Attribute `DefaultValue`](#AttributeDefaultValue30.4) + - [Attribute `BaseTerm`](#AttributeBaseTerm30.5) + - [Attribute `AppliesTo`](#AttributeAppliesTo30.6) +- [Element `edm:Annotation`](#ElementedmAnnotation31) + - [Attribute `Term`](#AttributeTerm31.1) + - [Attribute `Qualifier`](#AttributeQualifier31.2) +- [Expression `edm:Binary`](#ExpressionedmBinary32) +- [Expression `edm:Bool`](#ExpressionedmBool33) +- [Expression `edm:Date`](#ExpressionedmDate34) +- [Expression `edm:DateTimeOffset`](#ExpressionedmDateTimeOffset35) +- [Expression `edm:Decimal`](#ExpressionedmDecimal36) +- [Expression `edm:Duration`](#ExpressionedmDuration37) +- [Expression `edm:EnumMember`](#ExpressionedmEnumMember38) +- [Expression `edm:Float`](#ExpressionedmFloat39) +- [Expression `edm:Guid`](#ExpressionedmGuid40) +- [Expression `edm:Int`](#ExpressionedmInt41) +- [Expression `edm:String`](#ExpressionedmString42) +- [Expression `edm:TimeOfDay`](#ExpressionedmTimeOfDay43) +- [Expression `edm:AnnotationPath`](#ExpressionedmAnnotationPath44) +- [Expression `edm:ModelElementPath`](#ExpressionedmModelElementPath45) +- [Expression `edm:NavigationPropertyPath`](#ExpressionedmNavigationPropertyPath46) +- [Expression `edm:PropertyPath`](#ExpressionedmPropertyPath47) +- [Expression `edm:Path`](#ExpressionedmPath48) +- [Expressions `edm:And`](#ExpressionsedmAnd49) + - [`edm:Or`](#edmOr49.1) +- [Expression `edm:Not`](#ExpressionedmNot50) +- [Expressions `edm:Eq`](#ExpressionsedmEq51) + - [`edm:Ne`](#edmNe51.1) + - [`edm:Gt`](#edmGt51.2) + - [`edm:Ge`](#edmGe51.3) + - [`edm:Lt`](#edmLt51.4) + - [`edm:Le`](#edmLe51.5) + - [`edm:Has`](#edmHas51.6) + - [`edm:In`](#edmIn51.7) +- [Expression `edm:Neg`](#ExpressionedmNeg52) +- [Expressions `edm:Add`](#ExpressionsedmAdd53) + - [`edm:Sub`](#edmSub53.1) + - [`edm:Mul`](#edmMul53.2) + - [`edm:Div`](#edmDiv53.3) + - [`edm:DivBy`](#edmDivBy53.4) + - [`edm:Mod`](#edmMod53.5) +- [Expression `edm:Apply`](#ExpressionedmApply54) + - [Attribute `Function`](#AttributeFunction54.1) +- [Expression `edm:Cast`](#ExpressionedmCast55) + - [Attribute `Type`](#AttributeType55.1) +- [Expression `edm:Collection`](#ExpressionedmCollection56) +- [Expression `edm:If`](#ExpressionedmIf57) +- [Expression `edm:UrlRef`](#ExpressionedmUrlRef58) +- [Expression `edm:LabeledElement`](#ExpressionedmLabeledElement59) + - [Attribute `Name`](#AttributeName59.1) +- [Expression `edm:LabeledElementReference`](#ExpressionedmLabeledElementReference60) +- [Expression `edm:Null`](#ExpressionedmNull61) +- [Expression `edm:Record`](#ExpressionedmRecord62) + - [Attribute `Type`](#AttributeType62.1) +- [Element `edm:PropertyValue`](#ElementedmPropertyValue63) + - [Attribute `Property`](#AttributeProperty63.1) +- [Expression `edm:UrlRef`](#ExpressionedmUrlRef64) ::: ------- 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. 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
    -

    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.

    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.

    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 8805c7dd6..aeea5a236 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:

      @@ -416,10 +416,10 @@

      4.1 Header Content-Type

      Requests and responses with a JSON message body MUST have a Content-Type header value of application/json.

      -

      Requests MAY add the 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.

      +

      Requests MAY add the 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.

      Responses MUST include the 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:

        @@ -517,6 +517,7 @@

        type control information to specify the numeric type of the property.
      • String values do have a first class representation in JSON, but there is an obvious collision: OData also encodes a number of other primitive types as strings, e.g. DateTimeOffset, Int64 in the presence of the IEEE754Compatible format parameter etc. If a property appears in JSON string format, it should be treated as a string value unless the property is known (from the metadata document) to have a different type.
      +

      The type control information can be absent in properties nested in an instance of type Edm.Untyped. In particular, individual primitive values within a collection cannot have type control information.

      For more information on namespace- and alias-qualified names, see OData-CSDLJSON or OData-CSDLXML.

      Example 5: entity of type Model.VipCustomer defined in the metadata document of the same service with a dynamic property of type Edm.Date

      @@ -530,7 +531,7 @@

      }

    -

    Example 6: entity of type Model.VipCustomer defined in the metadata document of a different service

    +

    Example 6: entity of type Model.VipCustomer defined in the metadata document of a different service

    {
       "@context": "http://host/service/$metadata#Customers/$entity",
       "@type": "http://host/alternate/$metadata#Model.VipCustomer",
    @@ -592,7 +593,7 @@ 
     

    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.

    @@ -801,6 +802,7 @@

    "EmailAddresses@nextLink": "..." }

    +

    A collection of primitive values that occurs in a property of type Edm.Untyped is interpreted as a collection of Edm.Boolean, Edm.String, and Edm.Decimal values, depending on the JavaScript type.

    7.4 Collection of Complex Values

    A collection of complex values is represented as a JSON array; each element in the array is the representation of a complex value. A JSON literal null represents a null value within the collection. An empty collection is represented as an empty array.

    @@ -822,7 +824,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 +926,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
    @@ -974,7 +976,7 @@ 

    9 Str

    See OData-Protocol for details on the system query options $select and $expand.

    Depending on the metadata level, the stream property MAY be annotated to provide the read link, edit link, media type, and ETag of the media stream through their media* control information.

    -

    If the actual stream data is included inline, the control information mediaContentType MUST be present to indicate how the included stream property value is represented. Stream property values of media type application/json or one of its subtypes, optionally with format parameters, are represented as native JSON. Values of top-level type text, for example text/plain, are represented as a string, with JSON string escaping rules applied. Included stream data of other media types is represented as a base64url-encoded string value, see RFC4648, section 5.

    +

    If the actual stream data is included inline, the control information mediaContentType MUST be present to indicate how the included stream property value is represented. Stream property values of media type application/json or one of its subtypes, optionally with format parameters, are represented as native JSON. Values of top-level type text with an explicit or default charset of utf-8 or us-ascii, for example text/plain, are represented as a string, with JSON string escaping rules applied. Included stream data of other media types is represented as a base64url-encoded string value, see RFC4648, section 5.

    If the included stream property has no value, the non-existing stream data is represented as null and the control information mediaContentType is not necessary.

    Example 24:

    @@ -1062,7 +1064,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 +1103,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 +1115,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. -
    3. Order 10643 was removed from customer 'ALFKI'
    4. -
    5. Order 10645 was added to customer 'BOTTM'
    6. +
    7. ContactName for customer BOTTM was changed to Susan Halvenstern
    8. +
    9. Order 10643 was removed from customer ALFKI
    10. +
    11. Order 10645 was added to customer BOTTM
    12. The shipping information for order 10643 was updated
    13. -
    14. Customer 'ANTON' was deleted
    15. +
    16. Customer ANTON was deleted
    {
       "@context": "http://host/service/$metadata#Customers/$delta",
    @@ -1164,7 +1166,7 @@ 

    entities.

    Added entities MUST include all available selected properties and MAY include additional, unselected properties. Collection-valued properties are treated as atomic values; any collection-valued properties returned from a delta request MUST contain all current values for that collection.

    Changed entities MUST include all available selected properties that have changed, and MAY include additional properties.

    -

    If a property of an entity is dependent upon the property of another entity within the expanded set of entities being tracked, then both the change to the dependent property as well as the change to the principle property or added/deleted link corresponding to the change to the dependent property are returned in the delta response.

    +

    If a property of an entity is dependent upon the property of another entity within the expanded set of entities being tracked, then both the change to the dependent property as well as the change to the principal property or added/deleted link corresponding to the change to the dependent property are returned in the delta response.

    Entities that are not part of the entity set specified by the context URL MUST include the context control information to specify the entity set of the entity, regardless of the specified metadata value.

    Entities include control information for selected navigation links based on metadata.

    OData 4.0 payloads MUST NOT include expanded navigation properties inline; all changes MUST be represented as a flat array of added, deleted, or changed entities, along with added or deleted links.

    @@ -1173,16 +1175,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. +
      3. ContactName was changed to Susan Halvenstern
      4. Order 10645 was added
    3. -
    4. Customer 'ALFKI': +
    5. Customer ALFKI:
      1. Order 10643 was removed
    6. -
    7. Customer 'ANTON' was deleted
    8. +
    9. Customer ANTON was deleted
    {
       "@context": "http://host/service/$metadata#Customers/$delta",
    @@ -1238,15 +1240,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 +1258,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 +1286,9 @@

    Deleted links within a delta response are represented as deleted-link objects.

    @@ -1297,28 +1299,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 collection-update request for customers with expanded orders represented inline as a delta

      -
    1. Add customer 'EASTC'
    2. -
    3. Change ContactName of customer 'AROUT'
    4. -
    5. Delete customer 'ANTON'
    6. -
    7. Change customer 'ALFKI': +
    8. Add customer EASTC
    9. +
    10. Change ContactName of customer AROUT
    11. +
    12. Delete customer ANTON
    13. +
    14. Change customer ALFKI:
      1. Create order 11011
      2. Add link to existing order 10692
      3. Change RequiredDate of related order 10835
      4. Delete link to order 10643
    15. -
    16. Add link between customer 'ANATR' and order 10643
    17. -
    18. Delete link between customer 'DUMON' and order 10311
    19. +
    20. Add link between customer ANATR and order 10643
    21. +
    22. Delete link between customer DUMON and order 10311
    PATCH /service/Customers HTTP/1.1
     Host: host
    @@ -1400,18 +1402,18 @@ 

    -
  • Add customer 'EASTC' - failed
  • -
  • Change ContactName of customer 'AROUT' - failed
  • -
  • Delete customer 'ANTON' - failed
  • -
  • Change customer 'ALFKI': +
  • Add customer ‘EASTC’ - failed
  • +
  • Change ContactName of customer ‘AROUT’ - failed
  • +
  • Delete customer ‘ANTON’ - failed
  • +
  • Change customer ‘ALFKI’:
    1. Create order 11011 - succeeded, not mentioned in response
    2. Add link to existing order 10692 - succeeded, not mentioned in response
    3. Change RequiredDate of related order 10835 - failed
    4. Delete link to order 10643 - succeeded, not mentioned in response
  • -
  • Add link between customer 'ANATR' and order 10643 - failed without further info
  • -
  • Delete link between customer 'DUMON' and order 10311 - failed without further info
  • +
  • Add link between customer ‘ANATR’ and order 10643 - failed without further info
  • +
  • Delete link between customer ‘DUMON’ and order 10311 - failed without further info
  • HTTP/1.1 200 OK
     Content-Type: application/json
    @@ -1655,7 +1657,7 @@ 

    19.1 Batc

    Note: the id name/value pair corresponds to the Content-ID header in the multipart batch format specified in OData-Protocol.

    The value of method is a string that MUST contain one of the literals delete, get, patch, post, or put. These literals are case-insensitive.

    The value of url is a string containing the individual request URL. The URL MAY be an absolute path (starting with a forward slash /) which is appended to scheme, host, and port of the batch request URL, or a relative path (not starting with a forward slash /).

    -

    If the first segment of a relative path starts with a $ character and is not identical to the name of a top-level system resource ($batch, $crossjoin, $all, $entity, $root, $id, $metadata, or other system resources defined according to the OData-Version of the protocol specified in the request), then this first segment is replaced with the URL of the entity created by or returned from a preceding request whose id value is identical to the value of the first segment with the leading $ character removed. The id of this request MUST be specified in the dependsOn name/value pair.

    +

    If the first segment of a relative path starts with a $ character and is not identical to the name of a top-level system resource ($batch, $crossjoin, $all, $entity, $root, $id, $metadata, or other system resources defined according to the OData-Version of the protocol specified in the request), then this first segment is replaced with the URL of the entity created by or returned from a preceding request whose id value is identical to the value of the first segment with the leading $ character removed. The id of this request MUST be specified in the dependsOn name/value pair.

    Otherwise, the relative path is resolved relative to the batch request URL (i.e. relative to the service root).

    The value of atomicityGroup is a string whose content MUST NOT be identical to any value of id within the batch request, and which MUST satisfy the rule request-id in OData-ABNF. All request objects with the same value for atomicityGroup MUST be adjacent in the requests array. These requests are processed as an atomic operation and MUST either all succeed, or all fail.

    Note: the atomicity group is a generalization of the change set in the multipart batch format specified in OData-Protocol.

    @@ -1726,7 +1728,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
    @@ -1925,7 +1927,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.

    @@ -1947,15 +1949,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.

    @@ -2113,49 +2115,47 @@

    [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
    -https://www.rfc-editor.org/info/rfc2119.

    +

    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”, STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005. https://www.rfc-editor.org/info/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, DOI 10.17487/RFC3987, January 2005. https://www.rfc-editor.org/info/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, DOI 10.17487/RFC4648, October 2006. https://www.rfc-editor.org/info/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, DOI 10.17487/RFC5646, September 2009. https://www.rfc-editor.org/info/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”, RFC 7493, DOI 10.17487/RFC7493, March 2015. https://www.rfc-editor.org/info/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.

    +

    Butler, H., Daly, M., Doyle, A., Gillies, S., Hagen, S., and T. Schaub, “The GeoJSON Format”, RFC 7946, DOI 10.17487/RFC7946, August 2016. https://www.rfc-editor.org/info/rfc7946.

    [RFC8174]
    -

    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.

    +

    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”, STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017. https://www.rfc-editor.org/info/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.

    @@ -2258,14 +2258,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 665a9bb98..31bf0799a 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 @@ -551,7 +551,7 @@ Requests and responses with a JSON message body MUST have a `Content-Type` header value of `application/json`. Requests MAY add the `charset` parameter to the content type. -Allowed values are `UTF-8`,` UTF-16`, and +Allowed values are `UTF-8`, `UTF-16`, and `UTF-32`. If no `charset` parameter is present, `UTF-8` MUST be assumed. @@ -854,6 +854,9 @@ information: should be treated as a string value unless the property is known (from the metadata document) to have a different type. +The `type` control information can be absent in properties nested in an instance of type `Edm.Untyped`. +In particular, individual primitive values within a collection cannot have `type` control information. + For more information on namespace- and alias-qualified names, see [OData-CSDLJSON](#ODataCSDL) or [OData-CSDLXML](#ODataCSDL). @@ -876,10 +879,8 @@ metadata document of the same service with a dynamic property of type ::: ::: example -Example 6: entity of type -`Model.VipCustomer` defined in the -metadata` `document of a different -service +Example 6: entity of type `Model.VipCustomer` defined in the +metadata document of a different service ```json { "@context": "http://host/service/$metadata#Customers/$entity", @@ -1479,6 +1480,10 @@ Example 14: partial collection of strings with next link ``` ::: +A collection of primitive values that occurs in a property of type `Edm.Untyped` +is interpreted as a collection of `Edm.Boolean`, `Edm.String`, and `Edm.Decimal` values, +depending on the JavaScript type. + ## 7.4 Collection of Complex Values A collection of complex values is represented as a JSON array; each @@ -1716,7 +1721,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. @@ -1808,7 +1813,8 @@ If the actual stream data is included inline, the control information MUST be present to indicate how the included stream property value is represented. Stream property values of media type `application/json` or one of its subtypes, optionally with format parameters, are represented -as native JSON. Values of top-level type `text`, for example +as native JSON. Values of top-level type `text` with an explicit or +default `charset` of `utf-8` or `us-ascii`, for example `text/plain`, are represented as a string, with JSON string escaping rules applied. Included stream data of other media types is represented as a base64url-encoded string value, see @@ -2121,11 +2127,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 { @@ -2187,7 +2193,7 @@ have changed, and MAY include additional properties. If a property of an entity is dependent upon the property of another entity within the expanded set of entities being tracked, then both the -change to the dependent property as well as the change to the principle +change to the dependent property as well as the change to the principal property or [added](#AddedLink)/[deleted link](#DeletedLink) corresponding to the change to the dependent property are returned in the delta response. @@ -2233,12 +2239,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 { @@ -2326,10 +2332,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) @@ -2339,12 +2345,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 { @@ -2384,7 +2390,7 @@ following properties, regardless of the specified from the response _or_ the entity-id is not identical to the canonical URL of the entity. For [ordered payloads](#PayloadOrderingConstraints), the control information - `id,` if present, MUST immediately follow the control + `id`, if present, MUST immediately follow the control information [`removed`](#ControlInformationremovedodataremoved). @@ -2439,13 +2445,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 @@ -2463,16 +2469,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`, @@ -2493,16 +2499,16 @@ entities, as well as [added](#AddedLink) or ::: example Example 39: 4.01 collection-update request for 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 `RequiredDate` 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 PATCH /service/Customers HTTP/1.1 Host: host @@ -3020,7 +3026,7 @@ batch request URL, or a relative path (not starting with a forward slash `/`). If the first segment of a relative path starts with a `$` character and is not identical to the name of a top-level system -resource (`$batch`, `$crossjoin,` `$all,` `$entity`, `$root,` +resource (`$batch`, `$crossjoin`, `$all`, `$entity`, `$root`, `$id`, `$metadata`, or other system resources defined according to the `OData-Version` of the protocol specified in the request), then this first segment is replaced with the @@ -3883,40 +3889,40 @@ _OData Vocabularies Version 4.0: Core Vocabulary._ See link in "[Related work](#RelatedWork)" 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", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005_. +https://www.rfc-editor.org/info/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, DOI 10.17487/RFC3987, January 2005_. +https://www.rfc-editor.org/info/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, DOI 10.17487/RFC4648, October 2006_. +https://www.rfc-editor.org/info/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, DOI 10.17487/RFC5646, September 2009_. +https://www.rfc-editor.org/info/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", RFC 7493, DOI 10.17487/RFC7493, March 2015_. +https://www.rfc-editor.org/info/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. +_Butler, H., Daly, M., Doyle, A., Gillies, S., Hagen, S., and T. Schaub, "The GeoJSON Format", RFC 7946, DOI 10.17487/RFC7946, August 2016_. +https://www.rfc-editor.org/info/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", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017_. +https://www.rfc-editor.org/info/rfc8259. ## A.2 Informative References ###### [ECMAScript] diff --git a/docs/odata-protocol/odata-protocol.html b/docs/odata-protocol/odata-protocol.html index 773770ccd..4aa3252fa 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

    @@ -306,7 +306,8 @@

    Table of Contents

  • 11.2.3 Requesting the Media Stream of a Media Entity using $value
  • 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).

    @@ -564,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.

    @@ -617,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

    @@ -645,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.

    @@ -656,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.

    @@ -673,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

    @@ -682,16 +683,16 @@

    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.

    +

    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.

    If present, the request MUST only be processed if the specified ETag value matches the current ETag value of the target resource. Services sending ETag headers with weak ETags that only depend on the representation-independent entity state MUST use the weak comparison function because it is sufficient to prevent accidental overwrites. This is a deviation from RFC7232.

    If the value does not match the current ETag value of the resource for a Data Modification Request or Action Request, the service MUST respond with 412 Precondition Failed and MUST ensure that no observable change occurs as a result of the request. In the case of an upsert, if the addressed entity does not exist the provided ETag value is considered not to match.

    An If-Match header with a value of * in a PUT or PATCH request results in an upsert request being processed as an update and not an insert.

    @@ -703,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.

    @@ -716,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.

    @@ -725,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.

    @@ -771,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.*"

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

    @@ -808,14 +809,14 @@

    RFC7240.

    In OData, return=representation or return=minimal is defined for use with a POST, PUT, or PATCH Data Modification Request, or with an Action Request. Specifying a preference of return=representation or return=minimal in a GET or DELETE request does not have any effect.

    A preference of return=representation or return=minimal is allowed on an individual Data Modification Request or Action Request within a batch, subject to the same restrictions, but SHOULD return a 4xx Client Error if specified on the batch request itself.

    -

    A preference of return=minimal requests that the service invoke the request but does not return content in the response. The service MAY apply this preference by returning 204 No Content in which case it MAY include a Preference-Applied response header containing the return=minimal preference.

    +

    A preference of return=minimal requests that the service invoke the request but does not return content in the response. The service MAY apply this preference by returning 204 No Content in which case it MAY include a Preference-Applied response header containing the return=minimal preference.

    A preference of return=representation requests that the service invokes the request and returns the modified resource. The service MAY apply this preference by returning the representation of the successfully modified resource in the body of the response, formatted according to the rules specified for the requested format. In this case the service MAY include a Preference-Applied response header containing the return=representation preference.

    The return preference SHOULD NOT be applied to a batch request, but MAY be applied to individual requests within a batch.

    8.2.8.8 Preference respond-async

    The respond-async preference, as defined in RFC7240, allows clients to request that the service process the request asynchronously.

    If the client has specified respond-async in the request, the service MAY process the request asynchronously and return a 202 Accepted response.

    The respond-async preference MAY be used for batch requests, in which case it applies to the batch request as a whole and not to individual requests within the batch request.

    -

    In the case that the service applies the respond-async preference it MUST include a Preference-Applied response header containing the respond-async preference.

    +

    In the case that the service applies the respond-async preference it MUST include a Preference-Applied response header containing the respond-async preference.

    A service MAY specify the support for the respond-async preference using an annotation with term Capabilities.AsynchronousRequestsSupported, see OData-VocCap.

    Example 9: a service receiving the following header might choose to respond

    @@ -885,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

    @@ -912,7 +913,7 @@

    9.3.1 Response Code 501 Not Implemented

    If the client requests functionality not implemented by the OData Service, the service responds with 501 Not Implemented and SHOULD include a response body describing the functionality not implemented.

    9.4 Error Response Body

    -

    The representation of an error response body is format-specific. It consists at least of the following information:

    +

    An error response body can be the result of a failure of OData processing or of the underlying infrastructure. An OData-specific error response (which can be recognized by the presence of the OData-Version header) is format-specific and consists at least of the following information:

    • code: required non-null, non-empty, language-independent string. Its value is a service-defined error code. This code serves as a sub-status for the HTTP error code specified in the response.
    • message: required non-null, non-empty, language-dependent, human-readable string describing the error. The Content-Language header MUST contain the language code from RFC5646 corresponding to the language in which the value for message is written.
    • @@ -926,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:

      @@ -1051,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
    @@ -1237,7 +1238,7 @@ 

    server-driven paging:

      -
    • $apply -- defined in OData-Aggregation
    • +
    • $apply — defined in OData-Aggregation
    • $compute
    • $search
    • $filter
    • @@ -1254,19 +1255,19 @@

      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.

      +

      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.

      If no entity exists with the specified request URL, the service responds with 404 Not Found.

      11.2.3 Requesting the Media Stream of a Media Entity using $value

      A media entity is an entity that represents an out-of-band stream, such as a photograph.

      Use a media entity if the out-of-band stream is the main topic of interest and the media entity is just structured additional information attached to the stream. Use a normal entity with one or more stream properties if the structured data of the entity is the main topic of interest and the stream data is just additional information attached to the structured data.

      -

      To address the media stream represented by a media entity, clients append /$value to the resource path of the media entity URL. Services may redirect from this canonical URL to the source URL of the media stream.

      -

      Appending /$value to an entity that is not a media entity returns 400 Bad Request.

      +

      To address the media stream represented by a media entity, clients append /$value to the resource path of the media entity URL. 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 media stream with that media type. Alternatively, services MAY redirect from this canonical URL to the source URL of the media stream.

      +

      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.

      @@ -1275,7 +1276,10 @@

      11.2.4.1 Requesting a Property's Raw Value using $value

      +

      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

      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.

      @@ -1283,6 +1287,7 @@

      OData-ABNF.

      A $value request for a property that is null results in a 204 No Content response.

      If the property is not available, for example due to permissions, the service responds with 404 Not Found.

      +

      Appending /$value to the property URL of a property of type Edm.Stream returns 400 Bad Request.

      Example 32:

      GET http://host/service/Products(1)/Name/$value
      @@ -1439,7 +1444,7 @@
      String Functions

    - + @@ -1475,10 +1480,10 @@
    11.2.6.1.3 Parameter Aliases
    -

    Parameter aliases can be used in place of literal values in entity keys, function parameters, or within a $compute, $filter or $orderby expression. Parameters aliases are names beginning with an at sign (@).

    +

    Parameter aliases can be used in place of literal values in entity keys, 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.

    @@ -1549,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

    @@ -1593,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.

    @@ -1668,19 +1673,19 @@

    GET http://host/service/Orders?$format=json

    is equivalent to a request with the 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.

    -

    In metadata document requests, 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.

    +

    In metadata document requests, 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.

    11.2.12 System Query Option $schemaversion

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

    The value of the $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.

    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.

    +

    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.

    +

    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.

    Delta links are opaque, service-generated links that the client uses to retrieve subsequent changes to a result.

    Delta links are based on a defining query that describes the set of results for which changes are being tracked; for example, the request that generated the results containing the delta link. The delta link encodes the collection of entities for which changes are being tracked, along with a starting point from which to track changes. OData services may use the reserved system query option $deltatoken when building delta links. Its content is opaque, service-specific, and must only follow the rules for URL query parts.

    @@ -1712,7 +1717,7 @@

    11.4.1.1 Use of ETags for Avoiding Update Conflicts

    Each entity has its own ETag value that MUST change when structural properties or links from that entity have changed. In addition, modifying, adding, or deleting a contained entity MAY change the ETag of the parent entity.

    Collections of entities (including collections of related entities) MAY have their own ETag value whose semantics is service-specific. It typically changes if entities are added to or removed from the collection, or if an entity in the collection is changed. The ETag of a collection of related entities reached via a navigation property MAY differ from the ETag of the entity containing the navigation property.

    -

    A Data Modification Request on an existing resource or an Action Request invoking an action bound to an existing resource MAY require optimistic concurrency control. Services SHOULD announce this via annotations with the terms Core.OptimisticConcurrency in OData-VocCore and Capabilities.NavigationRestrictions (nested property OptimisticConcurrencyControl) in OData-VocCap.

    +

    A Data Modification Request on an existing resource or an Action Request invoking an action bound to an existing resource MAY require optimistic concurrency control. Services SHOULD announce this via annotations with the terms Core.OptimisticConcurrency in OData-VocCore and Capabilities.NavigationRestrictions (nested property OptimisticConcurrencyControl) in OData-VocCap.

    If optimistic concurrency control is required for a resource, the service MUST include an ETag header in a response to a GET request to the resource, and MAY include the ETag in a format-specific manner in responses containing that resource.

    The presence of an ETag header in a response does not imply in itself that the resource requires optimistic concurrency control; the ETag may just be used for caching and/or conditional GET requests.

    If an ETag value is specified in an If-Match or If-None-Match header of a Data Modification Request or Action Request, the operation MUST only be invoked if the If-Match or If-None-Match condition is satisfied.

    @@ -1733,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.

    @@ -1779,21 +1784,21 @@ -

    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.

    +

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

    +

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

    -

    Updating a principle property that is tied to a dependent entity through a referential constraint on the dependent entity updates the dependent property.

    +

    Updating a principal property that is tied to a dependent entity through a referential constraint on the dependent entity updates the dependent property.

    Key and other properties marked as read-only in metadata (including computed properties), as well as dependent properties that are not tied to key properties of the principal entity, can be omitted from the request. If the request contains a value for one of these properties, the service MUST ignore that value when applying the update. Services MUST return an error if an insert or update contains a new value for a property marked as updatable that cannot currently be changed by the user (i.e., given the state of the object or permissions of the user). The service MAY return success in this case if the specified value matches the value of the property. Clients SHOULD use PATCH and specify only those properties intended to be changed.

    Entity id and entity type cannot be changed when updating an entity. However, format-specific rules might in some cases require providing entity id and entity type values in the payload when applying the update.

    For requests with an OData-Version header with a value of 4.01 or greater, if the entity representation in the request body includes an ETag value, the update MUST NOT be performed and SHOULD return 412 Precondition Failed if the supplied ETag value is not * and does not match the current ETag value for the entity. ETag values in request bodies MUST be ignored for requests containing an OData-Version header with a value of 4.0.

    @@ -1803,18 +1808,18 @@

    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.

    +

    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"
         },
         {
    @@ -1833,7 +1838,7 @@ 
    - + @@ -3191,7 +3214,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 (`@`). @@ -3203,7 +3226,7 @@ specified parameter alias. ::: example Example 48: returns all employees whose Region property matches the -string parameter value "WA" +string parameter value `WA` ``` GET http://host/service.svc/Employees?$filter=Region eq @p1&@p1='WA' ``` @@ -3405,7 +3428,7 @@ those items *matching* the specified search expression. The definition of what it means to match is dependent upon the implementation. ::: example -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 ``` @@ -3414,7 +3437,7 @@ GET http://host/service/Products?$search=bike The search expression can contain phrases, enclosed in double-quotes. ::: example -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" ``` @@ -3424,7 +3447,7 @@ The upper-case keyword `NOT` restricts the set of entities to those that do not match the specified term. ::: example -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 ``` @@ -3435,8 +3458,8 @@ Multiple terms within a search expression are separated by a space such terms must be matched. ::: example -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 ``` @@ -3446,8 +3469,8 @@ The upper-case keyword `OR` is used to return entities that satisfy either the immediately preceding or subsequent expression. ::: example -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 ``` @@ -3457,8 +3480,8 @@ Parentheses within the search expression group together multiple expressions. ::: example -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 ``` @@ -3736,7 +3759,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` @@ -3788,7 +3811,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 @@ -3797,7 +3820,7 @@ change-tracking. Clients request that the service track changes to a result by specifying the [`track-changes`](#Preferencetrackchangesodatatrackchanges) preference on a request. If supported for the request, the service includes a -[`Preference-Applied`](#HeaderPreferenceApplied)` `header in the +[`Preference-Applied`](#HeaderPreferenceApplied) 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. @@ -3960,7 +3983,7 @@ A [Data Modification Request](#DataModification) on an existing resource or an [Action Request](#Actions) invoking an action bound to an existing resource MAY require optimistic concurrency control. Services SHOULD announce this via annotations with the terms -[`Core.OptimisticConcurrency`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#OptimisticConcurrency)` `in +[`Core.OptimisticConcurrency`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#OptimisticConcurrency) in [OData-VocCore](#ODataVocCore) and [`Capabilities.NavigationRestrictions`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Capabilities.V1.md#NavigationRestrictions) (nested property `OptimisticConcurrencyControl`) in @@ -4188,7 +4211,7 @@ 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 +Media entities MUST contain the format-specific representation of their media stream as a virtual property `$value` when nested within a deep insert. @@ -4241,8 +4264,10 @@ 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. Missing -properties of the containing entity or complex property, including +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](#UpdateaComplexProperty). +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. @@ -4260,7 +4285,7 @@ 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 +the format-specific representation of the media stream as a virtual property `$value`. Updating a dependent property that is tied to a key property of the @@ -4268,7 +4293,7 @@ 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. -Updating a principle property that is tied to a dependent entity through +Updating a principal property that is tied to a dependent entity through a referential constraint on the dependent entity updates the dependent property. @@ -4349,17 +4374,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"     },     { @@ -4619,8 +4644,8 @@ entity. Upon successful completion the service responds with either [`201 Created`](#ResponseCode201Created), or -[`204 No Content`](#ResponseCode204NoContent)if the request included a -[Prefer header](#Preferencereturnrepresentationandreturnminimal) with a value of +[`204 No Content`](#ResponseCode204NoContent) if the request included a +[`Prefer` header](#Preferencereturnrepresentationandreturnminimal) with a value of [`return=minimal`](#Preferencereturnrepresentationandreturnminimal). #### 11.4.7.2 Update a Media Entity Stream @@ -4688,7 +4713,8 @@ Example 81: directly read a stream property of an entity ``` GET http://host/service/Products(1)/Thumbnail ``` -can return [`200 OK`](#ResponseCode200OK) and the stream data, or a [`3xx Redirect`](#ResponseCode3xxRedirection) to the media read link of the stream property. +can return [`200 OK`](#ResponseCode200OK) and the stream data (see [section 11.2.4.1](#RequestingStreamProperties)), +or a [`3xx Redirect`](#ResponseCode3xxRedirection) to the media read link of the stream property. ::: Note: for scenarios in which the media value can only be inlined, @@ -4802,11 +4828,15 @@ property to null. A successful `PATCH` request to the edit URL for a complex typed property updates that property. The request body MUST contain a single -valid representation for the target complex type. +valid representation for the declared type of the complex property or one of its derived types. The service MUST directly modify only those properties of the complex type specified in the payload of the `PATCH` request. +If a complex-typed property is set to a different type in a `PATCH` request, +properties shared through inheritance, as well as dynamic properties, are retained (unless overwritten by new values in the payload). +Other properties of the original type are discarded. + The service MAY additionally support clients sending a `PUT` request to a URL that specifies a complex type. In this case, the service MUST replace the entire complex property with the values specified in the @@ -5209,7 +5239,7 @@ particular instance by setting its value to null. ::: example Example 92: the `SampleEntities.MostRecentOrder` function is not -available for customer 'ALFKI' +available for customer `ALFKI` ```json {   "@context": ..., @@ -5248,7 +5278,7 @@ ampersand (`&`) or a question mark (`?`). Services MAY additionally support invoking functions using the unqualified function name by defining one or more [default namespaces](#DefaultNamespaces) through the -[`Core.DefaultNamespace`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#DefaultNamespace)` `term +[`Core.DefaultNamespace`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#DefaultNamespace) term defined in  [OData-VocCore](#ODataVocCore). Functions can be used within [`$filter`](#SystemQueryOptionfilter) or @@ -5287,6 +5317,10 @@ POST http://host/service/MyShoppingCart()/Items ``` ::: +If the function returns a value of type `Edm.Stream` and no additional path +segments follow the function invocation, the response to the `GET` request +follows the rules for [requesting stream properties](#RequestingStreamProperties). + Parameter values passed to functions MUST be specified either as a URL literal (for primitive values) or as a JSON formatted OData object (for complex values, or collections of primitive or complex values). Entity @@ -5332,8 +5366,8 @@ GET http://host/service/EmployeesByManager(ManagerID=3) ::: ::: example -Example 95: return all `Customers` whose City property returns -"Western" when passed to the `Sales.SalesRegion` function +Example 95: return all Customers whose `City` property returns +`Western` when passed to the `Sales.SalesRegion` function ``` GET http://host/service/Customers?       $filter=Sales.SalesRegion(City=$it/City) eq 'Western' @@ -5374,7 +5408,7 @@ GET http://host/service/EmployeesByManager?ManagerID=3 ::: Non-binding parameters annotated with the term -[`Core.OptionalParameter`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#OptionalParameter)` `defined +[`Core.OptionalParameter`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#OptionalParameter) defined in [OData-VocCore](#ODataVocCore) MAY be omitted. If it is annotated and the annotation specifies a `DefaultValue`, the omitted parameter is interpreted as having that default value. If omitted and the annotation @@ -5424,7 +5458,7 @@ request was ambiguous. ### 11.5.5 Actions Actions are operations exposed by an OData service that MAY have side -effects when invoked. Actions MAY return data but` `MUST NOT be further +effects when invoked. Actions MAY return data but MUST NOT be further composed with additional path segments. #### 11.5.5.1 Invoking an Action @@ -5443,7 +5477,7 @@ according to the particular format. Services MAY additionally support invoking actions using the unqualified action name by defining one or more [default namespaces](#DefaultNamespaces) through the -[`Core.DefaultNamespace`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#DefaultNamespace)` `term +[`Core.DefaultNamespace`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#DefaultNamespace) term defined in  [OData-VocCore](#ODataVocCore). To invoke an action through an action import, the client issues a `POST` @@ -5454,7 +5488,7 @@ values MUST be passed in the request body according to the particular format. Non-binding parameters that are nullable or annotated with the term -[`Core.OptionalParameter`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#OptionalParameter)` `defined +[`Core.OptionalParameter`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#OptionalParameter) defined in [OData-VocCore](#ODataVocCore) MAY be omitted from the request body. If an omitted parameter is not annotated (and thus nullable), it MUST be interpreted as having the `null` value. If it is annotated and the @@ -5484,6 +5518,9 @@ Actions that create and return a single entity follow the rules for header](#HeaderLocation) that contains the edit URL or read URL of the created entity. +If the action returns a value of type `Edm.Stream`, the response to the `POST` request +follows the rules for [requesting stream properties](#RequestingStreamProperties). + Actions without a return type respond with [`204 No Content`](#ResponseCode204NoContent) on success. @@ -5496,7 +5533,7 @@ collection response. ::: example Example 98: invoke the `SampleEntities.CreateOrder` action using -`/Customers('ALFKI') `as the customer (or binding parameter). The values +`Customers('ALFKI')` as the customer (or binding parameter). The values `2` for the `quantity` parameter and `BLACKFRIDAY` for the `discountCode` parameter are passed in the body of the request. Invoke the action only if the customer's ETag still matches. @@ -5713,7 +5750,7 @@ clients MUST be able to resolve it relative to the request's URL even if that contains such a reference. If the `$`-prefixed request identifier is identical to the name of a -top-level system resource (`$batch`, `$crossjoin,` `$all,` `$entity`, +top-level system resource (`$batch`, `$crossjoin`, `$all`, `$entity`, `$root`, `$id`, `$metadata`, or other system resources defined according to the [`OData-Version`](#HeaderODataVersion) of the protocol specified in the request), then the reference to the top-level system resource is @@ -5832,8 +5869,8 @@ need not be percent-encoded. Each body part that represents a single request MUST NOT include: -- `authentication` or `authorization` related HTTP headers -- `Expect`, `From`, `Max-Forwards`, `Range`, or `TE` headers +- `authentication` or `authorization` related HTTP headers +- `Expect`, `From`, `Max-Forwards`, `Range`, or `TE` headers Processors of batch requests MAY choose to disallow additional HTTP constructs in HTTP requests serialized within body parts. For example, a @@ -6022,7 +6059,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, @@ -6359,7 +6396,7 @@ unsupported functionality ([section 9.3.1](#ResponseCode501NotImplemented)) 4. MUST support casting to a derived type according to [OData-URL](#ODataURL) if derived types are present in the model 5. MUST support `$top` ([section 11.2.6.3](#SystemQueryOptiontop)) -6. MUST support `/$value` on media entities ([section 11.1.2](#MetadataDocumentRequest)) and individual properties ([section 11.2.4.1](#RequestingaPropertysRawValueusingvalue)) +6. MUST support `/$value` on media entities ([section 11.1.2](#MetadataDocumentRequest)) and individual properties ([section 11.2.4.2](#RequestingaPropertysRawValueusingvalue)) 7. MUST support `$filter` ([section 11.2.6.1](#SystemQueryOptionfilter)) 1. MUST support `eq`, `ne` filter operations on properties of entities in the requested entity set ([section 11.2.6.1.1](#BuiltinFilterOperations)) @@ -6405,13 +6442,13 @@ collection-valued properties (section 5.1.1.10 in [OData-URL](#ODataURL)) 6. MUST support the `$skip` system query option ([section 11.2.6.4](#SystemQueryOptionskip)) 7. MUST support the `$count` system query option ([section 11.2.6.5](#SystemQueryOptioncount)) -8. MUST support `$orderby` `asc` and `desc` on individual properties +8. MUST support `$orderby` with `asc` and `desc` on individual properties ([section 11.2.6.2](#SystemQueryOptionorderby)) 9. MUST support `$expand` ([section 11.2.5.2](#SystemQueryOptionexpand)) 1. MUST support returning references for expanded properties 2. MUST support `$filter` on expanded collection-valued properties 3. MUST support cast segment in expand with derived types - 4. SHOULD support `$orderby` `asc` and `desc` on expanded + 4. SHOULD support `$orderby` with `asc` and `desc` on expanded collection-valued properties 5. SHOULD support `$count` on expanded collection-valued properties 6. SHOULD support `$top` and `$skip` on expanded collection-valued @@ -6539,7 +6576,7 @@ Level](#OData401MinimalConformanceLevel) Level](#OData40IntermediateConformanceLevel) 3. MUST support `eq/ne null` comparison for navigation properties with a maximum cardinality of one -4. MUST support the [`in`](#BuiltinFilterOperations)` `operator +4. MUST support the [`in`](#BuiltinFilterOperations) operator 5. MUST support the `$select` option nested within `$select` 6. SHOULD support the count of a filtered collection in a common expression @@ -6564,7 +6601,7 @@ expression 4. MUST support `$compute` system query option 5. MUST support nested options in `$select` 1. MUST support `$filter` on selected collection-valued properties - 2. SHOULD support `$orderby` `asc` and `desc` on selected + 2. SHOULD support `$orderby` with `asc` and `desc` on selected collection-valued properties 3. SHOULD support the `$count` on selected collection-valued properties @@ -6683,50 +6720,47 @@ _OData Vocabularies Version 4.0: Core Vocabulary._ See link in "[Related work](#RelatedWork)" section on cover page. ###### [RFC2046] -_Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996_ -https://tools.ietf.org/html/rfc2046. +_Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996_. +https://www.rfc-editor.org/info/rfc2046. ###### [RFC2119] +_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. ###### [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, DOI 10.17487/RFC3987, January 2005_. +https://www.rfc-editor.org/info/rfc3987. ###### [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, DOI 10.17487/RFC5646, September 2009_. +https://www.rfc-editor.org/info/rfc5646. ###### [RFC5789] -_Dusseault, L., and J. Snell, "Patch Method for HTTP", RFC 5789, March 2010_ -http://tools.ietf.org/html/rfc5789. - -###### [RFC7493] -_Bray, T., Ed., "The I-JSON Message Format", RFC7493, March 2015_ -https://tools.ietf.org/html/rfc7493. +_Dusseault, L. and J. Snell, "PATCH Method for HTTP", RFC 5789, DOI 10.17487/RFC5789, March 2010_. +https://www.rfc-editor.org/info/rfc5789. ###### [RFC7230] -_Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014_ -https://tools.ietf.org/html/rfc7230. +_Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014_. +https://www.rfc-editor.org/info/rfc7230. ###### [RFC7231] -_Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014_ -https://tools.ietf.org/html/rfc7231. +_Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014_. +https://www.rfc-editor.org/info/rfc7231. ###### [RFC7232] -_Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 2014_ -https://tools.ietf.org/html/rfc7232. +_Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014_. +https://www.rfc-editor.org/info/rfc7232. ###### [RFC7240] -_Snell, J., "Prefer Header for HTTP", RFC 7240, June 2014_ -https://tools.ietf.org/html/rfc7240. +_Snell, J., "Prefer Header for HTTP", RFC 7240, DOI 10.17487/RFC7240, June 2014_. +https://www.rfc-editor.org/info/rfc7240. ###### [RFC7617] -_Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, September 2015_ -https://tools.ietf.org/html/rfc7617. +_Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015_. +https://www.rfc-editor.org/info/rfc7617. ###### [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. ## A.2 Informative References diff --git a/docs/odata-temporal-ext/odata-temporal-ext.html b/docs/odata-temporal-ext/odata-temporal-ext.html index d9960b80f..799613a7b 100644 --- a/docs/odata-temporal-ext/odata-temporal-ext.html +++ b/docs/odata-temporal-ext/odata-temporal-ext.html @@ -150,12 +150,12 @@

    Abstract:

    This specification defines how to represent and interact with time-dependent data using the Open Data Protocol (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-Temporal-v4.0]

    @@ -163,7 +163,7 @@

    Citation format:

    Notices

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

    @@ -251,32 +251,32 @@

    1.2 Glossary

    1.2.1 Definitions of Terms

    1.2.1.1 Application Time

    -

    Application time is used to describe data that is known to change over time, for example the budget of a department, or which department an employee works for. Application time may capture planned changes in the future, for example transferring an employee to a new department next month or capturing next year's budget for a department. Both future and past data can be changed.

    +

    Application time is used to describe data that is known to change over time, for example the budget of a department, or which department an employee works for. Application time may capture planned changes in the future, for example transferring an employee to a new department next month or capturing next year’s budget for a department. Both future and past data can be changed.

    1.2.1.2 System Time

    -

    System time is used to record when data became known by the "system of record". System time does not extend into the future, and record entries are only added and are never changed.

    -

    System time is never manipulated directly, and typically not visible in APIs, except for "last changed at" time stamps, and the corresponding properties are read-only.

    +

    System time is used to record when data became known by the “system of record”. System time does not extend into the future, and record entries are only added and are never changed.

    +

    System time is never manipulated directly, and typically not visible in APIs, except for “last changed at” time stamps, and the corresponding properties are read-only.

    As system time is typically not visible in APIs, we do not consider this in the remainder of this document.

    1.2.1.3 Temporal Object

    A temporal object is a set of data whose change over time is tracked by the service as a sequence of time slices.

    1.2.1.4 Time Slice

    A piece of temporal data with attached time period, documenting that the data did not change during this time period.

    Time slices for the same temporal object are non-overlapping, so for any given point in time there is at most one slice whose time period contains that point in time.

    -

    Time slices for a temporal object need not cover the complete timeline. There can be points in time for which no time slice exists, indicating that the object's values are not known to the service.

    +

    Time slices for a temporal object need not cover the complete timeline. There can be points in time for which no time slice exists, indicating that the object’s values are not known to the service.

    1.2.1.4.1 Closed-Open Semantics

    Time slices typically use closed-open semantics, following [SQL:2011]. This means the start is part of the period, the end is not part of the period, and for directly adjacent time slices the end of the earlier time slice is identical to the start of the next time slice. The period start must be less than the period end.

    1.2.1.4.2 Closed-Closed Semantics

    Some software systems predating the availability of temporal databases and with data type date for the application-time period start and end use closed-closed semantics. Temporal services on top of these systems can either convert their period end boundaries on-the-fly by adding one day on the way out and subtracting one day on the way in, or alternatively express the used time slice semantics via annotations.

    1.2.1.5 Snapshot Entity Set

    -

    An entity in a snapshot entity set represents a temporal object at a specified point in time. When the entity is addressed via a resource path (directly or via related resources), the point in time must be specified, see section "Propagation of Temporal Query Options" for details on how to determine this point in time.

    -

    The entity's id and its canonical URL are independent of this point in time. Hence, they are sufficient to reference the entity but not address it. In other words: the entity can be considered a function that maps each point in time to an instance of the entity type. That function can be referenced but only its values can be addressed.

    +

    An entity in a snapshot entity set represents a temporal object at a specified point in time. When the entity is addressed via a resource path (directly or via related resources), the point in time must be specified, see section “Propagation of Temporal Query Options” for details on how to determine this point in time.

    +

    The entity’s id and its canonical URL are independent of this point in time. Hence, they are sufficient to reference the entity but not address it. In other words: the entity can be considered a function that maps each point in time to an instance of the entity type. That function can be referenced but only its values can be addressed.

    Without a point in time, statements about individual structural or navigation properties of the entity or even about its existence cannot be made, and change tracking is not possible.

    Snapshot entity sets MUST be annotated with a Timeline of type TimelineSnapshot.

    1.2.1.6 Timeline Entity Set

    An entity in a timeline entity set represents one time slice of a temporal object, and all time slices of that temporal object are part of the entity set.

    -

    The entity's id and its canonical URL depend on the period of application time of the corresponding time slice. Referencing and addressing the entity are equivalent concepts, unlike in the snapshot case.

    +

    The entity’s id and its canonical URL depend on the period of application time of the corresponding time slice. Referencing and addressing the entity are equivalent concepts, unlike in the snapshot case.

    The response to a time-range request need not reflect the time-slice cut of the underlying data model.

    Services MAY condense/defragment adjacent time slices that do not differ in represented properties other than the period boundaries. This reduces the payload size, and it also avoids potential information leakage if the service only publishes a projection of the underlying data model.

    -

    Services MAY also split time slices to align their boundaries with nested expanded time slices to represent a "coarsest common slicing" across an expand tree.

    +

    Services MAY also split time slices to align their boundaries with nested expanded time slices to represent a “coarsest common slicing” across an expand tree.

    Timeline entity sets MUST be annotated with a Timeline of type TimelineVisible.

    1.2.2 Document Conventions

    Keywords defined by this specification use this monospaced font.

    @@ -289,7 +289,7 @@

    Here is a customized command line which will generate HTML from this markdown file (named odata-temporal-ext-v4.0-csd04.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-temporal-ext-v4.0-csd04.html
            -c styles/markdown-styles-v1.7.3b.css
    @@ -309,13 +309,13 @@ 

    2 Overview

  • When did or will something happen?
  • When did we learn that it happened?
  • -

    This leads to two "directions" or "dimensions" of time (measured as a date or date-plus-time value):

    +

    This leads to two “directions” or “dimensions” of time (measured as a date or date-plus-time value):

    • Application time, also called actual time, business time, effective time, or valid time, and
    • System time, also called recording time, audit time, or transaction time.
    -

    Keeping track of time is typically done by storing data together with the time period for which that data is deemed valid or effective, using separate periods for application time and system time, and the time periods are part of the logical key for "records". See [SQL:2011] or [Kulkarni] on how this is done in the SQL standard.

    -

    A consumer's perspective on this data can be different: even if time is tracked internally, the period of time may or may not be visible in a consumer's perspective, and even if visible the related properties are often not considered part of an entity's identity. For example, an employee is still the same person even after switching to another department.

    +

    Keeping track of time is typically done by storing data together with the time period for which that data is deemed valid or effective, using separate periods for application time and system time, and the time periods are part of the logical key for “records”. See [SQL:2011] or [Kulkarni] on how this is done in the SQL standard.

    +

    A consumer’s perspective on this data can be different: even if time is tracked internally, the period of time may or may not be visible in a consumer’s perspective, and even if visible the related properties are often not considered part of an entity’s identity. For example, an employee is still the same person even after switching to another department.

    The goals of this extension are:

  • Records of type TimelineVisible MAY specify the property ObjectKey.
      @@ -1410,12 +1410,12 @@

      now() with period start and end of type Edm.Date.

      +

      Note that there is no literal for “today” as clients and services can be in different time zones and thus can have different notions of which date is “today”. Clients are advised to use concrete temporal values and should avoid using the URL function now() with period start and end of type Edm.Date.

      Note that services may allow service-defined functions for temporal expressions, for example to deal with fiscal years in a particular company.

      4.2 Querying Temporal Data

      Temporal query options allow point-in-time as well as time-range queries. They take a temporal expression as their argument whose result type MUST match the type of the corresponding time period start and end.

      Adding temporal query options to a request does not alter the response shape, it only affects the returned data.

      -

      Temporal query options can be used with data modification operations, in which case they do not alter the modification semantics of the request, they only affect the response. That is, they only influence the "implicit GET" after successful data modification.

      +

      Temporal query options can be used with data modification operations, in which case they do not alter the modification semantics of the request, they only affect the response. That is, they only influence the “implicit GET” after successful data modification.

      If no temporal query options are specified,

      • timeline entity sets return all time slices, and
      • @@ -1430,7 +1430,7 @@

        $at nested within $expand
      • by a $at value propagated along $expand
      • by $at in the query option part of the request URL, which applies to every segment of the resource path and paths that occur in system query options
      • -
      • by the default value "now" - the logic for determining this value is service-specific
      • +
      • by the default value “now” — the logic for determining this value is service-specific
      • For entities in a timeline entity set the time interval for filtering time slices is determined by the first applicable rule:

          @@ -1470,7 +1470,7 @@

          4.2.2

          Example 11: retrieve multiple employees at a past point in time

          GET /api-1/Employees?$filter=contains(Name,'i')&$at=2012-01-01
          -

          results in one time slice for each employee matching the filter at the specified point in time - note that E401 back then does not satisfy this condition

          +

          results in one time slice for each employee matching the filter at the specified point in time — note that E401 back then does not satisfy this condition

          {
             "@odata.context": "$metadata#Employees",
             "value": [
          @@ -1532,7 +1532,7 @@ 

          $from=<point-in-time>&$toInclusive=<point-in-time>

          -

          The result is restricted to time slices whose application-time period overlaps with the interval defined by the query option values, taking the closed-open or closed-closed semantics of the entity set's time slices into account. The benefit of the query options is that the client does not have to inspect the temporal annotations to determine the property names of the period boundaries, the period semantics, and get all comparison operators right.

          +

          The result is restricted to time slices whose application-time period overlaps with the interval defined by the query option values, taking the closed-open or closed-closed semantics of the entity set’s time slices into account. The benefit of the query options is that the client does not have to inspect the temporal annotations to determine the property names of the period boundaries, the period semantics, and get all comparison operators right.

          For timeline entity sets with closed-open semantics $from=<start>&$to=<end> is shorthand for

          4.2.4 Interaction with Standard System Query Options

          -

          For snapshot entity sets the point in time for representing data is determined following the rules in section "Propagation of Temporal Query Options" and evaluated first, then all other system query options are evaluated on the data valid at that point in time, including the query option $apply defined in OData-Aggregation.

          -

          For timeline entity sets the interval for filtering data is determined following the rules in section "Propagation of Temporal Query Options" and evaluated as an additional criterion for $filter in the evaluation sequence defined in OData-Protocol, section "System Query Options", which is evaluated after the query option $apply.

          +

          For snapshot entity sets the point in time for representing data is determined following the rules in section “Propagation of Temporal Query Options” and evaluated first, then all other system query options are evaluated on the data valid at that point in time, including the query option $apply defined in OData-Aggregation.

          +

          For timeline entity sets the interval for filtering data is determined following the rules in section “Propagation of Temporal Query Options” and evaluated as an additional criterion for $filter in the evaluation sequence defined in OData-Protocol, section “System Query Options”, which is evaluated after the query option $apply.

          Example 16: retrieve employee history over a period of application time and filter on job title

          GET /api-2/Employees?$expand=history(
          @@ -1739,7 +1739,7 @@ 

            ] }

          -

          The lambda operators any() and all() are not influenced by temporal query options, they are interpreted for each time slice on the filtered collection, meaning "any related time slice satisfying the lambda expression" and "all related time slices satisfy the lambda expression". The lambda expressions however can contain sub-expressions working on the period boundaries.

          +

          The lambda operators any() and all() are not influenced by temporal query options, they are interpreted for each time slice on the filtered collection, meaning “any related time slice satisfying the lambda expression” and “all related time slices satisfy the lambda expression”. The lambda expressions however can contain sub-expressions working on the period boundaries.

          Example 17: filter employees on their name at any point in time

          GET /api-2/Employees?$expand=history($select=Name,Jobtitle)
          @@ -1778,7 +1778,7 @@ 

          4.3.1 Direct Modification of Time Slices

          -

          The temporal query options $at, $from and $to/$toInclusive can be used with data modification operations, in which case they do not alter the modification semantics of the request, they only affect the response of the "implicit GET" after the data modification.

          +

          The temporal query options $at, $from and $to/$toInclusive can be used with data modification operations, in which case they do not alter the modification semantics of the request, they only affect the response of the “implicit GET” after the data modification.

          Modification of time slices SHOULD be done with the temporal actions defined in the next section and its subsections.

          This specification does not define the behavior of standard insert, update, upsert, or delete requests on temporal entity sets, and potential side-effects of direct modification requests to period boundaries and adjacent time slices are beyond the scope of this specification as the underlying business logic will vary from service to service.

          4.3.2 Operations on Temporal Objects

          @@ -1799,15 +1799,15 @@

          UnitOfTime of the collection. In particular, ClosedClosedPeriods governs whether the period end of type Edm.Date is the last day in the period or the first day after the period. The upper period boundary for items in deltaTimeslices need not be supplied; if it has no declared default value, it defaults to max.

          This works identical to the SQL statement UPDATE FOR PORTION OF:

            -
          1. The "delta time slices" in deltaTimeslices are processed in the order of the collection.
          2. +
          3. The “delta time slices” in deltaTimeslices are processed in the order of the collection.
          4. For each delta time slice all time slices from the bound collection are selected whose temporal object key values are identical to the values of corresponding properties present in the delta time slice, and whose application-time period overlaps with the period of the delta time slice.
          5. -
          6. Selected time slices whose period is not fully included in the period of the delta time slice are split into two or three consecutive time slices, one with fully included period, and one or two with a non-overlapping period immediately before or after the delta time slice's period.
          7. +
          8. Selected time slices whose period is not fully included in the period of the delta time slice are split into two or three consecutive time slices, one with fully included period, and one or two with a non-overlapping period immediately before or after the delta time slice’s period.
          9. Then all fully included time slices (including ones created in the previous step) are updated following the rules for updating entities specified in OData-Protocol.
          10. Gaps between selected time slices in the period to update are not affected.

          On success it returns the created or updated time slices.

          -

          Example 18: Change a department's budget during a period of application time with api-2 (visible timeline)

          +

          Example 18: Change a department’s budget during a period of application time with api-2 (visible timeline)

          POST /api-2/Departments('D08')/history/Temporal.Update
           Content-Type: application/json
           
          @@ -1949,7 +1949,7 @@ 

          -

          Example 19: Change an employee's job title during a period of application time with api-1 (snapshot). Note that the period boundaries are not visible in api-1 and are provided as PeriodStart and PeriodEnd next to the Timeslice data. The PeriodEnd is omitted, meaning the end of application time.

          +

          Example 19: Change an employee’s job title during a period of application time with api-1 (snapshot). Note that the period boundaries are not visible in api-1 and are provided as PeriodStart and PeriodEnd next to the Timeslice data. The PeriodEnd is omitted, meaning the end of application time.

          POST /api-1/Employees/Temporal.Update
           Content-Type: application/json
            
          @@ -2240,7 +2240,7 @@ 

          UnitOfTime of the collection. In particular, ClosedClosedPeriods governs whether the period end of type Edm.Date is the last day in the period or the first day after the period.

          This works identical to the SQL statement DELETE FOR PORTION OF:

            -
          1. The "delta time slices" in deltaTimeslices are processed in the order of the collection.
          2. +
          3. The “delta time slices” in deltaTimeslices are processed in the order of the collection.
          4. For each delta time slice all time slices from the bound collection are selected whose temporal object key values are identical to the values of corresponding properties present in the delta time slice, and whose application-time period overlaps with the period of the delta time slice.
          5. Selected time slices whose period is not fully included in the period of the delta time slice are split into two consecutive time slices, one with non-overlapping, and one with fully included period.
          6. Then all fully included time slices (including ones created in the previous step) are deleted following the rules for deleting entities specified in OData-Protocol.
          7. @@ -2264,45 +2264,45 @@

            [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-Aggregation]

            OData Extension for Data Aggregation Version 4.0.
            -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.

            [OData-VocTemporal]

            OData Temporal Vocabulary.
            -See link in "Additional artifacts" section on cover page.

            +See link in “Additional artifacts” 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.

            A.2 Informative References

            [Fowler]
            -

            Martin Fowler, "Temporal Patterns", 16 February 2005
            +

            Martin Fowler, “Temporal Patterns”, 16 February 2005
            http://martinfowler.com/eaaDev/timeNarrative.html.

            [Kulkarni]
            -

            Krishna Kulkarni, "Temporal Features in SQL standard", September 2012
            +

            Krishna Kulkarni, “Temporal Features in SQL standard”, September 2012
            https://dbs.uni-leipzig.de/file/Temporal%20features%20in%20SQL2011.pdf.

            [Snodgrass]
            -

            Richard T. Snodgrass, "Developing Time-Oriented Database Applications in SQL", Morgan Kaufmann Publishers, Inc., San Francisco, July, 1999, ISBN 1-55860-436-7
            +

            Richard T. Snodgrass, “Developing Time-Oriented Database Applications in SQL”, Morgan Kaufmann Publishers, Inc., San Francisco, July, 1999, ISBN 1-55860-436-7
            http://www2.cs.arizona.edu/people/rts/tdbbook.pdf and http://www2.cs.arizona.edu/people/rts/pp30-31.pdf.

            [SQL:2011]

            ISO/IEC 9075-2:2011 Information technology - Database languages - SQL - Part 2: Foundation (SQL/Foundation).

            @@ -2428,14 +2428,14 @@

            Appendix D. 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-temporal-ext/odata-temporal-ext.md b/docs/odata-temporal-ext/odata-temporal-ext.md index 3c033c901..885e29c74 100644 --- a/docs/odata-temporal-ext/odata-temporal-ext.md +++ b/docs/odata-temporal-ext/odata-temporal-ext.md @@ -69,7 +69,7 @@ This specification defines how to represent and interact with time-dependent dat #### 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-temporal-ext-v4.0-csd04.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-temporal-ext-v4.0-csd04.html -c styles/markdown-styles-v1.7.3b.css @@ -1476,7 +1476,7 @@ applicable rule: 2. by a [`$at`](#QueryOptionat) value propagated along `$expand` 3. by [`$at`](#QueryOptionat) in the query option part of the request URL, which applies to every segment of the resource path and paths that occur in system query options -4. by the default value "now" - the logic for determining this value is service-specific +4. by the default value "now" --- the logic for determining this value is service-specific For entities in a [timeline entity set](#TimelineEntitySet) the time interval for filtering time slices is determined by the first @@ -1541,7 +1541,7 @@ Example 11: retrieve multiple employees at a past point in time GET /api-1/Employees?$filter=contains(Name,'i')&$at=2012-01-01 ``` results in one time slice for each employee matching the filter at the -specified point in time - note that E401 back then does not satisfy +specified point in time --- note that E401 back then does not satisfy this condition ```json { diff --git a/docs/odata-url-conventions/odata-url-conventions.html b/docs/odata-url-conventions/odata-url-conventions.html index 64222437b..a939a6207 100644 --- a/docs/odata-url-conventions/odata-url-conventions.html +++ b/docs/odata-url-conventions/odata-url-conventions.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 specification defines a set of recommended (but not required) rules for constructing URLs to identify the data and metadata exposed by an OData service as well as a set of reserved URL query string operators.

            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-Part2]

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

            @@ -258,7 +258,7 @@

            Table of Contents

    • 5.1.1.7 String Functions

      After applying these steps defined by RFC3986 the following steps MUST be performed:

        -
      • Split undecoded query at "&" into query options, and each query option at the first "=" into query option name and query option value
      • +
      • Split undecoded query at “&” into query options, and each query option at the first “=” into query option name and query option value
      • Percent-decode path segments, query option names, and query option values exactly once
      • Interpret path segments, query option names, and query option values according to OData rules
      @@ -474,17 +474,17 @@

      OData-ABNF.

      Below is a (non-normative) snippet from OData-ABNF:

      resourcePath = entitySetName                  [collectionNavigation]
      -             / singleton                      [singleNavigation]
      +             / singletonEntity                [singleNavigation]
                    / actionImportCall
                    / entityColFunctionImportCall    [ collectionNavigation ]
                    / entityFunctionImportCall       [ singleNavigation ]
                    / complexColFunctionImportCall   [ collectionPath ]
                    / complexFunctionImportCall      [ complexPath ]
                    / primitiveColFunctionImportCall [ collectionPath ]
      -             / primitiveFunctionImportCall    [ singlePath ]
      -             / functionImportCallNoParens
      -             / crossjoin
      -             / '$all'                         [ "/" qualifiedEntityTypeName ]
      + / primitiveFunctionImportCall [ primitivePath ] + / functionImportCallNoParens [ querySegment ] + / crossjoin [ querySegment ] + / %s"$all" [ "/" optionallyQualifiedEntityTypeName ]

  • Since OData has a uniform composable URL syntax and associated rules there are many ways to address a collection of entities, including, but not limited to:

    5.1.1.3 Grouping

    -

    The Grouping operator (open and close parenthesis "( )") controls the evaluation order of an expression. The Grouping operator returns the expression grouped inside the parenthesis.

    +

    The Grouping operator (open and close parenthesis “( )”) controls the evaluation order of an expression. The Grouping operator returns the expression grouped inside the parenthesis.

    Example 68: all products because 9 mod 3 is 0

    http://host/service/Products?$filter=(4 add 5) mod (4 sub 1) eq 0
    @@ -1079,7 +1079,7 @@
    5.1.1.5.2 cont

    The contains function with ordered collection parameter values returns true if the first collection can be transformed into the second collection by removing zero or more items from the beginning or the end of the first collection.

    The containsMethodCallExpr syntax rule defines how the contains function is invoked.

    -

    Example 70: all customers with a CompanyName that contains 'Alfreds'

    +

    Example 70: all customers with a CompanyName that contains Alfreds

    http://host/service/Customers?$filter=contains(CompanyName,'Alfreds')
    5.1.1.5.3 endswith
    @@ -1090,7 +1090,7 @@
    5.1.1.5.3 ends

    The endswith function with ordered collection parameter values returns true if the first collection can be transformed into the second collection by removing zero or more items from the beginning of the first collection.

    The endsWithMethodCallExpr syntax rule defines how the endswith function is invoked.

    -

    Example 71: all customers with a CompanyName that ends with 'Futterkiste'

    +

    Example 71: all customers with a CompanyName that ends with Futterkiste

    http://host/service/Customers?$filter=endswith(CompanyName,'Futterkiste')
    5.1.1.5.4 indexof
    @@ -1101,7 +1101,7 @@
    5.1.1.5.4 indexof

    The indexof function with ordered collection parameter values returns the zero-based index of the first occurrence of the second collection in the first collection, or -1 if the first collection does not contain the second collection.

    The indexOfMethodCallExpr syntax rule defines how the indexof function is invoked.

    -

    Example 72: all customers with a CompanyName containing 'lfreds' starting at the second character

    +

    Example 72: all customers with a CompanyName containing lfreds starting at the second character

    http://host/service/Customers?$filter=indexof(CompanyName,'lfreds') eq 1
    5.1.1.5.5 length
    @@ -1123,7 +1123,7 @@
    5.1.1.5.6 The startswith function with ordered collection parameter values returns true if the first collection can be transformed into the second collection by removing zero or more items from the end of the first collection.

    The startsWithMethodCallExpr syntax rule defines how the startswith function is invoked.

    -

    Example 74: all customers with a CompanyName that starts with 'Alfr'

    +

    Example 74: all customers with a CompanyName that starts with Alfr

    http://host/service/Customers?$filter=startswith(CompanyName,'Alfr')
    5.1.1.5.7 substring
    @@ -1141,11 +1141,11 @@
    5.1.1.5.7 s

    A negative start index N, if supported, returns a string/collection starting N characters/items before the end of the string/collection.

    The substringMethodCallExpr syntax rule defines how the substring function is invoked.

    -

    Example 75: all customers with a CompanyName of 'lfreds Futterkiste' once the first character has been removed

    +

    Example 75: all customers with a CompanyName of lfreds Futterkiste once the first character has been removed

    http://host/service/Customers?$filter=substring(CompanyName,1) eq 'lfreds Futterkiste'
    -

    Example 76: all customers with a CompanyName that has 'lf' as the second and third characters, e.g, 'Alfreds Futterkiste'

    +

    Example 76: all customers with a CompanyName that has lf as the second and third characters, e.g, Alfreds Futterkiste

    http://host/service/Customers?$filter=substring(CompanyName,1,2) eq 'lf'

    5.1.1.6 Collection Functions

    @@ -1192,20 +1192,20 @@
    5. hassubsequence([1,2],[1,1,2])

    5.1.1.7 String Functions

    -
    5.1.1.7.1 matchesPattern
    -

    The matchesPattern function has the following signature:

    -
    Edm.Boolean matchesPattern(Edm.String,Edm.String)
    -

    The second parameter MUST evaluate to a string containing an [ECMAScript] (JavaScript) regular expression. The matchesPattern function returns true if the first parameter evaluates to a string matching that regular expression, using syntax and semantics of [ECMAScript] regular expressions, otherwise it returns false.

    +
    5.1.1.7.1 matchespattern
    +

    The matchespattern function has the following signature:

    +
    Edm.Boolean matchespattern(Edm.String,Edm.String)
    +

    The second parameter MUST evaluate to a string containing an [ECMAScript] (JavaScript) regular expression. The matchespattern function returns true if the first parameter evaluates to a string matching that regular expression, using syntax and semantics of [ECMAScript] regular expressions, otherwise it returns false.

    Example 81: all customers with a CompanyName that match the (percent-encoded) regular expression ^A.*e$

    -
    http://host/service/Customers?$filter=matchesPattern(CompanyName,'%5EA.*e$')
    +
    http://host/service/Customers?$filter=matchespattern(CompanyName,'%5EA.*e$')
    5.1.1.7.2 tolower

    The tolower function has the following signature:

    Edm.String tolower(Edm.String)

    The tolower function returns the input parameter string value with all uppercase characters converted to lowercase according to Unicode rules. The toLowerMethodCallExpr syntax rule defines how the tolower function is invoked.

    -

    Example 82: all customers with a CompanyName that equals 'alfreds futterkiste' once any uppercase characters have been converted to lowercase

    +

    Example 82: all customers with a CompanyName that equals alfreds futterkiste once any uppercase characters have been converted to lowercase

    http://host/service/Customers?$filter=tolower(CompanyName) eq 'alfreds futterkiste'
    5.1.1.7.3 toupper
    @@ -1213,7 +1213,7 @@
    5.1.1.7.3 toupper
    Edm.String toupper(Edm.String)

    The toupper function returns the input parameter string value with all lowercase characters converted to uppercase according to Unicode rules. The toUpperMethodCallExpr syntax rule defines how the toupper function is invoked.

    -

    Example 83: all customers with a CompanyName that equals 'ALFREDS FUTTERKISTE' once any lowercase characters have been converted to uppercase

    +

    Example 83: all customers with a CompanyName that equals ALFREDS FUTTERKISTE once any lowercase characters have been converted to uppercase

    http://host/service/Customers?$filter=toupper(CompanyName) eq 'ALFREDS FUTTERKISTE'
    5.1.1.7.4 trim
    @@ -1361,7 +1361,7 @@
    5.1.1.10.1 castThe null value can be cast to any type.
  • Primitive types are cast to Edm.String or a type definition based on it by using the literal representation used in payloads, and WKT (well-known text) format for Geo types, see rules fullCollectionLiteral, fullLineStringLiteral, fullMultiPointLiteral, fullMultiLineStringLiteral, fullMultiPolygonLiteral, fullPointLiteral, and fullPolygonLiteral in OData-ABNF. The cast fails if the target type specifies an insufficient MaxLength.
  • Edm.String, or a type definition based on Edm.String, can be cast to a primitive type if the string contains a literal representation for the target type.
  • -
  • Numeric primitive types are cast to each other with appropriate rounding. The cast fails if the integer part doesn't fit into the target type.
  • +
  • Numeric primitive types are cast to each other with appropriate rounding. The cast fails if the integer part doesn’t fit into the target type.
  • Edm.DateTimeOffset, Edm.Duration, and Edm.TimeOfDay values can be cast to the same type with a different precision with appropriate rounding.
  • Non-Unicode string values can be cast to a Unicode string type definition. Unicode string values can be cast to a non-Unicode string type definition if the Unicode string only contains ASCII characters.
  • Structured types are assignable to their type or a direct or indirect base type.
  • @@ -1393,7 +1393,7 @@
    5.1.1.11.1

    The geo.distance function has the following signatures:

    Edm.Double geo.distance(Edm.GeographyPoint,Edm.GeographyPoint)
     Edm.Double geo.distance(Edm.GeometryPoint,Edm.GeometryPoint)
    -

    The geo.distance function returns the shortest distance between the two points in the coordinate reference system signified by the two points' SRIDs.

    +

    The geo.distance function returns the shortest distance between the two points in the coordinate reference system signified by the two points’ SRIDs.

    5.1.1.11.2 geo.intersects

    The geo.intersects function has the following signatures:

    Edm.Boolean geo.intersects(Edm.GeographyPoint,Edm.GeographyPolygon)
    @@ -1408,8 +1408,8 @@ 

    5.1.1.12.1 case

    The case function has the following signature:

    expression case(Edm.Boolean:expression, ..., Edm.Boolean:expression)
    -

    Each parameter is a pair of expressions separated by a colon (:), where the first expression -- the condition -- MUST be a Boolean expression, and the second expression -- the result -- may evaluate to any type.

    -

    The case function evaluates the condition in each pair, starting with the leftmost pair, and stops as soon as a condition evaluates to true. It then returns the value of the result of this pair. It returns null if none of the conditions in any pair evaluates to true. Clients can specify a last pair whose condition is true to get a non-null "default/else/otherwise" result.

    +

    Each parameter is a pair of expressions separated by a colon (:), where the first expression — the condition — MUST be a Boolean expression, and the second expression — the result — may evaluate to any type.

    +

    The case function evaluates the condition in each pair, starting with the leftmost pair, and stops as soon as a condition evaluates to true. It then returns the value of the result of this pair. It returns null if none of the conditions in any pair evaluates to true. Clients can specify a last pair whose condition is true to get a non-null “default/else/otherwise” result.

    Clients SHOULD ensure that the results in all pairs are compatible. If all results are of the same type, the type of the case expression is of that type. If all results are of numeric type, then the type of the case expression is a numeric type capable of representing any of these expressions according to standard type promotion rules.

    Services MAY support case expressions containing parameters of incompatible types, in which case the case expression is treated as Edm.Untyped and its value has the type of the parameter expression selected by the case statement.

    -

    Example 106: customers along with their orders that shipped to the same city as the customer's address. The nested filter expression is evaluated in the context of Orders; $it allows referring to values in the outer context of Customers.

    +

    Example 106: customers along with their orders that shipped to the same city as the customer’s address. The nested filter expression is evaluated in the context of Orders; $it allows referring to values in the outer context of Customers.

    http://host/service/Customers?$expand=Orders($filter=$it/Address/City eq ShipTo/City)
    @@ -1565,7 +1565,7 @@

    Core.Messages annotation

    http://host/service/Employees?$filter=@Core.Messages/any(m:m/severity eq 'error')

    -

    Services MAY additionally support the use of the unqualified term name by defining one or more default namespaces through the Core.DefaultNamespace annotation term defined in OData-VocCore. For more information on default namespaces, see Default Namespaces in OData-Protocol. This short notation however uses the same name pattern as parameter aliases. If a query option is specified as a parameter alias, then any occurrence of the parameter alias name in an expression MUST evaluate to the parameter alias value and MUST NOT evaluate to the annotation value of an identical unqualified term name.

    +

    Services MAY additionally support the use of the unqualified term name by defining one or more default namespaces through the Core.DefaultNamespace annotation term defined in OData-VocCore. For more information on default namespaces, see Default Namespaces in OData-Protocol. This short notation however uses the same name pattern as parameter aliases. If a query option is specified as a parameter alias, then any occurrence of the parameter alias name in an expression MUST evaluate to the parameter alias value and MUST NOT evaluate to the annotation value of an identical unqualified term name.

    5.1.1.17 Operator Precedence

    OData services MUST use the following operator precedence for supported operators when evaluating $filter and $orderby expressions. Operators are listed by category in order of precedence from highest to lowest. Operators in the same category have equal precedence:

    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
    matchesPattern
    matchesPattern(CompanyName,'%5EA.*e$')
    matchespattern
    matchespattern(CompanyName,'%5EA.*e$')
    tolower
    tolower(CompanyName) eq 'alfreds futterkiste'
    toupper
    toupper(CompanyName) eq 'ALFREDS FUTTERKISTE'
    trim
    trim(CompanyName) eq 'Alfreds Futterkiste'
    hassubset
    hassubset([4,1,3],[3,1])
    hassubsequence
    hassubsequence([4,1,3,1],[1,1])
    String Functions
    matchesPattern
    matchesPattern(CompanyName,'%5EA.*e$')
    matchespattern
    matchespattern(CompanyName,'%5EA.*e$')
    tolower
    tolower(CompanyName) eq 'alfreds futterkiste'
    toupper
    toupper(CompanyName) eq 'ALFREDS FUTTERKISTE'
    trim
    trim(CompanyName) eq 'Alfreds Futterkiste'
    @@ -1725,9 +1725,9 @@

    Cyclic navigation properties (whose target type is identical or can be cast to its source type) can be recursively expanded using the special $levels option. The value of the $levels option is either a positive integer to specify the number of levels to expand, or the literal string max to specify the maximum expansion level supported by that service. A $levels option with a value of 1 specifies a single expand with no recursion.

    -

    Example 123: all employees with their manager, manager's manager, and manager's manager's manager

    +

    Example 123: all employees with their manager, manager’s manager, and manager’s manager’s manager

    http://host/service/Employees?$expand=ReportsTo($levels=3)

    It is also possible to expand all declared and dynamic navigation properties using a star (*). To retrieve references to all related entities use */$ref, and to expand all related entities with a certain distance use the star operator with the $levels option. The star operator can be combined with explicitly named navigation properties, which take precedence over the star operator.

    @@ -1800,12 +1800,12 @@

    -

    Example 126: include Employee's Photo stream property along with other properties of the customer

    +

    Example 126: include Employee’s Photo stream property along with other properties of the customer

    http://host/service/Employees?$expand=Photo
    -

    Specifying $value for a media entity includes the media entity's stream value inline according to the specified format.

    +

    Specifying $value for a media entity includes the media entity’s stream value inline according to the specified format.

    -

    Example 127: Include the Product's media stream along with other properties of the product

    +

    Example 127: Include the Product’s media stream along with other properties of the product

    http://host/service/Products?$expand=$value

    5.1.4 System Query Option $select

    @@ -1940,7 +1940,7 @@

    -

    Example 139: JSON array of strings as parameter alias value -- note that [, ], and " need to be percent-encoded in real URLs, the clear-text representation used here is just for readability

    +

    Example 139: JSON array of strings as parameter alias value — note that [, ], and " need to be percent-encoded in real URLs, the clear-text representation used here is just for readability

    http://host/service/Products/Model.WithIngredients(Ingredients=@i)?@i=["Carrots","Ginger","Oranges"]

    @@ -1954,31 +1954,30 @@

    [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-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-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]
    -

    https://www.rfc-editor.org/info/rfc2119.

    +

    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”, STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005. https://www.rfc-editor.org/info/rfc3986.

    [RFC8174]
    -

    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.

    +

    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.

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

    @@ -1987,7 +1986,8 @@
    [ECMAScript]

    ECMAScript 2023 Language Specification, 14th Edition, June 2023. Standard ECMA-262. https://www.ecma-international.org/publications-and-standards/standards/ecma-262/.


    Appendix B. Safety, Security and Privacy Considerations

    -

    TODO: do we have considerations specific to URLs, for example length, encoding, privacy (use $batch if in doubt), ...?

    + +

    Appendix C. Acknowledgments

    C.1 Participants

    @@ -2073,14 +2073,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-url-conventions/odata-url-conventions.md b/docs/odata-url-conventions/odata-url-conventions.md index 8ea6a3eb4..bc585dfda 100644 --- a/docs/odata-url-conventions/odata-url-conventions.md +++ b/docs/odata-url-conventions/odata-url-conventions.md @@ -62,7 +62,7 @@ The Open Data Protocol (OData) enables the creation of REST-based data services, #### 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). @@ -169,7 +169,7 @@ For complete copyright information please see the full Notices section in an App - [5.1.1.6.1 `hassubset`](#hassubset) - [5.1.1.6.2 `hassubsequence`](#hassubsequence) - [5.1.1.7 String Functions](#StringFunctions) - - [5.1.1.7.1 `matchesPattern`](#matchesPattern) + - [5.1.1.7.1 `matchespattern`](#matchespattern) - [5.1.1.7.2 `tolower`](#tolower) - [5.1.1.7.3 `toupper`](#toupper) - [5.1.1.7.4 `trim`](#trim) @@ -303,7 +303,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-v4.02-csd01-part2-url-conventions.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-v4.02-csd01-part2-url-conventions.html -c styles/markdown-styles-v1.7.3b.css @@ -513,17 +513,17 @@ Below is a (non-normative) snippet from [OData-ABNF](#ODataABNF): ``` resourcePath = entitySetName [collectionNavigation] - / singleton [singleNavigation] + / singletonEntity [singleNavigation] / actionImportCall / entityColFunctionImportCall [ collectionNavigation ] / entityFunctionImportCall [ singleNavigation ] / complexColFunctionImportCall [ collectionPath ] / complexFunctionImportCall [ complexPath ] / primitiveColFunctionImportCall [ collectionPath ] - / primitiveFunctionImportCall [ singlePath ] - / functionImportCallNoParens - / crossjoin - / '$all' [ "/" qualifiedEntityTypeName ] + / primitiveFunctionImportCall [ primitivePath ] + / functionImportCallNoParens [ querySegment ] + / crossjoin [ querySegment ] + / %s"$all" [ "/" optionallyQualifiedEntityTypeName ] ``` Since OData has a uniform composable URL syntax and associated rules @@ -540,8 +540,8 @@ http://host/service/Products - By navigating a collection-valued navigation property (see rule: `entityColNavigationProperty`) -- By invoking a function that returns a -collection of entities (see rule: `entityColFunctionCall`) +- By invoking a function import that returns a +collection of entities (see rule: `entityColFunctionImportCall`) ::: example Example 9: function with parameters in resource path @@ -557,16 +557,16 @@ http://host/service/ProductsByColor(color=@color)?@color='red' ``` ::: -- By invoking an action that returns a -collection of entities (see rule: `actionCall`) +- By invoking an action import that returns a +collection of entities (see rule: `actionImportCall`) Likewise there are many ways to address a single entity. Sometimes a single entity can be accessed directly, for example by: -- Invoking a function that returns a -single entity (see rule: `entityFunctionCall`) -- Invoking an action that returns a single -entity (see rule: `actionCall`) +- Invoking a function import that returns a +single entity (see rule: `entityFunctionImportCall`) +- Invoking an action import that returns a single +entity (see rule: `actionImportCall`) - Addressing a singleton ::: example @@ -838,7 +838,7 @@ key properties of the related entity that take part in the referential constraint MUST be omitted from URLs using key-as-segment convention. ::: example -Example 27: key predicate of related entity - no key segments for key +Example 27: key predicate of related entity --- no key segments for key properties of related entity with a referential constraint to preceding key segments ``` @@ -925,7 +925,7 @@ defined in the [OData-Protocol](#ODataProtocol) document. Services MAY additionally support the use of the unqualified name of an action or function in a URL by defining one or more default namespaces through the -[`Core.DefaultNamespace`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#DefaultNamespace)` `term +[`Core.DefaultNamespace`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#DefaultNamespace) term defined in [OData-VocCore](#ODataVocCore). For more information on default namespaces, see Default Namespaces in [OData-Protocol](#ODataProtocol). @@ -1190,7 +1190,7 @@ combined with the [`$filter`](#SystemQueryOptionfilter) system query option. ::: example -Example 41: red products that cost less than 10 -- combining path +Example 41: red products that cost less than 10 --- combining path segment and system query option ``` GET Products/$filter(@foo)?@foo=Price lt 10&$filter=Color eq 'red' @@ -1198,7 +1198,7 @@ GET Products/$filter(@foo)?@foo=Price lt 10&$filter=Color eq 'red' ::: ::: example -Example 42: red products that cost less than 10 -- combine two path +Example 42: red products that cost less than 10 --- combine two path segments ``` GET Products/$filter(@p)/$filter(@c)?@p=Price lt 10&@c=Color eq 'red' @@ -1285,7 +1285,7 @@ the corresponding entity set, with a target type equal to the declared entity type of the corresponding entity set. The [`$filter`](#SystemQueryOptionfilter) and -[`$orderby`](#SystemQueryOptionorderby)` `query options can be specified +[`$orderby`](#SystemQueryOptionorderby) query options can be specified using properties of the entities in the selected entity sets, prepended with the entity set as the navigation property name. @@ -1644,49 +1644,49 @@ The following examples illustrate the use and semantics of each of the logical operators. ::: example -Example 50: all products with a `Name` equal to 'Milk' +Example 50: all products with a `Name` equal to `Milk` ``` http://host/service/Products?$filter=Name eq 'Milk' ``` ::: ::: example -Example 51: all products with a `Name` not equal to 'Milk' +Example 51: all products with a `Name` not equal to `Milk` ``` http://host/service/Products?$filter=Name ne 'Milk' ``` ::: ::: example -Example 52: all products with a Name greater than 'Milk': +Example 52: all products with a `Name` greater than `Milk`: ``` http://host/service/Products?$filter=Name gt 'Milk' ``` ::: ::: example -Example 53: all products with a Name greater than or equal to 'Milk': +Example 53: all products with a `Name` greater than or equal to `Milk`: ``` http://host/service/Products?$filter=Name ge 'Milk' ``` ::: ::: example -Example 54: all products with a Name less than 'Milk': +Example 54: all products with a `Name` less than `Milk`: ``` http://host/service/Products?$filter=Name lt 'Milk' ``` ::: ::: example -Example 55: all products with a Name less than or equal to 'Milk': +Example 55: all products with a `Name` less than or equal to `Milk`: ``` http://host/service/Products?$filter=Name le 'Milk'` ``` ::: ::: example -Example 56: all products with the Name 'Milk' that also have a Price +Example 56: all products with a `Name` equal to `Milk` that also have a `Price` less than 2.55: ``` http://host/service/Products?$filter=Name eq 'Milk' and Price lt 2.55 @@ -1694,15 +1694,15 @@ http://host/service/Products?$filter=Name eq 'Milk' and Price lt 2.55 ::: ::: example -Example 57: all products that either have the Name 'Milk' or have a -Price less than 2.55: +Example 57: all products that either have a `Name` equal to `Milk` or have a +`Price` less than 2.55: ``` http://host/service/Products?$filter=Name eq 'Milk' or Price lt 2.55 ``` ::: ::: example -Example 58: all products that do not have a Name that ends with 'ilk': +Example 58: all products that do not have a `Name` that ends with `ilk`: ``` http://host/service/Products?$filter=not endswith(Name,'ilk') ``` @@ -1716,7 +1716,7 @@ http://host/service/Products?$filter=style has Sales.Pattern'Yellow' ::: ::: example -Example 60: all products whose `name` value is 'Milk' or 'Cheese': +Example 60: all products whose `Name` is `Milk` or `Cheese`: ``` http://host/service/Products?$filter=Name in ('Milk', 'Cheese') ``` @@ -1771,7 +1771,7 @@ or `variable` if any operand has variable scale. The `sub` operator is also valid for the following time-related operands: -- `DateTimeOffset` `sub` `Duration` +- `DateTimeOffset sub Duration` results in a `DateTimeOffset` - `Duration sub Duration` results in a `Duration` @@ -1980,7 +1980,7 @@ The `containsMethodCallExpr` syntax rule defines how the `contains` function is invoked. ::: example -Example 70: all customers with a `CompanyName` that contains `'Alfreds'` +Example 70: all customers with a `CompanyName` that contains `Alfreds` ``` http://host/service/Customers?$filter=contains(CompanyName,'Alfreds') ``` @@ -2012,7 +2012,7 @@ function is invoked. ::: example Example 71: all customers with a `CompanyName` that ends with -`'Futterkiste'` +`Futterkiste` ``` http://host/service/Customers?$filter=endswith(CompanyName,'Futterkiste') ``` @@ -2043,7 +2043,7 @@ The `indexOfMethodCallExpr` syntax rule defines how the `indexof` function is invoked. ::: example -Example 72: all customers with a `CompanyName` containing '`lfreds'` +Example 72: all customers with a `CompanyName` containing `lfreds` starting at the second character ``` http://host/service/Customers?$filter=indexof(CompanyName,'lfreds') eq 1 @@ -2101,7 +2101,7 @@ The `startsWithMethodCallExpr` syntax rule defines how the `startswith` function is invoked. ::: example -Example 74: all customers with a `CompanyName` that starts with `'Alfr'` +Example 74: all customers with a `CompanyName` that starts with `Alfr` ``` http://host/service/Customers?$filter=startswith(CompanyName,'Alfr') ``` @@ -2155,7 +2155,7 @@ The `substringMethodCallExpr` syntax rule defines how the `substring` function is invoked. ::: example -Example 75: all customers with a `CompanyName` of `'lfreds Futterkiste'` +Example 75: all customers with a `CompanyName` of `lfreds Futterkiste` once the first character has been removed ``` http://host/service/Customers?$filter=substring(CompanyName,1) eq 'lfreds Futterkiste' @@ -2163,8 +2163,8 @@ http://host/service/Customers?$filter=substring(CompanyName,1) eq 'lfreds Futter ::: ::: example -Example 76: all customers with a `CompanyName` that has '`lf' `as the -second and third characters, e.g, '`Alfreds Futterkiste`' +Example 76: all customers with a `CompanyName` that has `lf` as the +second and third characters, e.g, `Alfreds Futterkiste` ``` http://host/service/Customers?$filter=substring(CompanyName,1,2) eq 'lf' ``` @@ -2247,17 +2247,17 @@ hassubsequence([1,2],[1,1,2]) #### 5.1.1.7 String Functions -##### 5.1.1.7.1 `matchesPattern` +##### 5.1.1.7.1 `matchespattern` -The `matchesPattern` function has the following signature: +The `matchespattern` function has the following signature: ``` -Edm.Boolean matchesPattern(Edm.String,Edm.String) +Edm.Boolean matchespattern(Edm.String,Edm.String) ``` The second parameter MUST evaluate to a string containing an [**[ECMAScript]**](#ECMAScript) (JavaScript) regular expression. The -`matchesPattern` function returns true if the first parameter evaluates +`matchespattern` function returns true if the first parameter evaluates to a string matching that regular expression, using syntax and semantics of [**[ECMAScript]**](#ECMAScript) regular expressions, otherwise it returns false. @@ -2266,7 +2266,7 @@ returns false. Example 81: all customers with a `CompanyName` that match the (percent-encoded) regular expression `^A.*e$` ``` -http://host/service/Customers?$filter=matchesPattern(CompanyName,'%5EA.*e$') +http://host/service/Customers?$filter=matchespattern(CompanyName,'%5EA.*e$') ``` ::: @@ -2285,7 +2285,7 @@ function is invoked. ::: example Example 82: all customers with a `CompanyName` that equals -`'alfreds futterkiste'` once any uppercase characters have been +`alfreds futterkiste` once any uppercase characters have been converted to lowercase ``` http://host/service/Customers?$filter=tolower(CompanyName) eq 'alfreds futterkiste' @@ -2307,7 +2307,7 @@ function is invoked. ::: example Example 83: all customers with a `CompanyName` that equals -`'ALFREDS FUTTERKISTE'` once any lowercase characters have been +`ALFREDS FUTTERKISTE` once any lowercase characters have been converted to uppercase ``` http://host/service/Customers?$filter=toupper(CompanyName) eq 'ALFREDS FUTTERKISTE' @@ -2799,8 +2799,8 @@ expression case(Edm.Boolean:expression, ..., Edm.Boolean:expression) ``` Each parameter is a pair of expressions separated by a colon (`:`), -where the first expression -- the condition -- MUST be a Boolean -expression, and the second expression -- the result -- may evaluate to +where the first expression --- the condition --- MUST be a Boolean +expression, and the second expression --- the result --- may evaluate to any type. The case function evaluates the condition in each pair, starting with @@ -3187,7 +3187,7 @@ http://host/service/Employees?$filter=@Core.Messages/any(m:m/severity eq 'error' Services MAY additionally support the use of the unqualified term name by defining one or more default namespaces through the -[`Core.DefaultNamespace`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#DefaultNamespace)` `annotation +[`Core.DefaultNamespace`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#DefaultNamespace) annotation term defined in [OData-VocCore](#ODataVocCore). For more information on default namespaces, see Default Namespaces in [OData-Protocol](#ODataProtocol). This short notation however uses the same name pattern as parameter @@ -3244,9 +3244,9 @@ rules, in order: - If either operand is `Edm.Double`, the other operand is converted to type `Edm.Double`. - Otherwise, if either operand is `Edm.Single`, the other operand is converted to type `Edm.Single`. - Otherwise, if either operand is of type `Edm.Decimal`, the other operand is converted to `Edm.Decimal`. -- Otherwise, if either operand is `Edm.Int64`, the other operand is converted to type `Edm.Int64.` -- Otherwise, if either operand is `Edm.Int32`, the other operand is converted to type `Edm.Int32.` -- Otherwise, if either operand is `Edm.Int16`, the other operand is converted to type `Edm.Int16. ` +- Otherwise, if either operand is `Edm.Int64`, the other operand is converted to type `Edm.Int64`. +- Otherwise, if either operand is `Edm.Int32`, the other operand is converted to type `Edm.Int32`. +- Otherwise, if either operand is `Edm.Int16`, the other operand is converted to type `Edm.Int16`. Each of these promotions uses the same semantics as a `castExpression` to promote an operand to the target type. @@ -3458,7 +3458,7 @@ Specifying `$value` for a media entity includes the media entity's stream value inline according to the specified format. ::: example -Example 127: Include the `Product`'s media stream along with other +Example 127: Include the Product's media stream along with other properties of the product ``` http://host/service/Products?$expand=$value @@ -3856,7 +3856,7 @@ http://host/service/Movies?$filter=Title eq @title&@title='Wizard of Oz' ::: ::: example -Example 139: JSON array of strings as parameter alias value -- note that +Example 139: JSON array of strings as parameter alias value --- note that `[`, `]`, and `"` need to be percent-encoded in real URLs, the clear-text representation used here is just for readability ``` @@ -3912,14 +3912,15 @@ _OData Vocabularies Version 4.0: Core Vocabulary._ See link in "[Related work](#RelatedWork)" 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_. 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", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005_. +https://www.rfc-editor.org/info/rfc3986. ###### [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. ###### [XML-Schema-2] @@ -3935,7 +3936,7 @@ _ECMAScript 2023 Language Specification, 14th Edition_, June 2023. Standard ECMA # Appendix B. Safety, Security and Privacy Considerations -TODO: do we have considerations specific to URLs, for example length, encoding, privacy (use $batch if in doubt), ...? + ------- diff --git a/lib/pandoc.js b/lib/pandoc.js index cef502082..19ba3b16d 100644 --- a/lib/pandoc.js +++ b/lib/pandoc.js @@ -3,7 +3,7 @@ const { spawn } = require("child_process"); module.exports = function (options) { var opts = [ "-f", - "gfm+tex_math_dollars+fenced_divs", + "gfm+tex_math_dollars+fenced_divs+smart", "-t", "html", "-c", diff --git a/odata-csdl/0 frontmatter.md b/odata-csdl/0 frontmatter.md index 28fa418ae..5b0e56f1e 100644 --- a/odata-csdl/0 frontmatter.md +++ b/odata-csdl/0 frontmatter.md @@ -76,7 +76,7 @@ $$$description$$$ #### 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). diff --git a/odata-csdl/1 Introduction.md b/odata-csdl/1 Introduction.md index b46000b13..8ea5a1033 100644 --- a/odata-csdl/1 Introduction.md +++ b/odata-csdl/1 Introduction.md @@ -70,7 +70,7 @@ All other text is normative unless otherwise labeled. Here is a customized command line which will generate HTML from this markdown file (named `$$$filename$$$.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 $$$filename$$$.html -c styles/markdown-styles-v1.7.3b.css @@ -439,17 +439,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 @@ -494,6 +494,305 @@ representation of primitive type values in URLs and [OData-JSON](#ODataJSON) for the representation in requests and responses. +## ##subsec Type Facets + +The facets in the following subsections modify or constrain the acceptable values of primitive typed model elements, +for example a [structural property](#StructuralProperty), +action or function [parameter](#Parameter), +action or function [return type](#ReturnType), or +[term](#Term). + +For single-valued model elements the facets apply to the value of the +model element. For collection-valued model elements the facets apply to the items +in the collection. + +### ##subsubsec MaxLength + +A positive integer value specifying the maximum length of a binary, +stream or string value. For binary or stream values this is the octet +length of the binary data, for string values it is the character length +(number of code points for Unicode). + +If no maximum length is specified, clients SHOULD expect arbitrary +length. + +::: {.varjson .rep} +### ##isec Type Facet Members +### ##subisec `$MaxLength` + +The value of `$MaxLength` is a positive integer. + +Note: [OData-CSDL-XML](#ODataCSDL) 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. +::: + +::: {.varxml .rep} +### ##isec Type Facet Attributes +### ##subisec Attribute `MaxLength` + +The value of `MaxLength` is a positive integer or the symbolic value +`max` as a shorthand for the maximum length supported for the type by +the service. + +Note: the symbolic value `max` is only allowed in OData 4.0 responses; +it is deprecated in OData 4.01. While clients MUST be prepared for this +symbolic value, OData 4.01 and greater services MUST NOT return the +symbolic value `max` and MAY instead specify the concrete maximum length +supported for the type by the service or omit the attribute entirely. +::: + +### ##subsubsec 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 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`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Measures.V1.md#DurationGranularity), +see [OData-VocMeasures](#ODataVocMeasures). + +::: {.varjson .rep} +### ##subisec `$Precision` + +The value of `$Precision` is a number. + +Absence of `$Precision` means unspecified precision both for decimal and temporal values. +::: + +::: {.varjson .example} +Example ##ex: `Precision` facet applied to the `DateTimeOffset` type +```json +"SuggestedTimes": { + "$Type": "Edm.DateTimeOffset", + "$Collection": true, + "$Precision": 6 +} +``` +::: + +::: {.varxml .rep} +### ##subisec Attribute `Precision` + +The value of `Precision` is a number. + +If not specified for a decimal value, the decimal value has +unspecified precision. + +If not specified for a temporal value, the temporal value has a +precision of zero. +::: + +::: {.varxml .example} +Example ##ex: [`Precision`](#Precision) facet applied to the +`DateTimeOffset` type +```xml + +``` +::: + +### ##subsubsec Scale + +A non-negative integer value specifying the maximum number of digits +allowed to the right of the decimal point, or one of the symbolic values +`floating` or `variable`. + +The value `floating` means that the decimal value represents a +decimal floating-point number whose number of significant digits is the +value of the [`Precision`](#Precision) facet. OData 4.0 responses MUST +NOT specify the value `floating`. + +The value `variable` means that the number of digits to the right of the +decimal point can vary from zero to the value of the +[`Precision`](#Precision) facet. + +An integer value means that the number of digits to the right of the +decimal point may vary from zero to the value of the `Scale` facet, and +the number of digits to the left of the decimal point may vary from one +to the value of the `Precision` facet minus the value of the `Scale` +facet. If `Precision` is equal to `Scale`, a single zero MUST precede +the decimal point. + +The value of `Scale` MUST be less than or equal to the value of +[`Precision`](#Precision). + +Note: if the underlying data store allows negative scale, services may +use a [`Precision`](#Precision) with the absolute value of the negative +scale added to the actual number of significant decimal digits, and +client-provided values may have to be rounded before being stored. + +::: {.varjson .rep} +### ##subisec `$Scale` + +The value of `$Scale` is a number or a string with one of the symbolic +values `floating` or `variable`. + +Services SHOULD use lower-case values; clients SHOULD accept values in a +case-insensitive manner. + +Absence of `$Scale` means `variable`. +::: + +::: {.varjson .example} +Example ##ex: [`Precision`](#Precision)`=3` and `Scale=2`. +Allowed values: 1.23, 0.23, 3.14 and 0.7, not allowed values: 123, 12.3 +```json +"Amount32": { + "$Type": "Edm.Decimal", + "$Precision": 3, + "$Scale": 2 +} +``` +::: + +::: {.varjson .example} +Example ##ex: `Precision=2` equals `Scale`. +Allowed values: 0.23, 0.7, not allowed values: 1.23, 1.2 +```json +"Amount22": { + "$Type": "Edm.Decimal", + "$Precision": 2, + "$Scale": 2 +} +``` +::: + +::: {.varjson .example} +Example ##ex: `Precision=3` and a variable `Scale`. +Allowed values: 0.123, 1.23, 0.23, 0.7, 123 and 12.3, not allowed +values: 12.34, 1234 and 123.4 due to the limited precision. +```json +"Amount3v": { + "$Type": "Edm.Decimal", + "$Precision": 3 +} +``` +::: + +::: {.varjson .example} +Example ##ex: `Precision=7` and a floating `Scale`. +Allowed values: -1.234567e3, 1e-101, 9.999999e96, not allowed values: +1e-102 and 1e97 due to the limited precision. +```json +"Amount7f": { + "$Type": "Edm.Decimal", + "$Precision": 7, + "$Scale": "floating" +} +``` +::: + +::: {.varxml .rep} +### ##subisec Attribute `Scale` + +The value of `Scale` is a number or one of the symbolic values +`floating` or `variable`. + +Services SHOULD use lower-case values; clients SHOULD accept values in a +case-insensitive manner. + +If not specified, the `Scale` facet defaults to zero. +::: + +::: {.varxml .example} +Example ##ex: [`Precision`](#Precision)`=3` and `Scale=2`. +Allowed values: 1.23, 0.23, 3.14 and 0.7, not allowed values: 123, 12.3 +(the [`Nullable`](#Nullable) attribute can be ignored in these examples) +```xml + +``` +::: + +::: {.varxml .example} +Example ##ex: `Precision=2` equals `Scale`. +Allowed values: 0.23, 0.7, not allowed values: 1.23, 1.2 +```xml + +``` +::: + +::: {.varxml .example} +Example ##ex: `Precision=3` and a variable `Scale`. +Allowed values: 0.123, 1.23, 0.23, 0.7, 123 and 12.3, not allowed +values: 12.34, 1234 and 123.4 due to the limited precision. +```xml + +``` +::: + +::: {.varxml .example} +Example ##ex: `Precision=7` and a floating `Scale`. +Allowed values: -1.234567e3, 1e-101, 9.999999e96, not allowed values: +1e-102 and 1e97 due to the limited precision. +```xml + +``` +::: + +### ##subsubsec Unicode + +For a string-typed model element the `Unicode` facet indicates whether the it +might contain and accept string values with Unicode characters (code +points) beyond the ASCII character set. The value `false` indicates that +the it will only contain and accept string values with characters +limited to the ASCII character set. + +If no value is specified, the `Unicode` facet defaults to `true`. + +::: {.varjson .rep} +### ##subisec `$Unicode` + +The value of `$Unicode` is one of the Boolean literals `true` or +`false`. Absence of the member means `true`. +::: + +::: {.varxml .rep} +### ##subisec Attribute `Unicode` + +The value of `Unicode` is one of the Boolean literals `true` or `false`. +Absence of the attribute means `true`. +::: + +### ##subsubsec SRID + +For a geometry- or geography-typed model element the `SRID` facet identifies which +spatial reference system is applied to its values. + +The value of the `SRID` facet MUST be a non-negative integer or the +special value `variable`. If no value is specified, the facet defaults +to `0` for `Geometry` types or `4326` for `Geography` types. + +The valid values of the `SRID` facet and their meanings are as defined +by the European Petroleum Survey Group [EPSG](#_EPSG). + +::: {.varjson .rep} +### ##subisec `$SRID` + +The value of `$SRID` is a string containing a number or the symbolic +value `variable`. +::: + +::: {.varxml .rep} +### ##subisec Attribute `SRID` + +The value of `SRID` is a number or the symbolic value `variable`. +::: + ## ##subsec Built-In Abstract Types The following built-in abstract types can be used within a model: @@ -532,9 +831,7 @@ be used anywhere a corresponding concrete type can be used, except: - cannot be used as the underlying type of a type definition or enumeration type. - `Collection(Edm.PrimitiveType)` - - cannot be used as the type of a property or term. - - cannot be used as the type of a parameter or the return type of - an action or function. + - cannot be used. - `Collection(Edm.Untyped)` - cannot be returned in a payload with an `OData-Version` header of `4.0`. Services should treat untyped properties as dynamic diff --git a/odata-csdl/12 Action and Function.md b/odata-csdl/12 Action and Function.md index b75ca57e9..ec8e594e6 100644 --- a/odata-csdl/12 Action and Function.md +++ b/odata-csdl/12 Action and Function.md @@ -156,7 +156,7 @@ explicitly indicated, it is unbound. Bound actions or functions are invoked on resources matching the type of the binding parameter. The binding parameter can be of any type, and it -MAY be [nullable](#Nullable). +MAY be nullable. Unbound actions are invoked from the entity container through an [action import](#ActionImport). @@ -240,7 +240,7 @@ The value of `IsComposable` is one of the Boolean literals `true` or The return type of an action or function overload MAY be any type in scope, or a collection of any type in scope. -The facets [`Nullable`](#Nullable), [`MaxLength`](#MaxLength), +The facets [`MaxLength`](#MaxLength), [`Precision`](#Precision), [`Scale`](#Scale), and [`SRID`](#SRID) can be used as appropriate to specify value restrictions of the return type, as well as the [`Unicode`](#Unicode) facet for 4.01 and greater payloads. diff --git a/odata-csdl/13 Entity Container.md b/odata-csdl/13 Entity Container.md index 89fda7b92..956f807e1 100644 --- a/odata-csdl/13 Entity Container.md +++ b/odata-csdl/13 Entity Container.md @@ -690,6 +690,8 @@ The `edm:FunctionImport` element MUST contain the attributes `Name` and `Function`, and it MAY contain the attributes `EntitySet` and `IncludeInServiceDocument`. +It MAY contain [`edm:Annotation`](#Annotation) elements. + ### ##subisec Attribute `Name` The value of `Name` is the function import's name. diff --git a/odata-csdl/14 Vocabulary and Annotation.md b/odata-csdl/14 Vocabulary and Annotation.md index 450d918c4..4afa65fc6 100644 --- a/odata-csdl/14 Vocabulary and Annotation.md +++ b/odata-csdl/14 Vocabulary and Annotation.md @@ -148,10 +148,11 @@ unqualified name of the term and whose value is an object. The term object MUST contain the member `$Kind` with a string value of `Term`. -It MAY contain the members `$Type`, `$Collection`, -[`$AppliesTo`](#Applicability), [`$Nullable`](#Nullable), +It MAY contain the members `$Type`, `$Collection`, `$Nullable`, `$DefaultValue`, +[`$BaseTerm`](#SpecializedTerm), +[`$AppliesTo`](#Applicability), [`$MaxLength`](#MaxLength), [`$Precision`](#Precision), -[`$Scale`](#Scale), [`$SRID`](#SRID), and `$DefaultValue`, as well as +[`$Scale`](#Scale), and [`$SRID`](#SRID), as well as [`$Unicode`](#Unicode) for 4.01 and greater payloads. It MAY contain [annotations](#Annotation). @@ -168,6 +169,19 @@ with the literal value `true`. Absence of the `$Type` member means the type is `Edm.String`. +### ##subisec `$Nullable` + +The value of `$Nullable` is one of the Boolean literals `true` or +`false`. Absence of the member means `false`. + +For single-valued terms the value `true` means that annotations may have +the `null` value. + +For collection-valued terms the annotation value will always be a +collection that MAY be empty. In this case `$Nullable` applies to items +of the collection and specifies whether the collection MAY contain +`null` values. + ### ##subisec `$DefaultValue` The value of `$DefaultValue` is the type-specific JSON representation of @@ -183,14 +197,12 @@ CSDL JSON documents MUST always specify an explicit value. ### ##isec Element `edm:Term` The `edm:Term` element MUST contain the attributes `Name` and `Type`. It -MAY contain the attributes `BaseTerm` and `AppliesTo`. +MAY contain the attributes `Nullable`, `DefaultValue`, [`BaseTerm`](#SpecializedTerm) and [`AppliesTo`](#Applicability). -It MAY specify values for the [`Nullable`](#Nullable), -[ ]{.apple-converted-space}[`MaxLength`](#MaxLength), -[`Precision`](#Precision), [`Scale`](#Scale), or [`SRID`](#SRID) facet -attributes, as well as the [`Unicode`](#Unicode) facet attribute for -4.01 and greater payloads. These facets and their implications are -described in section 7.2. +The facets [`MaxLength`](#MaxLength), +[`Precision`](#Precision), [`Scale`](#Scale), and [`SRID`](#SRID) can be +used as appropriate, as well as the [`Unicode`](#Unicode) facet attribute for +4.01 and greater payloads. A `edm:Term` element whose `Type` attribute specifies a primitive or enumeration type MAY define a value for the `DefaultValue` attribute. @@ -203,13 +215,35 @@ The value of `Name` is the term's name. ### ##subisec Attribute `Type` -For single-valued properties the value of `Type` is the qualified name -of the property's 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 `)`. +### ##subisec 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. + +For collection-valued terms the annotation value will always be a +collection that MAY be empty. In this case the `Nullable` attribute +applies to items of the collection and specifies whether the collection +MAY contain `null` values. + +If no value is specified for a single-valued term, the `Nullable` +attribute defaults to `true`. + +In OData 4.01 responses a collection-valued term MUST specify a +value for the `Nullable` attribute. + +If no value is specified for a collection-valued term, the client +cannot assume any default value. Clients SHOULD be prepared for this +situation even in OData 4.01 responses. + ### ##subisec Attribute `DefaultValue` The value of this attribute determines the value of the term when @@ -2338,7 +2372,7 @@ the member name of the enumeration value. #### ##subsubsubsec Function `odata.fillUriTemplate` The `odata.fillUriTemplate` client-side function takes two or more -expressions as arguments and returns a value of type `Edm.String.` +expressions as arguments and returns a value of type `Edm.String`. The first argument MUST be of type `Edm.String` and specifies a URI template according to [RFC6570](#rfc6570), the other arguments MUST be diff --git a/odata-csdl/15 Identifier and Path Values.md b/odata-csdl/15 Identifier and Path Values.md index a3b68dc6f..dab58f78c 100644 --- a/odata-csdl/15 Identifier and Path Values.md +++ b/odata-csdl/15 Identifier and Path Values.md @@ -108,7 +108,6 @@ Example ##ex: "@Core.DefaultNamespace": true, "Product": { "$Kind": "EntityType", - "$HasStream": true, "$Key": [ "ID" ], @@ -311,7 +310,7 @@ Example ##ex: - + diff --git a/odata-csdl/4 CSDL Document.md b/odata-csdl/4 CSDL Document.md index 9c6c18c07..d427bfdd8 100644 --- a/odata-csdl/4 CSDL Document.md +++ b/odata-csdl/4 CSDL Document.md @@ -55,8 +55,8 @@ other CSDL documents. The `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 +`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`. ### ##isec Element `edmx:DataServices` diff --git a/odata-csdl/7 Structural Property.md b/odata-csdl/7 Structural Property.md index 0c891825a..0b5a24dbb 100644 --- a/odata-csdl/7 Structural Property.md +++ b/odata-csdl/7 Structural Property.md @@ -38,7 +38,7 @@ the member value is an object. The property object MAY contain the member `$Kind` with a string value of `Property`. This member SHOULD be omitted to reduce document size. -It MAY contain the member [`$Type`](#Type), [`$Collection`](#Type), +It MAY contain the members [`$Type`](#Type), [`$Collection`](#Type), [`$Nullable`](#Nullable), [`$MaxLength`](#MaxLength), [`$Unicode`](#Unicode), [`$Precision`](#Precision), [`$Scale`](#Scale), [`$SRID`](#SRID), and [`$DefaultValue`](#DefaultValue). @@ -68,7 +68,7 @@ Example ##ex: complex type with two properties `Dimension` and `Length` ### ##isec Element `edm:Property` The `edm:Property` element MUST contain the `Name` and the `Type` -attribute, and it MAY contain the facet attributes +attribute, and it MAY contain the attributes [`Nullable`](#Nullable), [`MaxLength`](#MaxLength), [`Unicode`](#Unicode), [`Precision`](#Precision), [`Scale`](#Scale), [`SRID`](#SRID), and [`DefaultValue`](#DefaultValue). @@ -153,15 +153,7 @@ value ``` ::: -## ##subsec Type Facets - -Facets modify or constrain the acceptable values of a property. - -For single-valued properties the facets apply to the value of the -property. For collection-valued properties the facets apply to the items -in the collection. - -### ##subsubsec Nullable +## ##subsec Nullable A Boolean value specifying whether the property can have the value `null`. @@ -175,7 +167,7 @@ The value of `$Nullable` is one of the Boolean literals `true` or For single-valued properties the value `true` means that the property allows the `null` value. -For collection-valued properties the property value will always be a +For collection-valued properties the value will always be a collection that MAY be empty. In this case `$Nullable` applies to items of the collection and specifies whether the collection MAY contain `null` values. @@ -190,7 +182,7 @@ The value of `Nullable` is one of the Boolean literals `true` or For single-valued properties the value `true` means that the property allows the `null` value. -For collection-valued properties the property value will always be a +For collection-valued properties the value will always be a collection that MAY be empty. In this case the `Nullable` attribute applies to items of the collection and specifies whether the collection MAY contain `null` values. @@ -206,298 +198,9 @@ cannot assume any default value. Clients SHOULD be prepared for this situation even in OData 4.01 responses. ::: -### ##subsubsec MaxLength - -A positive integer value specifying the maximum length of a binary, -stream or string value. For binary or stream values this is the octet -length of the binary data, for string values it is the character length -(number of code points for Unicode). - -If no maximum length is specified, clients SHOULD expect arbitrary -length. - -::: {.varjson .rep} -### ##subisec `$MaxLength` - -The value of `$MaxLength` is a positive integer. - -Note: [OData-CSDL-XML](#ODataCSDL) 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. -::: - -::: {.varxml .rep} -### ##subisec Attribute `MaxLength` - -The value of `MaxLength` is a positive integer or the symbolic value -`max` as a shorthand for the maximum length supported for the type by -the service. - -Note: the symbolic value `max` is only allowed in OData 4.0 responses; -it is deprecated in OData 4.01. While clients MUST be prepared for this -symbolic value, OData 4.01 and greater services MUST NOT return the -symbolic value `max` and MAY instead specify the concrete maximum length -supported for the type by the service or omit the attribute entirely. -::: - -### ##subsubsec Precision - -For a decimal value: the maximum number of significant decimal digits of -the property'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 properties and 7 for -temporal properties. 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 properties will reduce -the risk for unintended data loss. - -Note: duration properties supporting a granularity less than seconds -(e.g. minutes, hours, days) can be annotated with term -[`Measures.DurationGranularity`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Measures.V1.md#DurationGranularity), -see [OData-VocMeasures](#ODataVocMeasures). - -::: {.varjson .rep} -### ##subisec `$Precision` - -The value of `$Precision` is a number. - -Absence of `$Precision` means arbitrary precision. -::: - -::: {.varjson .example} -Example ##ex: `Precision` facet applied to the `DateTimeOffset` type -```json -"SuggestedTimes": { - "$Type": "Edm.DateTimeOffset", - "$Collection": true, - "$Precision": 6 -} -``` -::: - -::: {.varxml .rep} -### ##subisec Attribute `Precision` - -The value of `Precision` is a number. - -If not specified for a decimal property, the decimal property has -arbitrary precision. - -If not specified for a temporal property, the temporal property has a -precision of zero. -::: - -::: {.varxml .example} -Example ##ex: [`Precision`](#Precision) facet applied to the -`DateTimeOffset` type -```xml - -``` -::: - -### ##subsubsec Scale - -A non-negative integer value specifying the maximum number of digits -allowed to the right of the decimal point, or one of the symbolic values -`floating` or `variable`. - -The value `floating` means that the decimal property represents a -decimal floating-point number whose number of significant digits is the -value of the [`Precision`](#Precision) facet. OData 4.0 responses MUST -NOT specify the value `floating`. - -The value `variable` means that the number of digits to the right of the -decimal point can vary from zero to the value of the -[`Precision`](#Precision) facet. - -An integer value means that the number of digits to the right of the -decimal point may vary from zero to the value of the `Scale` facet, and -the number of digits to the left of the decimal point may vary from one -to the value of the `Precision` facet minus the value of the `Scale` -facet. If `Precision` is equal to `Scale`, a single zero MUST precede -the decimal point. - -The value of `Scale` MUST be less than or equal to the value of -[`Precision`](#Precision). - -Note: if the underlying data store allows negative scale, services may -use a [`Precision`](#Precision) with the absolute value of the negative -scale added to the actual number of significant decimal digits, and -client-provided values may have to be rounded before being stored. - -::: {.varjson .rep} -### ##subisec `$Scale` - -The value of `$Scale` is a number or a string with one of the symbolic -values `floating` or `variable`. - -Services SHOULD use lower-case values; clients SHOULD accept values in a -case-insensitive manner. - -Absence of `$Scale` means `variable`. -::: - -::: {.varjson .example} -Example ##ex: [`Precision`](#Precision)`=3` and `Scale=2`. -Allowed values: 1.23, 0.23, 3.14 and 0.7, not allowed values: 123, 12.3 -```json -"Amount32": { - "$Nullable": true, - "$Type": "Edm.Decimal", - "$Precision": 3, - "$Scale": 2 -} -``` -::: - -::: {.varjson .example} -Example ##ex: `Precision=2` equals `Scale`. -Allowed values: 0.23, 0.7, not allowed values: 1.23, 1.2 -```json -"Amount22": { - "$Nullable": true, - "$Type": "Edm.Decimal", - "$Precision": 2, - "$Scale": 2 -} -``` -::: - -::: {.varjson .example} -Example ##ex: `Precision=3` and a variable `Scale`. -Allowed values: 0.123, 1.23, 0.23, 0.7, 123 and 12.3, not allowed -values: 12.34, 1234 and 123.4 due to the limited precision. -```json -"Amount3v": { - "$Nullable": true, - "$Type": "Edm.Decimal", - "$Precision": 3 -} -``` -::: - -::: {.varjson .example} -Example ##ex: `Precision=7` and a floating `Scale`. -Allowed values: -1.234567e3, 1e-101, 9.999999e96, not allowed values: -1e-102 and 1e97 due to the limited precision. -```json -"Amount7f": { - "$Nullable": true, - "$Type": "Edm.Decimal", - "$Precision": 7, - "$Scale": "floating" -} -``` -::: - -::: {.varxml .rep} -### ##subisec Attribute `Scale` - -The value of `Scale` is a number or one of the symbolic values -`floating` or `variable`. - -Services SHOULD use lower-case values; clients SHOULD accept values in a -case-insensitive manner. - -If not specified, the `Scale` facet defaults to zero. -::: - -::: {.varxml .example} -Example ##ex: [`Precision`](#Precision)`=3` and `Scale=2`. -Allowed values: 1.23, 0.23, 3.14 and 0.7, not allowed values: 123, 12.3 -```xml - -``` -::: - -::: {.varxml .example} -Example ##ex: `Precision=2` equals `Scale`. -Allowed values: 0.23, 0.7, not allowed values: 1.23, 1.2 -```xml - -``` -::: - -::: {.varxml .example} -Example ##ex: `Precision=3` and a variable `Scale`. -Allowed values: 0.123, 1.23, 0.23, 0.7, 123 and 12.3, not allowed -values: 12.34, 1234 and 123.4 due to the limited precision. -```xml - -``` -::: - -::: {.varxml .example} -Example ##ex: `Precision=7` and a floating `Scale`. -Allowed values: -1.234567e3, 1e-101, 9.999999e96, not allowed values: -1e-102 and 1e97 due to the limited precision. -```xml - -``` -::: - -### ##subsubsec Unicode - -For a string property the `Unicode` facet indicates whether the property -might contain and accept string values with Unicode characters (code -points) beyond the ASCII character set. The value `false` indicates that -the property will only contain and accept string values with characters -limited to the ASCII character set. - -If no value is specified, the `Unicode` facet defaults to `true`. - -::: {.varjson .rep} -### ##subisec `$Unicode` - -The value of `$Unicode` is one of the Boolean literals `true` or -`false`. Absence of the member means `true`. -::: - -::: {.varxml .rep} -### ##subisec Attribute `Unicode` - -The value of `Unicode` is one of the Boolean literals `true` or `false`. -Absence of the attribute means `true`. -::: - -### ##subsubsec SRID - -For a geometry or geography property the `SRID` facet identifies which -spatial reference system is applied to values of the property on type -instances. - -The value of the `SRID` facet MUST be a non-negative integer or the -special value `variable`. If no value is specified, the facet defaults -to `0` for `Geometry` types or `4326` for `Geography` types. - -The valid values of the `SRID` facet and their meanings are as defined -by the European Petroleum Survey Group [EPSG](#_EPSG). - -::: {.varjson .rep} -### ##subisec `$SRID` - -The value of `$SRID` is a string containing a number or the symbolic -value `variable`. -::: - -::: {.varxml .rep} -### ##subisec Attribute `SRID` - -The value of `SRID` is a number or the symbolic value `variable`. -::: - -### ##subsubsec Default Value +## ##subsec Default Value -A primitive or enumeration property MAY define a default value that is +A primitive- or enumeration-typed property MAY define a default value that is used if the property is not explicitly represented in an annotation or the body of a request or response. @@ -854,10 +557,10 @@ the target of the navigation). The type of the dependent property MUST match the type of the principal property, or both types MUST be complex types. -If the principle property references an entity, then the dependent +If the principal property references an entity, then the dependent property must reference the same entity. -If the principle property's value is a complex type instance, then the +If the principal property's value is a complex type instance, then the dependent property's value must be a complex type instance with the same properties, each with the same values. diff --git a/odata-csdl/Appendix.md b/odata-csdl/Appendix.md index 51b26a9c1..051230f21 100644 --- a/odata-csdl/Appendix.md +++ b/odata-csdl/Appendix.md @@ -85,23 +85,23 @@ _Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14 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. +_Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012_. +https://www.rfc-editor.org/info/rfc6570. : varjson ###### [RFC7493] -_Bray, T., Ed., "The I-JSON Message Format", RFC7493, March 2015_. -https://tools.ietf.org/html/rfc7493. +_The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015_. +https://www.rfc-editor.org/info/rfc7493. : ###### [RFC8174] _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. +https://www.rfc-editor.org/info/rfc8174. : varjson ###### [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", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017_. +https://www.rfc-editor.org/info/rfc8259. : : varxml @@ -125,7 +125,7 @@ http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/. Latest version available ## ##subasec 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/odata-data-aggregation-ext/0 frontmatter.md b/odata-data-aggregation-ext/0 frontmatter.md index 2effc04fe..82f2c2343 100644 --- a/odata-data-aggregation-ext/0 frontmatter.md +++ b/odata-data-aggregation-ext/0 frontmatter.md @@ -67,7 +67,7 @@ $$$description$$$ #### 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). diff --git a/odata-data-aggregation-ext/1 Introduction.md b/odata-data-aggregation-ext/1 Introduction.md index 5413a4085..1456fcf93 100644 --- a/odata-data-aggregation-ext/1 Introduction.md +++ b/odata-data-aggregation-ext/1 Introduction.md @@ -57,7 +57,7 @@ All other text is normative unless otherwise labeled. Here is a customized command line which will generate HTML from this markdown file (named `$$$filename$$$.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 $$$filename$$$.html -c styles/markdown-styles-v1.7.3b.css diff --git a/odata-json-format/0 frontmatter.md b/odata-json-format/0 frontmatter.md index 2132cfd61..3ea22f209 100644 --- a/odata-json-format/0 frontmatter.md +++ b/odata-json-format/0 frontmatter.md @@ -58,7 +58,7 @@ $$$description$$$ #### 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). diff --git a/odata-json-format/1 Introduction.md b/odata-json-format/1 Introduction.md index 6137f04c0..8e923a0e7 100644 --- a/odata-json-format/1 Introduction.md +++ b/odata-json-format/1 Introduction.md @@ -51,7 +51,7 @@ All other text is normative unless otherwise labeled. Here is a customized command line which will generate HTML from this markdown file (named `$$$filename$$$.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 $$$filename$$$.html -c styles/markdown-styles-v1.7.3b.css diff --git a/odata-json-format/15 Delta Payload.md b/odata-json-format/15 Delta Payload.md index cf3c92704..db7df27af 100644 --- a/odata-json-format/15 Delta Payload.md +++ b/odata-json-format/15 Delta Payload.md @@ -50,11 +50,11 @@ or deleted links. Example ##ex: 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 { @@ -116,7 +116,7 @@ have changed, and MAY include additional properties. If a property of an entity is dependent upon the property of another entity within the expanded set of entities being tracked, then both the -change to the dependent property as well as the change to the principle +change to the dependent property as well as the change to the principal property or [added](#AddedLink)/[deleted link](#DeletedLink) corresponding to the change to the dependent property are returned in the delta response. @@ -162,12 +162,12 @@ links](#DeletedLink). Example ##ex: 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 { @@ -255,10 +255,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) @@ -268,12 +268,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 ##ex: deleted entity in OData 4.0 response - note that `id` is +Example ##ex: deleted entity in OData 4.0 response --- note that `id` is a property, not control information ```json { @@ -313,7 +313,7 @@ following properties, regardless of the specified from the response _or_ the entity-id is not identical to the canonical URL of the entity. For [ordered payloads](#PayloadOrderingConstraints), the control information - `id,` if present, MUST immediately follow the control + `id`, if present, MUST immediately follow the control information [`removed`](#ControlInformationremovedodataremoved). @@ -368,13 +368,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) ## ##subsec Deleted Link @@ -392,16 +392,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`, @@ -422,16 +422,16 @@ entities, as well as [added](#AddedLink) or ::: example Example ##ex: 4.01 collection-update request for 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 `RequiredDate` 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 PATCH /service/Customers HTTP/1.1 Host: host diff --git a/odata-json-format/19 Batch Requests and Responses.md b/odata-json-format/19 Batch Requests and Responses.md index 00944e295..359d3443c 100644 --- a/odata-json-format/19 Batch Requests and Responses.md +++ b/odata-json-format/19 Batch Requests and Responses.md @@ -39,7 +39,7 @@ batch request URL, or a relative path (not starting with a forward slash `/`). If the first segment of a relative path starts with a `$` character and is not identical to the name of a top-level system -resource (`$batch`, `$crossjoin,` `$all,` `$entity`, `$root,` +resource (`$batch`, `$crossjoin`, `$all`, `$entity`, `$root`, `$id`, `$metadata`, or other system resources defined according to the `OData-Version` of the protocol specified in the request), then this first segment is replaced with the diff --git a/odata-json-format/4 Common Characteristics.md b/odata-json-format/4 Common Characteristics.md index 2461e5c64..22f0494ff 100644 --- a/odata-json-format/4 Common Characteristics.md +++ b/odata-json-format/4 Common Characteristics.md @@ -15,7 +15,7 @@ Requests and responses with a JSON message body MUST have a `Content-Type` header value of `application/json`. Requests MAY add the `charset` parameter to the content type. -Allowed values are `UTF-8`,` UTF-16`, and +Allowed values are `UTF-8`, `UTF-16`, and `UTF-32`. If no `charset` parameter is present, `UTF-8` MUST be assumed. @@ -319,6 +319,9 @@ information: should be treated as a string value unless the property is known (from the metadata document) to have a different type. +The `type` control information can be absent in properties nested in an instance of type `Edm.Untyped`. +In particular, individual primitive values within a collection cannot have `type` control information. + For more information on namespace- and alias-qualified names, see [OData-CSDLJSON](#ODataCSDL) or [OData-CSDLXML](#ODataCSDL). @@ -341,10 +344,8 @@ metadata document of the same service with a dynamic property of type ::: ::: example -Example ##ex: entity of type -`Model.VipCustomer` defined in the -metadata` `document of a different -service +Example ##ex: entity of type `Model.VipCustomer` defined in the +metadata document of a different service ```json { "@context": "http://host/service/$metadata#Customers/$entity", diff --git a/odata-json-format/7 Structural Property.md b/odata-json-format/7 Structural Property.md index d7f7ef314..b98aae8cf 100644 --- a/odata-json-format/7 Structural Property.md +++ b/odata-json-format/7 Structural Property.md @@ -146,6 +146,10 @@ Example ##ex: partial collection of strings with next link ``` ::: +A collection of primitive values that occurs in a property of type `Edm.Untyped` +is interpreted as a collection of `Edm.Boolean`, `Edm.String`, and `Edm.Decimal` values, +depending on the JavaScript type. + ## ##subsec Collection of Complex Values A collection of complex values is represented as a JSON array; each @@ -383,7 +387,7 @@ Example ##ex: 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. @@ -476,7 +480,8 @@ If the actual stream data is included inline, the control information MUST be present to indicate how the included stream property value is represented. Stream property values of media type `application/json` or one of its subtypes, optionally with format parameters, are represented -as native JSON. Values of top-level type `text`, for example +as native JSON. Values of top-level type `text` with an explicit or +default `charset` of `utf-8` or `us-ascii`, for example `text/plain`, are represented as a string, with JSON string escaping rules applied. Included stream data of other media types is represented as a base64url-encoded string value, see diff --git a/odata-json-format/Appendix.md b/odata-json-format/Appendix.md index 5d520f7a7..6aea417d2 100644 --- a/odata-json-format/Appendix.md +++ b/odata-json-format/Appendix.md @@ -39,40 +39,40 @@ _OData Vocabularies Version 4.0: Core Vocabulary._ See link in "[Related work](#RelatedWork)" 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", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005_. +https://www.rfc-editor.org/info/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, DOI 10.17487/RFC3987, January 2005_. +https://www.rfc-editor.org/info/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, DOI 10.17487/RFC4648, October 2006_. +https://www.rfc-editor.org/info/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, DOI 10.17487/RFC5646, September 2009_. +https://www.rfc-editor.org/info/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", RFC 7493, DOI 10.17487/RFC7493, March 2015_. +https://www.rfc-editor.org/info/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. +_Butler, H., Daly, M., Doyle, A., Gillies, S., Hagen, S., and T. Schaub, "The GeoJSON Format", RFC 7946, DOI 10.17487/RFC7946, August 2016_. +https://www.rfc-editor.org/info/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", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017_. +https://www.rfc-editor.org/info/rfc8259. ## ##subasec Informative References diff --git a/odata-protocol/0 frontmatter.md b/odata-protocol/0 frontmatter.md index 74363ef1b..cdc8713e5 100644 --- a/odata-protocol/0 frontmatter.md +++ b/odata-protocol/0 frontmatter.md @@ -62,7 +62,7 @@ $$$description$$$ #### 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). diff --git a/odata-protocol/1 Introduction.md b/odata-protocol/1 Introduction.md index 7e0d76e79..8ec33d691 100644 --- a/odata-protocol/1 Introduction.md +++ b/odata-protocol/1 Introduction.md @@ -56,7 +56,7 @@ All other text is normative unless otherwise labeled. Here is a customized command line which will generate HTML from this markdown file (named `$$$filename$$$.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 $$$filename$$$.html -c styles/markdown-styles-v1.7.3b.css diff --git a/odata-protocol/10 Context URL.md b/odata-protocol/10 Context URL.md index 325df5c83..bae736a89 100644 --- a/odata-protocol/10 Context URL.md +++ b/odata-protocol/10 Context URL.md @@ -320,7 +320,7 @@ Navigation properties with expanded references are not represented in the context URL. ::: example -Example ##ex: resource URL and corresponding context URL - select and +Example ##ex: resource URL and corresponding context URL --- select and expand ``` http://host/service/Customers?$select=Name&$expand=Address/Country @@ -329,7 +329,7 @@ http://host/service/$metadata#Customers(Name,Address/Country()) ::: ::: example -Example ##ex: resource URL and corresponding context URL -- expand `$ref` +Example ##ex: resource URL and corresponding context URL --- expand `$ref` ``` http://host/service/Customers?$expand=Orders/$ref http://host/service/$metadata#Customers @@ -337,7 +337,7 @@ http://host/service/$metadata#Customers ::: ::: example -Example ##ex: resource URL and corresponding context URL -- expand with +Example ##ex: resource URL and corresponding context URL --- expand with `$levels` ``` http://host/service/Employees/Sales.Manager?$select=DirectReports diff --git a/odata-protocol/11 Data Service Requests.md b/odata-protocol/11 Data Service Requests.md index 9167fa2a2..933597829 100644 --- a/odata-protocol/11 Data Service Requests.md +++ b/odata-protocol/11 Data Service Requests.md @@ -129,7 +129,7 @@ processing. Prior to applying any [server-driven paging](#ServerDrivenPaging): -- `$apply` -- defined in [OData-Aggregation](#ODataAggregation) +- `$apply` --- defined in [OData-Aggregation](#ODataAggregation) - [`$compute`](#SystemQueryOptioncompute) - [`$search`](#SystemQueryOptionsearch) - [`$filter`](#SystemQueryOptionfilter) @@ -167,7 +167,7 @@ Properties that are not available, for example due to permissions, are not returned. In this case, the [`Core.Permissions`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#Permissions) annotation, defined in [OData-VocCore](#ODataVocCore) MUST be returned -for the property with a value of `None.` +for the property with a value of `None`. If no entity exists with the specified request URL, the service responds with [`404 Not Found`](#ResponseCode404NotFound). @@ -185,12 +185,17 @@ entity is the main topic of interest and the stream data is just additional information attached to the structured data. To address the media stream represented by a media entity, clients -append `/$value` to the resource path of the media entity URL. Services -may redirect from this canonical URL to the source URL of the media +append `/$value` to the resource path of the media entity URL. +The media type of the response is the +media type of the stream, subject to content type negotiation based on the +[`Accept`](#HeaderAccept) header of the request. +The response body is the octet-stream that represents the raw +value of the media stream with that media type. Alternatively, services +MAY redirect from this canonical URL to the source URL of the media stream. Appending `/$value` to an entity that is not a media entity returns -`400 Bad Request.` +`400 Bad Request`. Attempting to retrieve the media stream from a single-valued navigation property referencing a media entity whose value is null returns @@ -199,7 +204,7 @@ property referencing a media entity whose value is null returns ### ##subsubsec 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 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 @@ -220,6 +225,18 @@ GET http://host/service/Products(1)/Name ``` ::: +#### ##subsubsubsec Requesting Stream Properties + +If the property being requested has type `Edm.Stream` (see +[OData-URL, section 9](#ODataURL)), the media type of the response is the +media type of the stream, subject to content type negotiation based on the +[`Accept`](#HeaderAccept) 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`](#SystemQueryOptionformat) +system query option. + #### ##subsubsubsec Requesting a Property's Raw Value using `$value` To retrieve the raw value of a primitive type property, the client sends @@ -259,6 +276,9 @@ A `$value` request for a property that is `null` results in a If the property is not available, for example due to permissions, the service responds with [`404 Not Found`](#ResponseCode404NotFound). +Appending `/$value` to the property URL of a property of type `Edm.Stream` +returns `400 Bad Request`. + ::: example Example ##ex: ``` @@ -627,7 +647,7 @@ a `null` literal that can be used in comparisons.

    - + @@ -666,7 +686,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 (`@`). @@ -678,7 +698,7 @@ specified parameter alias. ::: example Example ##ex: returns all employees whose Region property matches the -string parameter value "WA" +string parameter value `WA` ``` GET http://host/service.svc/Employees?$filter=Region eq @p1&@p1='WA' ``` @@ -880,7 +900,7 @@ those items *matching* the specified search expression. The definition of what it means to match is dependent upon the implementation. ::: example -Example ##ex: return all Products that match the search term "bike" +Example ##ex: return all Products that match the search term `bike` ``` GET http://host/service/Products?$search=bike ``` @@ -889,7 +909,7 @@ GET http://host/service/Products?$search=bike The search expression can contain phrases, enclosed in double-quotes. ::: example -Example ##ex: return all Products that match the phrase "mountain bike" +Example ##ex: return all Products that match the phrase `mountain bike` ``` GET http://host/service/Products?$search="mountain bike" ``` @@ -899,7 +919,7 @@ The upper-case keyword `NOT` restricts the set of entities to those that do not match the specified term. ::: example -Example ##ex: return all Products that do not match "clothing" +Example ##ex: return all Products that do not match `clothing` ``` GET http://host/service/Products?$search=NOT clothing ``` @@ -910,8 +930,8 @@ Multiple terms within a search expression are separated by a space such terms must be matched. ::: example -Example ##ex: return all Products that match both "mountain" and -"bike" +Example ##ex: return all Products that match both `mountain` and +`bike` ``` GET http://host/service/Products?$search=mountain AND bike ``` @@ -921,8 +941,8 @@ The upper-case keyword `OR` is used to return entities that satisfy either the immediately preceding or subsequent expression. ::: example -Example ##ex: return all Products that match either "mountain" or -"bike" +Example ##ex: return all Products that match `mountain` or +`bike` ``` GET http://host/service/Products?$search=mountain OR bike ``` @@ -932,8 +952,8 @@ Parentheses within the search expression group together multiple expressions. ::: example -Example ##ex: return all Products that match either "mountain" or -"bike" and do not match clothing +Example ##ex: 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 ``` @@ -1211,7 +1231,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. ### ##subsubsec System Query Option `$schemaversion` @@ -1263,7 +1283,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 @@ -1272,7 +1292,7 @@ change-tracking. Clients request that the service track changes to a result by specifying the [`track-changes`](#Preferencetrackchangesodatatrackchanges) preference on a request. If supported for the request, the service includes a -[`Preference-Applied`](#HeaderPreferenceApplied)` `header in the +[`Preference-Applied`](#HeaderPreferenceApplied) 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. diff --git a/odata-protocol/11.4 Data Modification.md b/odata-protocol/11.4 Data Modification.md index 6e48b71df..86a1f307e 100644 --- a/odata-protocol/11.4 Data Modification.md +++ b/odata-protocol/11.4 Data Modification.md @@ -34,7 +34,7 @@ A [Data Modification Request](#DataModification) on an existing resource or an [Action Request](#Actions) invoking an action bound to an existing resource MAY require optimistic concurrency control. Services SHOULD announce this via annotations with the terms -[`Core.OptimisticConcurrency`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#OptimisticConcurrency)` `in +[`Core.OptimisticConcurrency`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#OptimisticConcurrency) in [OData-VocCore](#ODataVocCore) and [`Capabilities.NavigationRestrictions`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Capabilities.V1.md#NavigationRestrictions) (nested property `OptimisticConcurrencyControl`) in @@ -262,7 +262,7 @@ 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 +Media entities MUST contain the format-specific representation of their media stream as a virtual property `$value` when nested within a deep insert. @@ -315,8 +315,10 @@ 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. Missing -properties of the containing entity or complex property, including +the corresponding property in the entity or complex type. +Complex properties are updated by applying `PATCH` semantics recursively, +see also [section ##UpdateaComplexProperty]. +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. @@ -334,7 +336,7 @@ 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 +the format-specific representation of the media stream as a virtual property `$value`. Updating a dependent property that is tied to a key property of the @@ -342,7 +344,7 @@ 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. -Updating a principle property that is tied to a dependent entity through +Updating a principal property that is tied to a dependent entity through a referential constraint on the dependent entity updates the dependent property. @@ -423,17 +425,17 @@ NOT include added links, deleted links, or deleted entities. Example ##ex: 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"     },     { @@ -693,8 +695,8 @@ entity. Upon successful completion the service responds with either [`201 Created`](#ResponseCode201Created), or -[`204 No Content`](#ResponseCode204NoContent)if the request included a -[Prefer header](#Preferencereturnrepresentationandreturnminimal) with a value of +[`204 No Content`](#ResponseCode204NoContent) if the request included a +[`Prefer` header](#Preferencereturnrepresentationandreturnminimal) with a value of [`return=minimal`](#Preferencereturnrepresentationandreturnminimal). #### ##subsubsubsec Update a Media Entity Stream @@ -762,8 +764,8 @@ Example ##ex: directly read a stream property of an entity ``` GET http://host/service/Products(1)/Thumbnail ``` -can return [`200 OK`](#ResponseCode200OK) and the stream data, or a -[`3xx Redirect`](#ResponseCode3xxRedirection) to the media read link of the stream property. +can return [`200 OK`](#ResponseCode200OK) and the stream data (see [section ##RequestingStreamProperties]), +or a [`3xx Redirect`](#ResponseCode3xxRedirection) to the media read link of the stream property. ::: Note: for scenarios in which the media value can only be inlined, @@ -877,11 +879,16 @@ property to null. A successful `PATCH` request to the edit URL for a complex typed property updates that property. The request body MUST contain a single -valid representation for the target complex type. +valid representation for the declared type of the complex property or one of its derived types. The service MUST directly modify only those properties of the complex type specified in the payload of the `PATCH` request. +If a complex-typed property is set to a different type in a `PATCH` request, +properties shared through inheritance, as well as dynamic properties, +are retained (unless overwritten by new values in the payload). +Other properties of the original type are discarded. + The service MAY additionally support clients sending a `PUT` request to a URL that specifies a complex type. In this case, the service MUST replace the entire complex property with the values specified in the diff --git a/odata-protocol/11.5 Operations.md b/odata-protocol/11.5 Operations.md index e00bc941d..9be53635c 100644 --- a/odata-protocol/11.5 Operations.md +++ b/odata-protocol/11.5 Operations.md @@ -130,7 +130,7 @@ particular instance by setting its value to null. ::: example Example ##ex: the `SampleEntities.MostRecentOrder` function is not -available for customer 'ALFKI' +available for customer `ALFKI` ```json {   "@context": ..., @@ -169,7 +169,7 @@ ampersand (`&`) or a question mark (`?`). Services MAY additionally support invoking functions using the unqualified function name by defining one or more [default namespaces](#DefaultNamespaces) through the -[`Core.DefaultNamespace`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#DefaultNamespace)` `term +[`Core.DefaultNamespace`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#DefaultNamespace) term defined in  [OData-VocCore](#ODataVocCore). Functions can be used within [`$filter`](#SystemQueryOptionfilter) or @@ -208,6 +208,10 @@ POST http://host/service/MyShoppingCart()/Items ``` ::: +If the function returns a value of type `Edm.Stream` and no additional path +segments follow the function invocation, the response to the `GET` request +follows the rules for [requesting stream properties](#RequestingStreamProperties). + Parameter values passed to functions MUST be specified either as a URL literal (for primitive values) or as a JSON formatted OData object (for complex values, or collections of primitive or complex values). Entity @@ -253,8 +257,8 @@ GET http://host/service/EmployeesByManager(ManagerID=3) ::: ::: example -Example ##ex: return all `Customers` whose City property returns -"Western" when passed to the `Sales.SalesRegion` function +Example ##ex: return all Customers whose `City` property returns +`Western` when passed to the `Sales.SalesRegion` function ``` GET http://host/service/Customers?       $filter=Sales.SalesRegion(City=$it/City) eq 'Western' @@ -295,7 +299,7 @@ GET http://host/service/EmployeesByManager?ManagerID=3 ::: Non-binding parameters annotated with the term -[`Core.OptionalParameter`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#OptionalParameter)` `defined +[`Core.OptionalParameter`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#OptionalParameter) defined in [OData-VocCore](#ODataVocCore) MAY be omitted. If it is annotated and the annotation specifies a `DefaultValue`, the omitted parameter is interpreted as having that default value. If omitted and the annotation @@ -345,7 +349,7 @@ request was ambiguous. ### ##subsubsec Actions Actions are operations exposed by an OData service that MAY have side -effects when invoked. Actions MAY return data but` `MUST NOT be further +effects when invoked. Actions MAY return data but MUST NOT be further composed with additional path segments. #### ##subsubsubsec Invoking an Action @@ -364,7 +368,7 @@ according to the particular format. Services MAY additionally support invoking actions using the unqualified action name by defining one or more [default namespaces](#DefaultNamespaces) through the -[`Core.DefaultNamespace`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#DefaultNamespace)` `term +[`Core.DefaultNamespace`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#DefaultNamespace) term defined in  [OData-VocCore](#ODataVocCore). To invoke an action through an action import, the client issues a `POST` @@ -375,7 +379,7 @@ values MUST be passed in the request body according to the particular format. Non-binding parameters that are nullable or annotated with the term -[`Core.OptionalParameter`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#OptionalParameter)` `defined +[`Core.OptionalParameter`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#OptionalParameter) defined in [OData-VocCore](#ODataVocCore) MAY be omitted from the request body. If an omitted parameter is not annotated (and thus nullable), it MUST be interpreted as having the `null` value. If it is annotated and the @@ -405,6 +409,9 @@ Actions that create and return a single entity follow the rules for header](#HeaderLocation) that contains the edit URL or read URL of the created entity. +If the action returns a value of type `Edm.Stream`, the response to the `POST` request +follows the rules for [requesting stream properties](#RequestingStreamProperties). + Actions without a return type respond with [`204 No Content`](#ResponseCode204NoContent) on success. @@ -417,7 +424,7 @@ collection response. ::: example Example ##ex: invoke the `SampleEntities.CreateOrder` action using -`/Customers('ALFKI') `as the customer (or binding parameter). The values +`Customers('ALFKI')` as the customer (or binding parameter). The values `2` for the `quantity` parameter and `BLACKFRIDAY` for the `discountCode` parameter are passed in the body of the request. Invoke the action only if the customer's ETag still matches. diff --git a/odata-protocol/11.7 Batch Requests.md b/odata-protocol/11.7 Batch Requests.md index 6ceb42e4b..083606717 100644 --- a/odata-protocol/11.7 Batch Requests.md +++ b/odata-protocol/11.7 Batch Requests.md @@ -110,7 +110,7 @@ clients MUST be able to resolve it relative to the request's URL even if that contains such a reference. If the `$`-prefixed request identifier is identical to the name of a -top-level system resource (`$batch`, `$crossjoin,` `$all,` `$entity`, +top-level system resource (`$batch`, `$crossjoin`, `$all`, `$entity`, `$root`, `$id`, `$metadata`, or other system resources defined according to the [`OData-Version`](#HeaderODataVersion) of the protocol specified in the request), then the reference to the top-level system resource is @@ -230,8 +230,8 @@ need not be percent-encoded. Each body part that represents a single request MUST NOT include: -- `authentication` or `authorization` related HTTP headers -- `Expect`, `From`, `Max-Forwards`, `Range`, or `TE` headers +- `authentication` or `authorization` related HTTP headers +- `Expect`, `From`, `Max-Forwards`, `Range`, or `TE` headers Processors of batch requests MAY choose to disallow additional HTTP constructs in HTTP requests serialized within body parts. For example, a @@ -422,7 +422,7 @@ response so clients can correlate requests and responses. #### ##subsubsubsec 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/odata-protocol/12 Conformance.md b/odata-protocol/12 Conformance.md index df016cd9e..bceb51a95 100644 --- a/odata-protocol/12 Conformance.md +++ b/odata-protocol/12 Conformance.md @@ -180,13 +180,13 @@ collection-valued properties (section 5.1.1.10 in [OData-URL](#ODataURL)) 6. MUST support the `$skip` system query option ([section ##SystemQueryOptionskip]) 7. MUST support the `$count` system query option ([section ##SystemQueryOptioncount]) -8. MUST support `$orderby` `asc` and `desc` on individual properties +8. MUST support `$orderby` with `asc` and `desc` on individual properties ([section ##SystemQueryOptionorderby]) 9. MUST support `$expand` ([section ##SystemQueryOptionexpand]) 1. MUST support returning references for expanded properties 2. MUST support `$filter` on expanded collection-valued properties 3. MUST support cast segment in expand with derived types - 4. SHOULD support `$orderby` `asc` and `desc` on expanded + 4. SHOULD support `$orderby` with `asc` and `desc` on expanded collection-valued properties 5. SHOULD support `$count` on expanded collection-valued properties 6. SHOULD support `$top` and `$skip` on expanded collection-valued @@ -315,7 +315,7 @@ Level](#OData401MinimalConformanceLevel) Level](#OData40IntermediateConformanceLevel) 3. MUST support `eq/ne null` comparison for navigation properties with a maximum cardinality of one -4. MUST support the [`in`](#BuiltinFilterOperations)` `operator +4. MUST support the [`in`](#BuiltinFilterOperations) operator 5. MUST support the `$select` option nested within `$select` 6. SHOULD support the count of a filtered collection in a common expression @@ -340,7 +340,7 @@ expression 4. MUST support `$compute` system query option 5. MUST support nested options in `$select` 1. MUST support `$filter` on selected collection-valued properties - 2. SHOULD support `$orderby` `asc` and `desc` on selected + 2. SHOULD support `$orderby` with `asc` and `desc` on selected collection-valued properties 3. SHOULD support the `$count` on selected collection-valued properties diff --git a/odata-protocol/8 Header Fields.md b/odata-protocol/8 Header Fields.md index 5bf87dbec..d2ff452e5 100644 --- a/odata-protocol/8 Header Fields.md +++ b/odata-protocol/8 Header Fields.md @@ -23,7 +23,7 @@ or [stream property](#ManagingStreamProperties), in which case the 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 +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. @@ -167,7 +167,7 @@ As defined in [RFC7232](#rfc7232), a client MAY include an 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`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#OptimisticConcurrency)` `in +[`Core.OptimisticConcurrency`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#OptimisticConcurrency) in [OData-VocCore](#ODataVocCore) and property `OptimisticConcurrencyControl` of type [`Capabilities.NavigationPropertyRestriction`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Capabilities.V1.md#NavigationPropertyRestriction) @@ -491,7 +491,7 @@ Prefer: include-annotations="-*" ::: example Example ##ex: a `Prefer` header requesting that all annotations defined -under the "display" namespace (recursively) be returned +under the `display` namespace (recursively) be returned ``` Prefer: include-annotations="display.*" ``` @@ -507,8 +507,8 @@ Prefer: include-annotations="display.subject" ::: example Example ##ex: a `Prefer` header requesting that all annotations defined -under the "display" namespace (recursively) with the qualifier -"tablet" be returned +under the `display` namespace (recursively) with the qualifier +`tablet` be returned ``` Prefer: include-annotations="display.*#tablet" ``` @@ -642,7 +642,7 @@ A preference of `return=minimal` requests that the service invoke the request but does not return content in the response. The service MAY apply this preference by returning [`204 No Content`](#ResponseCode204NoContent) in which case it MAY -include a [`Preference-Applied`](#HeaderPreferenceApplied)` `response +include a [`Preference-Applied`](#HeaderPreferenceApplied) response header containing the `return=minimal `preference. A preference of `return=representation` requests that the service @@ -673,7 +673,7 @@ requests within the batch request. In the case that the service applies the `respond-async` preference it MUST include a -[`Preference-Applied`](#HeaderPreferenceApplied)` `response header +[`Preference-Applied`](#HeaderPreferenceApplied) response header containing the `respond-async` preference. A service MAY specify the support for the `respond-async` preference @@ -1037,7 +1037,9 @@ include a response body describing the functionality not implemented. ## ##subsec Error Response Body -The representation of an error response body is format-specific. It +An error response body can be the result of a failure of OData processing or of the underlying infrastructure. +An OData-specific error response (which can be recognized by the presence +of the [`OData-Version`](#HeaderODataVersion) header) is format-specific and consists at least of the following information: - `code`: required non-null, non-empty, language-independent string. Its value is a service-defined error code. diff --git a/odata-protocol/Appendix.md b/odata-protocol/Appendix.md index bc49beaef..caa5ac333 100644 --- a/odata-protocol/Appendix.md +++ b/odata-protocol/Appendix.md @@ -43,50 +43,47 @@ _OData Vocabularies Version 4.0: Core Vocabulary._ See link in "[Related work](#RelatedWork)" section on cover page. ###### [RFC2046] -_Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996_ -https://tools.ietf.org/html/rfc2046. +_Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996_. +https://www.rfc-editor.org/info/rfc2046. ###### [RFC2119] +_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. ###### [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, DOI 10.17487/RFC3987, January 2005_. +https://www.rfc-editor.org/info/rfc3987. ###### [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, DOI 10.17487/RFC5646, September 2009_. +https://www.rfc-editor.org/info/rfc5646. ###### [RFC5789] -_Dusseault, L., and J. Snell, "Patch Method for HTTP", RFC 5789, March 2010_ -http://tools.ietf.org/html/rfc5789. - -###### [RFC7493] -_Bray, T., Ed., "The I-JSON Message Format", RFC7493, March 2015_ -https://tools.ietf.org/html/rfc7493. +_Dusseault, L. and J. Snell, "PATCH Method for HTTP", RFC 5789, DOI 10.17487/RFC5789, March 2010_. +https://www.rfc-editor.org/info/rfc5789. ###### [RFC7230] -_Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014_ -https://tools.ietf.org/html/rfc7230. +_Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014_. +https://www.rfc-editor.org/info/rfc7230. ###### [RFC7231] -_Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014_ -https://tools.ietf.org/html/rfc7231. +_Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014_. +https://www.rfc-editor.org/info/rfc7231. ###### [RFC7232] -_Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 2014_ -https://tools.ietf.org/html/rfc7232. +_Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014_. +https://www.rfc-editor.org/info/rfc7232. ###### [RFC7240] -_Snell, J., "Prefer Header for HTTP", RFC 7240, June 2014_ -https://tools.ietf.org/html/rfc7240. +_Snell, J., "Prefer Header for HTTP", RFC 7240, DOI 10.17487/RFC7240, June 2014_. +https://www.rfc-editor.org/info/rfc7240. ###### [RFC7617] -_Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, September 2015_ -https://tools.ietf.org/html/rfc7617. +_Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015_. +https://www.rfc-editor.org/info/rfc7617. ###### [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. ## ##subasec Informative References diff --git a/odata-temporal-ext/0 frontmatter.md b/odata-temporal-ext/0 frontmatter.md index 8bbbb4e98..e705ac656 100644 --- a/odata-temporal-ext/0 frontmatter.md +++ b/odata-temporal-ext/0 frontmatter.md @@ -69,7 +69,7 @@ $$$description$$$ #### 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). diff --git a/odata-temporal-ext/1 Introduction.md b/odata-temporal-ext/1 Introduction.md index 552b60489..0e552ef61 100644 --- a/odata-temporal-ext/1 Introduction.md +++ b/odata-temporal-ext/1 Introduction.md @@ -147,7 +147,7 @@ All other text is normative unless otherwise labeled. Here is a customized command line which will generate HTML from this markdown file (named `$$$filename$$$.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 $$$filename$$$.html -c styles/markdown-styles-v1.7.3b.css diff --git a/odata-temporal-ext/4 Temporal Requests.md b/odata-temporal-ext/4 Temporal Requests.md index 14fcaab62..0f874b461 100644 --- a/odata-temporal-ext/4 Temporal Requests.md +++ b/odata-temporal-ext/4 Temporal Requests.md @@ -72,7 +72,7 @@ applicable rule: 2. by a [`$at`](#QueryOptionat) value propagated along `$expand` 3. by [`$at`](#QueryOptionat) in the query option part of the request URL, which applies to every segment of the resource path and paths that occur in system query options -4. by the default value "now" - the logic for determining this value is service-specific +4. by the default value "now" --- the logic for determining this value is service-specific For entities in a [timeline entity set](#TimelineEntitySet) the time interval for filtering time slices is determined by the first @@ -137,7 +137,7 @@ Example ##ex: retrieve multiple employees at a past point in time GET /api-1/Employees?$filter=contains(Name,'i')&$at=2012-01-01 ``` results in one time slice for each employee matching the filter at the -specified point in time - note that E401 back then does not satisfy +specified point in time --- note that E401 back then does not satisfy this condition ```json { diff --git a/odata-url-conventions/0 frontmatter.md b/odata-url-conventions/0 frontmatter.md index d0e5069a8..a80365853 100644 --- a/odata-url-conventions/0 frontmatter.md +++ b/odata-url-conventions/0 frontmatter.md @@ -62,7 +62,7 @@ $$$description$$$ #### 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). diff --git a/odata-url-conventions/1 Introduction.md b/odata-url-conventions/1 Introduction.md index f34801c3d..f64a2616b 100644 --- a/odata-url-conventions/1 Introduction.md +++ b/odata-url-conventions/1 Introduction.md @@ -61,7 +61,7 @@ All other text is normative unless otherwise labeled. Here is a customized command line which will generate HTML from this markdown file (named `$$$filename$$$.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 $$$filename$$$.html -c styles/markdown-styles-v1.7.3b.css diff --git a/odata-url-conventions/4 Resource Path.md b/odata-url-conventions/4 Resource Path.md index ff7a73a65..5138d0866 100644 --- a/odata-url-conventions/4 Resource Path.md +++ b/odata-url-conventions/4 Resource Path.md @@ -78,17 +78,17 @@ Below is a (non-normative) snippet from [OData-ABNF](#ODataABNF): ``` resourcePath = entitySetName [collectionNavigation] - / singleton [singleNavigation] + / singletonEntity [singleNavigation] / actionImportCall / entityColFunctionImportCall [ collectionNavigation ] / entityFunctionImportCall [ singleNavigation ] / complexColFunctionImportCall [ collectionPath ] / complexFunctionImportCall [ complexPath ] / primitiveColFunctionImportCall [ collectionPath ] - / primitiveFunctionImportCall [ singlePath ] - / functionImportCallNoParens - / crossjoin - / '$all' [ "/" qualifiedEntityTypeName ] + / primitiveFunctionImportCall [ primitivePath ] + / functionImportCallNoParens [ querySegment ] + / crossjoin [ querySegment ] + / %s"$all" [ "/" optionallyQualifiedEntityTypeName ] ``` Since OData has a uniform composable URL syntax and associated rules @@ -105,8 +105,8 @@ http://host/service/Products - By navigating a collection-valued navigation property (see rule: `entityColNavigationProperty`) -- By invoking a function that returns a -collection of entities (see rule: `entityColFunctionCall`) +- By invoking a function import that returns a +collection of entities (see rule: `entityColFunctionImportCall`) ::: example Example ##ex: function with parameters in resource path @@ -122,16 +122,16 @@ http://host/service/ProductsByColor(color=@color)?@color='red' ``` ::: -- By invoking an action that returns a -collection of entities (see rule: `actionCall`) +- By invoking an action import that returns a +collection of entities (see rule: `actionImportCall`) Likewise there are many ways to address a single entity. Sometimes a single entity can be accessed directly, for example by: -- Invoking a function that returns a -single entity (see rule: `entityFunctionCall`) -- Invoking an action that returns a single -entity (see rule: `actionCall`) +- Invoking a function import that returns a +single entity (see rule: `entityFunctionImportCall`) +- Invoking an action import that returns a single +entity (see rule: `actionImportCall`) - Addressing a singleton ::: example @@ -403,7 +403,7 @@ key properties of the related entity that take part in the referential constraint MUST be omitted from URLs using key-as-segment convention. ::: example -Example ##ex: key predicate of related entity - no key segments for key +Example ##ex: key predicate of related entity --- no key segments for key properties of related entity with a referential constraint to preceding key segments ``` @@ -490,7 +490,7 @@ defined in the [OData-Protocol](#ODataProtocol) document. Services MAY additionally support the use of the unqualified name of an action or function in a URL by defining one or more default namespaces through the -[`Core.DefaultNamespace`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#DefaultNamespace)` `term +[`Core.DefaultNamespace`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#DefaultNamespace) term defined in [OData-VocCore](#ODataVocCore). For more information on default namespaces, see Default Namespaces in [OData-Protocol](#ODataProtocol). @@ -756,7 +756,7 @@ combined with the [`$filter`](#SystemQueryOptionfilter) system query option. ::: example -Example ##ex: red products that cost less than 10 -- combining path +Example ##ex: red products that cost less than 10 --- combining path segment and system query option ``` GET Products/$filter(@foo)?@foo=Price lt 10&$filter=Color eq 'red' @@ -764,7 +764,7 @@ GET Products/$filter(@foo)?@foo=Price lt 10&$filter=Color eq 'red' ::: ::: example -Example ##ex: red products that cost less than 10 -- combine two path +Example ##ex: red products that cost less than 10 --- combine two path segments ``` GET Products/$filter(@p)/$filter(@c)?@p=Price lt 10&@c=Color eq 'red' @@ -851,7 +851,7 @@ the corresponding entity set, with a target type equal to the declared entity type of the corresponding entity set. The [`$filter`](#SystemQueryOptionfilter) and -[`$orderby`](#SystemQueryOptionorderby)` `query options can be specified +[`$orderby`](#SystemQueryOptionorderby) query options can be specified using properties of the entities in the selected entity sets, prepended with the entity set as the navigation property name. diff --git a/odata-url-conventions/5 Query Options.md b/odata-url-conventions/5 Query Options.md index fa7224133..a71a06031 100644 --- a/odata-url-conventions/5 Query Options.md +++ b/odata-url-conventions/5 Query Options.md @@ -247,49 +247,49 @@ The following examples illustrate the use and semantics of each of the logical operators. ::: example -Example ##ex: all products with a `Name` equal to 'Milk' +Example ##ex: all products with a `Name` equal to `Milk` ``` http://host/service/Products?$filter=Name eq 'Milk' ``` ::: ::: example -Example ##ex: all products with a `Name` not equal to 'Milk' +Example ##ex: all products with a `Name` not equal to `Milk` ``` http://host/service/Products?$filter=Name ne 'Milk' ``` ::: ::: example -Example ##ex: all products with a Name greater than 'Milk': +Example ##ex: all products with a `Name` greater than `Milk`: ``` http://host/service/Products?$filter=Name gt 'Milk' ``` ::: ::: example -Example ##ex: all products with a Name greater than or equal to 'Milk': +Example ##ex: all products with a `Name` greater than or equal to `Milk`: ``` http://host/service/Products?$filter=Name ge 'Milk' ``` ::: ::: example -Example ##ex: all products with a Name less than 'Milk': +Example ##ex: all products with a `Name` less than `Milk`: ``` http://host/service/Products?$filter=Name lt 'Milk' ``` ::: ::: example -Example ##ex: all products with a Name less than or equal to 'Milk': +Example ##ex: all products with a `Name` less than or equal to `Milk`: ``` http://host/service/Products?$filter=Name le 'Milk'` ``` ::: ::: example -Example ##ex: all products with the Name 'Milk' that also have a Price +Example ##ex: all products with a `Name` equal to `Milk` that also have a `Price` less than 2.55: ``` http://host/service/Products?$filter=Name eq 'Milk' and Price lt 2.55 @@ -297,15 +297,15 @@ http://host/service/Products?$filter=Name eq 'Milk' and Price lt 2.55 ::: ::: example -Example ##ex: all products that either have the Name 'Milk' or have a -Price less than 2.55: +Example ##ex: all products that either have a `Name` equal to `Milk` or have a +`Price` less than 2.55: ``` http://host/service/Products?$filter=Name eq 'Milk' or Price lt 2.55 ``` ::: ::: example -Example ##ex: all products that do not have a Name that ends with 'ilk': +Example ##ex: all products that do not have a `Name` that ends with `ilk`: ``` http://host/service/Products?$filter=not endswith(Name,'ilk') ``` @@ -319,7 +319,7 @@ http://host/service/Products?$filter=style has Sales.Pattern'Yellow' ::: ::: example -Example ##ex: all products whose `name` value is 'Milk' or 'Cheese': +Example ##ex: all products whose `Name` is `Milk` or `Cheese`: ``` http://host/service/Products?$filter=Name in ('Milk', 'Cheese') ``` @@ -377,7 +377,7 @@ or `variable` if any operand has variable scale. The `sub` operator is also valid for the following time-related operands: -- `DateTimeOffset` `sub` `Duration` +- `DateTimeOffset sub Duration` results in a `DateTimeOffset` - `Duration sub Duration` results in a `Duration` @@ -586,7 +586,7 @@ The `containsMethodCallExpr` syntax rule defines how the `contains` function is invoked. ::: example -Example ##ex: all customers with a `CompanyName` that contains `'Alfreds'` +Example ##ex: all customers with a `CompanyName` that contains `Alfreds` ``` http://host/service/Customers?$filter=contains(CompanyName,'Alfreds') ``` @@ -618,7 +618,7 @@ function is invoked. ::: example Example ##ex: all customers with a `CompanyName` that ends with -`'Futterkiste'` +`Futterkiste` ``` http://host/service/Customers?$filter=endswith(CompanyName,'Futterkiste') ``` @@ -649,7 +649,7 @@ The `indexOfMethodCallExpr` syntax rule defines how the `indexof` function is invoked. ::: example -Example ##ex: all customers with a `CompanyName` containing '`lfreds'` +Example ##ex: all customers with a `CompanyName` containing `lfreds` starting at the second character ``` http://host/service/Customers?$filter=indexof(CompanyName,'lfreds') eq 1 @@ -707,7 +707,7 @@ The `startsWithMethodCallExpr` syntax rule defines how the `startswith` function is invoked. ::: example -Example ##ex: all customers with a `CompanyName` that starts with `'Alfr'` +Example ##ex: all customers with a `CompanyName` that starts with `Alfr` ``` http://host/service/Customers?$filter=startswith(CompanyName,'Alfr') ``` @@ -761,7 +761,7 @@ The `substringMethodCallExpr` syntax rule defines how the `substring` function is invoked. ::: example -Example ##ex: all customers with a `CompanyName` of `'lfreds Futterkiste'` +Example ##ex: all customers with a `CompanyName` of `lfreds Futterkiste` once the first character has been removed ``` http://host/service/Customers?$filter=substring(CompanyName,1) eq 'lfreds Futterkiste' @@ -769,8 +769,8 @@ http://host/service/Customers?$filter=substring(CompanyName,1) eq 'lfreds Futter ::: ::: example -Example ##ex: all customers with a `CompanyName` that has '`lf' `as the -second and third characters, e.g, '`Alfreds Futterkiste`' +Example ##ex: all customers with a `CompanyName` that has `lf` as the +second and third characters, e.g, `Alfreds Futterkiste` ``` http://host/service/Customers?$filter=substring(CompanyName,1,2) eq 'lf' ``` @@ -853,17 +853,17 @@ hassubsequence([1,2],[1,1,2]) #### ##subsubsubsec String Functions -##### ##subsubsubsubsec `matchesPattern` +##### ##subsubsubsubsec `matchespattern` -The `matchesPattern` function has the following signature: +The `matchespattern` function has the following signature: ``` -Edm.Boolean matchesPattern(Edm.String,Edm.String) +Edm.Boolean matchespattern(Edm.String,Edm.String) ``` The second parameter MUST evaluate to a string containing an [**[ECMAScript]**](#ECMAScript) (JavaScript) regular expression. The -`matchesPattern` function returns true if the first parameter evaluates +`matchespattern` function returns true if the first parameter evaluates to a string matching that regular expression, using syntax and semantics of [**[ECMAScript]**](#ECMAScript) regular expressions, otherwise it returns false. @@ -872,7 +872,7 @@ returns false. Example ##ex: all customers with a `CompanyName` that match the (percent-encoded) regular expression `^A.*e$` ``` -http://host/service/Customers?$filter=matchesPattern(CompanyName,'%5EA.*e$') +http://host/service/Customers?$filter=matchespattern(CompanyName,'%5EA.*e$') ``` ::: @@ -891,7 +891,7 @@ function is invoked. ::: example Example ##ex: all customers with a `CompanyName` that equals -`'alfreds futterkiste'` once any uppercase characters have been +`alfreds futterkiste` once any uppercase characters have been converted to lowercase ``` http://host/service/Customers?$filter=tolower(CompanyName) eq 'alfreds futterkiste' @@ -913,7 +913,7 @@ function is invoked. ::: example Example ##ex: all customers with a `CompanyName` that equals -`'ALFREDS FUTTERKISTE'` once any lowercase characters have been +`ALFREDS FUTTERKISTE` once any lowercase characters have been converted to uppercase ``` http://host/service/Customers?$filter=toupper(CompanyName) eq 'ALFREDS FUTTERKISTE' @@ -1405,8 +1405,8 @@ expression case(Edm.Boolean:expression, ..., Edm.Boolean:expression) ``` Each parameter is a pair of expressions separated by a colon (`:`), -where the first expression -- the condition -- MUST be a Boolean -expression, and the second expression -- the result -- may evaluate to +where the first expression --- the condition --- MUST be a Boolean +expression, and the second expression --- the result --- may evaluate to any type. The case function evaluates the condition in each pair, starting with @@ -1793,7 +1793,7 @@ http://host/service/Employees?$filter=@Core.Messages/any(m:m/severity eq 'error' Services MAY additionally support the use of the unqualified term name by defining one or more default namespaces through the -[`Core.DefaultNamespace`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#DefaultNamespace)` `annotation +[`Core.DefaultNamespace`](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Core.V1.md#DefaultNamespace) annotation term defined in [OData-VocCore](#ODataVocCore). For more information on default namespaces, see Default Namespaces in [OData-Protocol](#ODataProtocol). This short notation however uses the same name pattern as parameter @@ -1850,9 +1850,9 @@ rules, in order: - If either operand is `Edm.Double`, the other operand is converted to type `Edm.Double`. - Otherwise, if either operand is `Edm.Single`, the other operand is converted to type `Edm.Single`. - Otherwise, if either operand is of type `Edm.Decimal`, the other operand is converted to `Edm.Decimal`. -- Otherwise, if either operand is `Edm.Int64`, the other operand is converted to type `Edm.Int64.` -- Otherwise, if either operand is `Edm.Int32`, the other operand is converted to type `Edm.Int32.` -- Otherwise, if either operand is `Edm.Int16`, the other operand is converted to type `Edm.Int16. ` +- Otherwise, if either operand is `Edm.Int64`, the other operand is converted to type `Edm.Int64`. +- Otherwise, if either operand is `Edm.Int32`, the other operand is converted to type `Edm.Int32`. +- Otherwise, if either operand is `Edm.Int16`, the other operand is converted to type `Edm.Int16`. Each of these promotions uses the same semantics as a `castExpression` to promote an operand to the target type. @@ -2067,7 +2067,7 @@ Specifying `$value` for a media entity includes the media entity's stream value inline according to the specified format. ::: example -Example ##ex: Include the `Product`'s media stream along with other +Example ##ex: Include the Product's media stream along with other properties of the product ``` http://host/service/Products?$expand=$value @@ -2466,7 +2466,7 @@ http://host/service/Movies?$filter=Title eq @title&@title='Wizard of Oz' ::: ::: example -Example ##ex: JSON array of strings as parameter alias value -- note that +Example ##ex: JSON array of strings as parameter alias value --- note that `[`, `]`, and `"` need to be percent-encoded in real URLs, the clear-text representation used here is just for readability ``` diff --git a/odata-url-conventions/Appendix.md b/odata-url-conventions/Appendix.md index a0989b4c7..e95b448c6 100644 --- a/odata-url-conventions/Appendix.md +++ b/odata-url-conventions/Appendix.md @@ -39,14 +39,15 @@ _OData Vocabularies Version 4.0: Core Vocabulary._ See link in "[Related work](#RelatedWork)" 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_. 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", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005_. +https://www.rfc-editor.org/info/rfc3986. ###### [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. ###### [XML-Schema-2] @@ -63,7 +64,7 @@ https://www.ecma-international.org/publications-and-standards/standards/ecma-262 # Appendix ##asec Safety, Security and Privacy Considerations -TODO: do we have considerations specific to URLs, for example length, encoding, privacy (use $batch if in doubt), ...? + ------- diff --git a/package.json b/package.json index 33ce27150..3b3813213 100644 --- a/package.json +++ b/package.json @@ -2,7 +2,7 @@ "name": "odata-specs", "version": "1.0.0", "description": "", - "main": "number.js", + "main": "lib/server.js", "scripts": { "build": "node lib/build.js", "pdf": "node lib/build-pdf.js",
    hassubset
    hassubset([4,1,3],[3,1])
    hassubsequence
    hassubsequence([4,1,3,1],[1,1])
    String Functions
    matchesPattern
    matchesPattern(CompanyName,'%5EA.*e$')
    matchespattern
    matchespattern(CompanyName,'%5EA.*e$')
    tolower
    tolower(CompanyName) eq 'alfreds futterkiste'
    toupper
    toupper(CompanyName) eq 'ALFREDS FUTTERKISTE'
    trim
    trim(CompanyName) eq 'Alfreds Futterkiste'