[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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").
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,
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:
a.Address Errata as they come up
b.Progress OData V4 Errata 2 to ISO
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
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
a.Is performance suitable for specific scenarios
b.What optimizations can we apply *where needed*
5.Investigate HTTP 2.0
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 email@example.com.)
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 firstname.lastname@example.org.
To post to this group, send email to email@example.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]
Here  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 . For TC timeline, see . Feel free to suggest additions or modifications.
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]
a. Mike will present summary of last meeting’s discussion
b. Classify issues for OData V4.1 as
i. AdoptionBlocker – recurring issue, not just nice to have
ii. Clarification – definition needed but can’t be added in Errata
iii. Extension – something that the V4 spec allows but doesn't describe
iv. GoodIdea – not yet reported as an issue by (potentiaI) adopters
v. Usability – helpful for client developers
6. Process issues [Issues list: https://issues.oasis-open.org/issues/?jql=project%20%3D%20ODATA] [9:30am PT]
i. OData CSDL
ii. OData JSON Format
7. Next meeting [9:50am PT]
a. Thursday June 18, 2015 during 8-10am PT?
8. AOB and wrap up [9:55am PT]
· Conference call details: https://www.oasis-open.org/apps/org/workgroup/odata/download.php/46401/TC%20meeting%20dial-in%20details.htm
· Chat room: http://webconf.soaphub.org/conf/room/odatatc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]