RE: [odata] Agenda for OData TC meeting on 2015-06-11

Room information was updated by: Stefan

Please register yourself at https://www.oasis-open.org/apps/org/workgroup/odata/event.php?event_id=39102 - thanks.

Stefan: Info: Voting Members: 3 of 14 (21%) (used for quorum calculation)

Martin Zurmuehl: Can you please register me? Can't log in.

anonymous morphed into Mark Biamonte (Progress)

Stefan: Info: Voting Members: 8 of 14 (57%) (used for quorum calculation) (including Martin)

Stefan: @Ralf: Stefan has trouble calling in will try again in a few minutes ...

Ralf Handl (SAP): Germany, Bad Homburgtel:+496172661299,,8541568#

Ralf Handl (SAP): Who else has dial-in problems?

Ralf Handl (SAP): Currently I can only hear Martin and Hubert

Ralf Handl (SAP)1: 2.Approve agenda [8:05am PT]

Ralf Handl (SAP)1: Agenda is approved

Ralf Handl (SAP)1: 3.Approve minutes from previous meeting(s) [8:10am PT]

Ralf Handl (SAP)1: a.Minutes from May 21, 2015 TC meeting: https://www.oasis-open.org/committees/download.php/55712/odata-meeting-98_on-20150521-minutes.html

Ralf Handl (SAP)1: Minutes are approved

Ralf Handl (SAP)1: 4.Review action items [Action item list: https://www.oasis-open.org/apps/org/workgroup/odata/members/action_items.php] [8:15am PT]

Ralf Handl (SAP)1: a.Action items due

i.Follow up with JSON-Schema on use for modeling (Mike Pizzo)

Mike Pizzo: Sent the following to the JSON-Schema Google Group:

Mike Pizzo: Dear JSON Schema Community;

We would like to understand from the experts whether or not JSON Schema is appropriate for our particular use case.

OData is an OASIS standard that defines an interoperable protocol for clients to interact with RESTful services in a completely generic manner.

An important part of the protocol is the ability to describe the resources exposed by the service. OData uses an entity-relationship data model for describing these resources, and has defined an XML-based representation of this common data model (known as "CSDL").

OData uses a JSON representation for data payloads, and together with the growing popularity of JSON/_javascript_ clients, the OASIS OData Technical Committee (TC) has gotten numerous requests to provide a JSON representation of the data model as well as data payloads.

Given the significant overlap between describing a data model and validating the JSON payload returned from requests against the data model it is very tempting to use JSON Schema for both. In fact, we've seen other REST APIs, such as the DMTF "Redfish" specification, attempt to use JSON Schema to describe their resource model. However, in attempting to use JSON Schema to describe our data model we've run into a few issues that have caused us to question whether modeling is an appropriate use of JSON Schema.

So our question to the community is this:

Is JSON-Schema intended to be used for data modeling, or should we invest in an alternate "JSON Modeling" language that we would have first-class representation of concepts such as inheritance and relationships, and from which we could generate JSON Schema for validation?

We eagerly await your guidance in this area.

Thanks in advance,

Mike Pizzo

Editor, OASIS OData Technical Committee

anonymous morphed into Matt Borges (SAP)

Ralf Handl (SAP)1 morphed into Ralf Handl (SAP)

Mike Pizzo: Url for JSON-Schema Google Group: https://groups.google.com/forum/#!forum/json-schema

Ralf Handl (SAP): ii.Overview presentation on HTTP/2 features (Martin Zurmhl)

Ralf Handl (SAP): Martin will present next meeting

Ralf Handl (SAP): 5.TC Goals for next 12-18 months [8:30am PT]

Ralf Handl (SAP): a.Mike will present summary of last meetings discussion

Ralf Handl (SAP): Mike's mail:

Ralf Handl (SAP): Following are my notes from our discussion in our May 21, 2015 OASIS OData TC meeting regarding the goals and accompanying work items to focus on over the course of the next 12-18 months:

1.Maintain Standard:

a.Address Errata as they come up

b.Progress OData V4 Errata 2 to ISO

i.Demonstrate interoperability

2.Increase Adoption by:

a.Addressing technical adoption blockers/inhibitors

i.Targeted, highly-compatible OData 4.1 release

ii.JSON format for metadata

iii.Publish vocabulary to describe authentication flows

b.Making OData more approachable through:

i.Publishing a profile for simple REST services

ii.Producing webinars

iii.Publishing samples that begin at a simple starting point and incrementally walk through a scenario

iv.Publish "Implementing OData" whitepaper

c.Making OData service endpoints more discoverable

i.Establish an OData endpoint registry, for example, on OData.org

3.Extend the Protocol by

a.Publishing Aggregation Extensions for OData

b.Publishing Temporal Extensions for OData

4.Evaluate Performance

a.Is performance suitable for specific scenarios

i.i.e., Bulk-load

b.What optimizations can we apply *where needed*

i.Binary protocol

5.Investigate HTTP 2.0

a.Server PUSH

I suggest that the next step would be to prioritize and assign dates for each of the deliverables.

Ralf Handl (SAP): Hubert asks on what security-related topics we want to address

Ralf Handl (SAP): Mike: define a vocabulary for supported authentication methods and flows

Ralf Handl (SAP): Ralf: might need to be part of a Catalog because $metadata access already may require authentication

Ralf Handl (SAP): Mark: split metadata into "server metadata" and "schema metadata"

Ralf Handl (SAP): Mike: authentication is a barrier for interoperability

Ralf Handl (SAP): Mike: need a way to provide generic clients with the necessary information

Mike Pizzo: Email from odata-discussion google group on efforts to align Swagger with OData:

Mike Pizzo: FromSubjectReceivedSize

Mark Stafford[OData Discussion] Aligning Swagger and OData4/15/201560 KB

Mike Pizzo: We are working really hard to align Swagger and OData. We do sometimes forget to update our non-Microsoft friends with where were at, so thanks, Josh, for bringing this back up on another thread. Heres our current thinking  and please take it as current thinking, not roadmap commitments.

We have no philosophical objection to Swagger. Few of us like CSDL as a description format, but its clear that for OData to benefit from really terse payloads and still have rich support for types, relationships, etc, we do need a description of the model somewhere (JSON-LD does the same thing so were not alone in seeing this as a necessity).

There are some pretty big gaps at this point, though. Swagger doesnt support relationships, doesnt have semantics for query string parameters (so a computer cant tell which is the conceptual top parameter), cant tell you where the nextLink is in a response, etc. When I was last in the US (February) I had a great face-to-face conversation with Tony Tam about these points and Im happy to say that were very much on the same page  these would be great additions to Swagger. Since the acquisition, SmartBear has expressed similar interest in closing the gap.

The long term vision would be to allow every OData service to be well-described by Swagger. I mentioned previously that folks should watch our Github repo for news about a modeling tool. The specs for that tool are now public (https://github.com/odata/model-first/), and I think wed like to get some feedback on our thinking here.

The Swagger editor (http://editor.swagger.io) was what originally inspired us to kick off this initiative. We love the idea, but you just have to put so much YAML into the tool to get output. OData has a LOT of conventions that would theoretically enable you to put in a LOT less YAML in order to get the same amount of output, and unlike most Swagger docs, the output would be super consistent. So imagine in your head a tool that allows you to just describe the resource model for your REST API and the tool supplies the rest of the conventions and allows you to output Swagger, RAML, API Blueprint, or even eventually scaffold a proper OData service.

For clickstop #1 we are looking to keep things simple. We would support ingesting the YAML were proposing and outputting Swagger docs. We understand that wouldnt allow rich RESTful APIs to be modeled, but we think its enough to get feedback on whether the approach is helpful.

We  of course  think this tool could be pretty amazing, but what we really want to hear is what you, the OData community thinks. Thoughts?

(And just to preface any questions, we are  as mentioned  currently talking to the Swagger crew and weve kicked off a conversation with CA who seems to have something similar going at Who wants to try out an OData Extension. If theres anyone else we should work with as well, please feel free to connect me  you can reach me directly at mastaffo@microsoft.com.)

Thanks,

Mark

--

You received this message because you are subscribed to the Google Groups "OData Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to odata-discussion+unsubscribe@googlegroups.com.

To post to this group, send email to odata-discussion@googlegroups.com.

For more options, visit https://groups.google.com/d/optout

Ralf Handl (SAP): Prioritization

Susan Malaika (IBM): have to drop

Ralf Handl (SAP): Mike: review applied issues and working drafts next week

Ralf Handl (SAP): Hold documents back until October to see if V4.1 issues affect Errata03

Ralf Handl (SAP): Mike: demonstration of interoperability will help progression to ISO standard

Ralf Handl (SAP): Mike: schedule discussion on demonstration of interoperability

Ralf Handl (SAP): Meetings during Summer

Ralf Handl (SAP): Mike away July/August

Ralf Handl (SAP): Hubert away August

Matt Borges (SAP): I will be available for the whole summer, only missing the odd week

Ralf Handl (SAP): Hand off Aggregation spec for next public review in July

Ralf Handl (SAP): Gerald, Martin, Ralf to prepare Temporal spec for TC review in September

Ralf Handl (SAP): Version 4.1

Ralf Handl (SAP): Start work on WD01 in September, submit CSD01 in November for public review

Ralf Handl (SAP): JSON CSDL

Ralf Handl (SAP): Review in TC in September

Ralf Handl (SAP): REST Profile

Ralf Handl (SAP): Depends on V4.1

Ralf Handl (SAP): First draft in January 2016

Ralf Handl (SAP): b.Classify issues for OData V4.1 as

Mike Pizzo: I move we reassign all 4.1 issues with no label to 4.2

Martin Zurmuehl: I second

Ralf Handl (SAP): Motion passes

Ralf Handl (SAP): 6.Process issues [Issues list: https://issues.oasis-open.org/issues/?jql=project%20%3D%20ODATA] [9:30am PT]

Ralf Handl (SAP): a.Issues for V4.0_ERRATA03 in New or Open state

Ralf Handl (SAP): i.OData CSDL

Ralf Handl (SAP): 1.ODATA-819 10.2.2: Clarify whether enum types allow multiple members with the same value

Ralf Handl (SAP): ODATA-819 is OPEN

Ralf Handl (SAP): Postponed to next week

Ralf Handl (SAP): ii.OData JSON Format

Ralf Handl (SAP): 1.ODATA-815 Clarify that the values of the format parameters odata.metadata etc. are case-insensitive

Ralf Handl (SAP): ODATA-815 is OPEN

Mike Pizzo: I move we accept ODATA-815 as proposed

Matt Borges (SAP): I second

Ralf Handl (SAP): ODATA-815 is resolved as proposed

Ralf Handl (SAP): 7.Next meeting [9:50am PT]

Ralf Handl (SAP): a.Thursday June 18, 2015 during 8-10am PT?

Ralf Handl (SAP): Agreed

Ralf Handl (SAP): 8.AOB and wrap up [9:55am PT]

From: odata@lists.oasis-open.org [mailto:odata@lists.oasis-open.org] On Behalf Of Handl, Ralf
Sent: Mittwoch, 10. Juni 2015 18:26
To: odata@lists.oasis-open.org
Subject: [odata] Agenda for OData TC meeting on 2015-06-11

Here [1] is a draft agenda for the OData TC (Technical Committee) meeting scheduled on Thursday June 11, 2015 during 8-10am PDT (17:00-19:00 CEST). For additional information, such as dial-in details and chat room, refer to [2]. For TC timeline, see [3]. Feel free to suggest additions or modifications.

Thanks.

[1] Agenda

1. Roll call [8:00am PT]

a. Self-registration link: https://www.oasis-open.org/apps/org/workgroup/odata/event.php?event_id=39102

2. Approve agenda [8:05am PT]

3. Approve minutes from previous meeting(s) [8:10am PT]

a. Minutes from May 21, 2015 TC meeting: https://www.oasis-open.org/committees/download.php/55712/odata-meeting-98_on-20150521-minutes.html

4. Review action items [Action item list: https://www.oasis-open.org/apps/org/workgroup/odata/members/action_items.php] [8:15am PT]

a. Action items due

i. Follow up with JSON-Schema on use for modeling (Mike Pizzo)

ii. Overview presentation on HTTP/2 features (Martin Zurmühl)

5. TC Goals for next 12-18 months [8:30am PT]