1. Name of the TC

   OASIS Open Data Protocol (OData) Technical Committee (TC)

2. Statement of Purpose

   The purpose of the Open Data Protocol (OData) Technical Committee (TC) is to define an open data protocol for sharing data and exposing data models interoperably on the Web.

   The work will focus on enabling:

   • The creation of REST-ful HTTP-based data services, allowing resources identified using Uniform Resource Identifiers (URIs) and defined in an abstract data model, to be published and edited by Web clients using simple HTTP messages.
   • Exposure and access of information from a variety of sources including, but not limited to, relational databases, file systems, content management systems, and traditional Web sites.
3. Scope of Work

   The TC accepted the following OData V3 core specifications published on 27 April 2012 as the basis for its work:

   OData

   http://www.odata.org/media/30002/OData.html

   OData URL Conventions

   http://www.odata.org/media/30002/OData%20URL%20Conventions.html

   ABNF for OData

   http://www.odata.org/media/30002/OData%20ABNF.html

   OData Common Schema Definition Language (CSDL)

   http://www.odata.org/media/30002/OData%20CSDL%20Definition.html

   OData ATOM Format

   http://www.odata.org/media/30002/OData%20Atom%20Format.html

   OData Verbose JSON Format

   http://www.odata.org/media/30002/OData%20JSON%20Verbose%20Format.html

   Open Data Protocol (OData) Batch Processing

   http://www.odata.org/media/30002/OData%20Batch%20Processing%20Format.html

   And the following OData V3 extension contributions dated 18 May 2012 (see below for links):

   • OData Extension for Data Aggregation
   • OData Extension for Temporal Data
   • OData Extension for XML Data
   • OData Extension for JSON Data

   The TC will refine these initial contributions to produce OASIS standard specifications, including necessary supporting documentation.

   Other contributions will be accepted for consideration without any prejudice or restrictions and evaluated based on technical merit in so far as they conform to this charter.

   The scope of the TC's work is limited to technical refinements to the features defined in the input contributions and the following features and capabilities.

   The features in scope for the TC have been divided into the following categories:

   1. Core
   2. Extensions
   3. Considerations
   4. Patterns and Guidance

   The TC will focus on delivering the core functionality first, followed by extensions (including any necessary changes to core), followed by patterns and guidance and additional considerations, not precluding parallel work.

   1. Core

      Description of a Data-Oriented Service:

      • Description of the underlying entity model comprising:
        • Types of entities that may be returned from the service
          • Properties of entities that may be Simple types, Complex Types, Collections, Spatial types, Enumerations, Stream or navigation properties
          • Open entity types whose instances may expose properties not defined in metadata
        • Relationships between entities that may be returned from the service
        • Sets of entities that may be enumerated, queried, or inserted into
        • Nesting of sets of entities within other sets (containment scenarios)
        • Functions and Actions exposed by the service
        • Containers of sets, functions and actions exposed by the service
        • Additional annotations, such as visualization hints and updatability, which may be applied to metadata elements as well as individual data entries
      • Binding of a particular ontology provided by shared vocabularies to an entity or property description or instance
      • An addressing scheme for addressing metadata elements as required

      Interaction Semantics (request types and associated responses) for a REST-ful Data-Oriented Service:

      • Hypermedia-driven mechanisms for enumerating, navigating, and updating resources exposed by the service
      • Mechanisms to:
        • Retrieve entity sets, entries, service documents, individual properties, links between entities, and metadata and service documents
        • Navigate through responses split across multiple pages
        • Create new entries, media link entries
        • Update entries, individual properties
        • Delete entries
        • Create, remove, and replace links between entries
        • Invoke operations (functions and actions) on resources in the service
        • Retrieve changes (deltas) from a result, including tombstones for deleted or removed entries
        • Batch a group of requests to send to an OData service in a single request
      • Conventions for constructing URIs to obtain metadata, identify, query, and navigate resources exposed by an OData service
      • Conventions for querying resources exposed by the data-oriented service, including:
        • Select, Filter, OrderBy, Expand, Count, Top, Skip
        • Built-in String, Math, and Date functions
        • Custom functions
        • Any/All operations on collections
        • Filter by type, casting operators

      The core OData protocol shall be designed to support multiple formats. The TC will focus on specific representations for Data-Oriented Service request / response payloads in the following formats:

      • Atom (deprecated)
      • JSON
      • Other formats as appropriate, e.g. Binary or Compact

      Protocol Extensibility:

      • Versioning mechanism for understanding rules for processing requests/responses
      • Resiliency to future payload and URL convention extensions
      • Extensibility points for describing (i.e., through metadata annotations), invoking (i.e., through headers or URI extensibility), and representing (i.e., through payload extensibility) custom behaviors and content
      • Namespacing mechanism for vendor-specific extensions
   2. Extensions
      • Capabilities such as queryability/sortability defined through additional metadata.
      • Representation and semantics for aggregation of data supporting multidimensional modeling
        • Annotate entity sets and /or entity types with annotations representing analytic concepts such as dimensions, hierarchies, measures and key performance indicators
        • Define semantics and operations for querying aggregated data
        • Define results format for queries containing aggregated data
      • Representation and semantics for temporal data
        • Annotate entity sets and/or entity types as representing temporal data with application time periods and/or system time periods
        • Support querying temporal types as of a particular time or time range
        • Support operations on, navigating between, and updating of temporal entities
      • Retrieval and manipulation of properties representing XML documents in OData
        • Identify properties that represent XML documents using annotations
        • Define query and update operations over XML properties
      • Retrieval and manipulation of properties representing JSON documents in OData
        • Identify properties that represent JSON documents using annotations
        • Define query and update operations over JSON properties
   3. Considerations
      • Use of free text search across entities and entity sets and representation of results
   4. Patterns and Guidance
      • Patterns and guidance for how to do repeatable requests using OData
      • Guidance around data authorization model and secure authenticated access to an OData Service
      • Guidance for using OData endpoints with cross-origin access (e.g. CORS)
      • Prevention of Cross Site Request Forgery attacks (XSRF) when exposing OData endpoints
      • Improved client experience for OData consumers, e.g., for
        • auto-save functionality
        • user interactions spanning several requests
        • efficient use of delta payloads
        • handling of user messages
      • Profile(s) for applying OData constructs and patterns
      • Interoperability / co-existence with other Web API standards (OpenAPI, GraphQL, …)

   Out of Scope

   The following is a non-exhaustive list provided only for the sake of clarity. If some function, mechanism or feature is not mentioned here, and it is not mentioned as in-scope in the Scope of Work section, then it will be deemed to be out of scope.

   The following items are specifically out of scope of the work of the TC:

   • Mapping to models, representations or protocols not scoped above
   • Adding unnecessary complication to the protocol by extending beyond the scope described above or redefining mechanisms for authentication, encryption, security, cross-origin access, etc.
   • State based protocol

   Contributions to this TC which are out of scope for this charter may be accumulated and taken into consideration for potential development of a charter for another technical committee that may be created to address future extensions or modifications to OData.

4. List of Deliverables

   The TC has the following set of deliverables:

   • OASIS standards track OData core specification(s):
     • OData Protocol
     • OData Conceptual Schema Definition Language (CSDL)
     • OData ABNF Construction Rules
     • OData URL Conventions
   • OASIS standards track OData format specifications:
     • A JSON representation for OData request / response payloads
     • A Batch processing format
   • OASIS standards track OData extension specifications:
     • An OData extension defining the representation and semantics for aggregation of data supporting multidimensional modeling
     • An OData extension defining representation and semantics of temporal data
     • An OData extension defining retrieval and manipulation of properties representing XML documents in OData
     • An OData extension defining retrieval and manipulation of properties representing JSON documents in OData

   Optionally, such other non-standards track deliverables within the scope outlined above, such as tutorials or Committee Notes.

   Maintenance

   At such a time as the TC has completed producing deliverables, the TC will enter into a maintenance mode. The purpose of the maintenance mode is to provide minor revisions to previously adopted deliverables, in order to clarify ambiguities, inconsistencies, and obvious errors, define interoperability with other technologies, and support the community in documentation and tooling as appropriate. The maintenance mode may also functionally enhance a previously adopted deliverable, or extend its functionality.

5. IPR Mode

   This TC will operate under the "RF (Royalty Free) on RAND" IPR mode as defined in the OASIS Intellectual Property Rights (IPR) Policy effective 15 October 2010.

6. Anticipated Audience

   The anticipated audience for this work includes:

   • Vendors and service providers offering products that produce data services.
   • Vendors and application developers who consume data services.
   • Software engineers building distributed client/service architectures.
   • Software architects who design, write and deploy data producers and/or consumers.
   • End users implementing solutions that require an interoperable solution for querying and updating data.
7. Language

   TC business will be conducted in English. The output documents will be written in (US) English.

References

OData V3 extensions:

OData Extension for Data Aggregation:

http://www.oasis-open.org/committees/download.php/46084/ODataExtensionforDataAggregationv1.0.pdf

OData Extension for Temporal Data:

http://www.oasis-open.org/committees/download.php/46086/ODataExtensionforTemporalDatav1.0.pdf

OData Extension for XML Data:

http://www.oasis-open.org/committees/download.php/46087/ODataExtensionforXMLDatav1.0.pdf

OData Extension for JSON Data:

http://www.oasis-open.org/committees/download.php/46085/ODataExtensionforJSONDatav1.0.pdf