1 / 15

OASIS OData Technical Committee

OASIS OData Technical Committee. Agenda. Introduction OASIS OData Technical Committee OData Overview Work of the Technical Committee Q&A. OASIS Odata Technical Committee. OASIS OData Technical Committee Announcement May 24, 2012

abram
Download Presentation

OASIS OData Technical Committee

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OASIS OData Technical Committee

  2. Agenda • Introduction • OASIS OData Technical Committee • OData Overview • Work of the Technical Committee • Q&A

  3. OASIS Odata Technical Committee • OASIS OData Technical Committee Announcement May 24, 2012 • Supporters: Microsoft, IBM, SAP, Citrix, WS02, Progress, CA, Red Hat • Microsoft contributed OData version 3.0 specs • Schedule • Call for participation June 11th • First meeting July 26-27th in Redmond, WA • Members must join by July 19th to vote at first meeting • Charter proposes ~12 months to Standardize • More information on joining the OASIS OData Technical Committee • https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=odata

  4. OData Overview

  5. Open Data Protocol (OData) A common, open, REST-ful Web protocol for querying and updating data that provides a uniform way to unlock data and free it from silos that exist in applications today.

  6. OdataPrinciples Build On REST Principles Resource-oriented Entities modeled as Resources Relationships modeled as links CRUD = POST, GET, PUT/PATCH, DELETE Hypermedia-driven Navigate from Service Document to Sets to Members to related items to… Links in Payload for editing, navigation, operations, etc. Model-based URLs, operations, namespaces, derived from declarative model Build on Existing Formats ATOM, JSON

  7. Odata Entity Data Model • Entities • Named structures with keys • Inheritance • Properties • String, Integer, Boolean, DateTime, Spatial datatypes • Collections, Complex Types • Stream Properties • Dynamic Properties • Relationships • Expose navigation paths

  8. Odata Semantics • Query • Basic filter, sort, projection • Built-in functions • Client/Server paging • Expand • Navigation • Hyper-media driven relationship links in payload • Data Modification • POST – a new entity to a collection • PUT/PATCH – to an edit URL to update a retrieved entity • DELETE – to an edit URL to delete an entity • Batch Operations • Single request, group requests into atomic “changesets”

  9. Extensibility • Custom Actions • Side-effecting operations that may or may not return a value • May be exposed on instances (Hypermedia-driven) • Custom Functions • Extend query language • May be exposed on instances (Hypermedia-driven) • Metadata Annotations • Extend the metadata language • Instance Annotations • Add additional information to the payload

  10. Vocabularies • Shared annotation terms • Type or Value terms • Common Extensions • Capabilities, Display, etc. • Ontologies • Shared schemas • Include data and operations

  11. Work of Technical Committee • Address issues, comments, errors in submitted documents • Extend OData to support: • Deltas • Servers return “delta link” that can be used to fetch changes to a result • Analytic Data • Add $aggregate, $rollup to query • Join support (queries rooted at EntityContainer) • Annotations for “measures”, hierarchies, dimensions, etc. • Temporal Data • Functions to query “as of” a particular application/system time or time range • Annotate columns that represent “from” and “to” time validity • Operations against XML, JSON streams • Specify content type for streams • Define operations on well known content types • Simplified JSON Format • Describe metadata through a common instance annotation mechanism • Leverage templating to remove redundant metadata information from payload

  12. OData Extension Design Principles • Keep it Simple! • Support common scenarios without trying to implement every possible variation • Model the concepts you want the clients to consume • Push modeling complexity to the service • Hypermedia-driven • Follow REST principles wherever possible, deriving semantics from exposed Data Model • Make Extensions Incremental • Extensions must not violate core semantics of OData • Client libraries that don’t understand the extensions should still work • Clients that do understand the extensions can have a richer experience • Be Consistent • Consistency/reuse across core/extensions enhances simplicity

  13. Get Involved! • Join the OASIS OData Technical Committee: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=odata • Submit comments to the OASIS OData Mailing List: https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=odata • Participate in the OData Community http://www.odata.org

  14. Q & A

More Related