OData meeting in Littleton, MA, USA #15 F2F, Thursday, 08 Nov 2012, 0900 - 1800 EST and Friday, 09 Nov 2012, 0900 - 1800 EST

Day One

Meeting chaired by Barabara Hartel and Ram Jeyaraman

Acting chair: Barabara Hartel

1. Roll call

1.1 Members Present:

    Andrew Eisenberg (IBM)
    Anila Kumar GVN (CA Technologies)
    Barbara Hartel (SAP AG)
    Colleen Evans (Microsoft)
    Dale Moberg (Axway Software)
    Diane Downie (Citrix Systems)
    Gerald Krause (SAP AG)
    Hubert Heijkers (IBM)
    Jeffrey Turpin (Axway Software)
    John Willson (Individual)
    Ken Baclawski (Northeastern University)
    Martin Zurmuehl (SAP AG)
    Matthew Borges (SAP AG)
    Michael Pizzo (Microsoft) a.k.a. Mike
    Ralf Handl (SAP AG)
    Ram Jeyaraman (Microsoft)
    Robert Richards (Mashery)
    Stefan Drees (Individual)
    Susan Malaika (IBM)
    Ted Jones (Red Hat)

Quorum achieved. Details cf. normative attendance sheet for this meeting.

2. Approval of Agenda

Review and make necessary adjustments to the draft agenda based on progress made on issues and proposals.

Discussion:

Mike Pizzo is writing the following proposal topics on the white board

  1. Aggregation
  2. Delta queries
  3. New JSON
  4. Relationship simplification
  5. Data Time issues
  6. Enums
  7. Issues in JIRA

Mike is suggestion that 3. New JSON format be discussed tomorrow. The proposal will be uploaded today.

Here is a proposed order for discussion today:

  1. Aggregation
  2. Delta queries
  3. Data Time issues
  4. Other JIRA issues in Proposed state

Items 1. and 2. above planned for discussion before lunch break. 3. and 4. are planned for after lunch break.

Otherwise agenda approved as published.

3. Approval of Minutes from Previous Meeting(s)

3.1 Approval of Minutes of 2012–11–01 Meeting#14:

Meeting minutes approved with no objections.

4. Review of Action Items (AI) and Progress

Context: The ownership of action items is noted [owner: Given Family] and as indicated by AI-List-Tool retrieved 2012-11-08 14:15 +02:00.

AI#0003
“Come up with examples / usecases (and proposals) for open types and document annotation for JSON extensions document” [owner: Susan Malaika] is Ongoing (Note: Due 2012–11–05)
AI#0005
“Come up with a first milestine for the temporal extension” [owner: Andrew Eisenberg] is Ongoing (Note: Due 2012–11–09)
AI#0006
“Come up with estimate for first milestone for XML data extension” [owner: Andrew Eisenberg] is Ongoing (Note: Due 2012–11–09)
AI#0007
“Come up with estimate for first milestone for JSON data extension” [owner: Susan Malaika] is Ongoing (Note: Due 2012–11–09)
AI#0008
“Recording of TC meetings” [owner: Hubert Heijkers] is Ongoing (Note: Due 2012–11–05)
AI#0017
“Prepare Working Draft 01 (WD01) version of OData Extension for Data Aggregation” [owner: Ralf Handl] is Ongoing (Note: Due 2012–11–02) {already closed by owner on 2012–11–02}
AI#0018
“Prepare Working Draft 01 (WD01) version of OData Extension for Temporal Data” [owner: Andrew Eisenberg] is Ongoing
AI#0019
“Prepare Working Draft 01 (WD01) version of OData Extension for XML Data” [owner: Andrew Eisenberg] is Ongoing
AI#0020
“Prepare Working Draft 01 (WD01) version of OData Extension for JSON Data” [owner: Susan Malaika] is Ongoing
AI#0026
“Detail a proposal with regard to enumerations” [owner: Mike Pizzo] is Ongoing (Note: Due 2012–11–15)

4.1 Action items due by 2012–11–08 (end of day)

4.1.1 AI#0017

AI#0017
“Prepare Working Draft 01 (WD01) version of OData Extension for Data Aggregation” [owner: Ralf Handl] is closed (Note: Due 2012–11–02)

4.1.2 AI#0008

AI#0008
“Recording of TC meetings” [owner: Hubert Heijkers] is closed (Note: Due 2012–11–05)

4.1.3 AI#0003

Discussion:

AI#0003
“Come up with examples / usecases (and proposals) for open types and document annotation for JSON extensions document” [owner: Susan Malaika] is Ongoing (Note: Due 2012–11–05)

4.2 Action items NOT due by 2012–11–08 but MAY be ready for closure

None.

5 Discuss new proposals Part A

5.1 Aggregation

5.1.1 Presentation

Discussion:

In presenting slide 13, Ralf lists the open topics w.r.t Aggregation:

5.1.2 Working Draft

Now through a shared screen session the new revision of the working draft OData Extension for Data Aggregation from 2012–11–07 is discussed.

Discussion:

Context “3.1 $aggregate”:

Context 3.1.2.2.2 Aliasing:

(A short break)

Discussion (continued):

Context “3.1.2.2.5 The Standard Aggregation Function distinctCount”:

Context “3.2 $rollup”:

Context “3.4 Processing Sequence”:

Further on (More examples):

Further on (Now enter $rollup"):

(One hour lunch break)

Context “3.5 Cross-Joins”:

Context “4.1 Aggregatable Properties”:

Context “4.3 Hierarchies”:

Context “4.4 Functions and Actions on Aggregated Entities”:

Barbara asks if there is general agreement on the work in progress or if there are major concerns?

All: Agree that this is a work in progress and that there are no major concerns.

Updates:

5.2 Delta queries

5.2.1 Presentation

Mike first shows some slides in this regard from the first face to face, then switches to document for details

Discussion:

Context is slide 7 “Deltas and Query Options”:

(short fifteen minutes break)

In closing Mike lists the open issues:

5.2.2 OData Delta Query Protocol Design

Discussion:

Context is page 2 (section “Query Operators in Initial Query”):

Context is page 3 (section “Query Operators in Delta Queries” third paragraph starting with The client can compose …):

Context is page 7 in live edited document (Atom format response sample):

Context is still page 7 in live edited document (Focus on request part of relationship request sample):

Barbara asks if there is general agreement on the work in progress or if there are major concerns?

All: Agree that this is a work in progress and that there are no major concerns but main use case shall be named to check the scenarios.

Noted question also: How do we process results from separate queries?

It has been noted, that $inlinecount on delta result includes tombstone

Diane: $expand will cause multiple delta queries to be returned to process the set and relation changes. presumably the consumer would process run those deltas in batch. How would the consumer process those multiple set of changes in order when you have 3 distinct sets of changes.

(Proposed to start tomorrow’s meeting with JSON Format)

6 Agenda for tomorrow

09:00 EST Review and approve agenda for day 2

09:10 EST Review action items

09:30 EST Discuss new proposals: New JSON Format

10:30 EST Break

10:45 EST Discuss new proposals: Relationship Simplification

12:30 EST Lunch

01:30 EST Async

02:00 EST Simple Type

02:30 EST Enums,

03:00 EST Break

03:15 EST Scoping and URL Issues 32/36/38/73

03:45 EST Review TC timeline and next steps

04:30 EST AOBand wrap up

06:00 EST End

Susan on action item iii.#0003: Come up with examples / usecases (and proposals) for open types and document annotation for JSON extensions document

7 AOB

None.

Thursdays’ Meeting adjourned on 1800 EST.

Day Two

Meeting day chaired by Barabara Hartel and Ram Jeyaraman

Acting chair: Ram Jeyaraman

Meeting Details cf. event page for this meeting day.

8 Approval of Agenda for Day Two

At the end of day one meeting of the two days event #15 it has been proposed to proceed today as follows (estimated start times in 24 hour format):

09:00 EST Review and approve agenda for day 2

09:10 EST Review action items

09:30 EST Discuss new proposals: New JSON Format

10:30 EST Break

10:45 EST Discuss new proposals: Relationship Simplification

12:30 EST Lunch

13:30 EST Async

14:00 EST Simple Type

14:30 EST Enums

15:00 EST Break

15:15 EST Scoping and URL Issues 32/36/38/73

15:45 EST Review TC timeline and next steps

16:30 EST AOBand wrap up

18:00 EST End

Discussion:

Otherwise agenda approved as published.

9 Discuss new proposals Part B

9.1 New JSON Format

9.1.1 Working Draft

Mike presents the current working draft in a screen shared session.

Discussion:

Context is page 7 section “Property”:

Context is how NULL values are represented in the response as well as the reason for needing to do that to differentiate with values of a property that might be called ‘value’ in a complex type that by themselves might be null again. The base reason there is because we no longer have the value property in every response (as we used to have the “d” property):

Ram asks if there is general agreement on the work in progress as being on the right track or if there are major concerns?

All think that yes.

(short ten minutes break)

10. Review of Action Items (AI) and Progress

10.1 Action items due by 2012–11–09 (end of day)

10.1.1 AI#0005

Discussion:

AI#0005
“Come up with a first milestine for the temporal extension” [owner: Andrew Eisenberg] is Ongoing (Note: Due 2012–11–09)

10.1.2 AI#0006

Discussion:

AI#0006
“Come up with estimate for first milestone for XML data extension” [owner: Andrew Eisenberg] is Ongoing (Note: Due 2012–11–09)

10.1.3 AI#0007

Discussion:

AI#0007
“Come up with estimate for first milestone for JSON data extension” [owner: Susan Malaika] is Ongoing (Note: Due 2012–11–09)

10.1.4 AI#0003

Discussion:

AI#0003
“Come up with examples / usecases (and proposals) for open types and document annotation for JSON extensions document” [owner: Susan Malaika] is Ongoing (Note: Due 2012–11–19)

11 Discuss new proposals Part C

11.1 Association Simplification

11.1.1 Presentation

Mike presents the slides from first face to face meeting.

Discussion:

Proposed is to adapt a future version of the OData CSDL to these simplified associations.

(One hour lunch break)

11.2 Async

11.2.1 Presentation

Martin presents the topic from scratch. Mike produces some live text for persistent storage.

Discussion:

Context is HTTP header “Prefer: respond-async, wait=10”:

References:

Header: draft-snell-http-prefer–17 J. Snell ‘Prefer Header for HTTP’, Internet-Draft, 2012–11–05, Expires: May 9, 2013

delta-seconds (for wait): draft-ietf-httpbis-p2-semantics–21 R. Fielding and J. Reschke (Eds.) ‘Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content’, Internet-Draft, 2012–10–04, Expires: April 7, 2013

cancel fails/succeeds: draft-nottingham-http-problem–01 M. Nottingham ‘Indicating Details of Problems to Machines in HTTP’, Internet-Draft, 2012–09–13, Expires: March 17, 2013

For opinions on if Retry-After header is allowed in a HTTP 202 response see mail thread in W3C’s public ietf-http-wg mailing list 202 Accepted, Location, and Retry-After and follow all responses, esp. branches like: Filling out 202 Accepted.

Further discussion on procedures/steps:

— Use version –17 of the RFC draft. http://tools.ietf.org/html/draft-snell-http-prefer–17 The prefer tokens have been renamed from “return-asynch” … now it’s “respond-async”

(a)

Question: For use response is there any preference? returning 202 accepted? use link header for monitor URL? Is this reasonable?

Answer: Yes ; Link: <http://.../monitor> (http://.../monitor%3E); rel="monitor" then GET http://.../monitor can also return 202 Acceptedif the processing is not yet complete until it’s done.. at which time it returns the final response

(b)

Question: When polling the monitor … return 200 or 204 …… using a link header to determine the eventual location of final outcome?

Answer: Yes, that would work great. There is a Retry-After response header I believe that you can use to specify how often to poll

(c)

Question: What rel do we use in the link header to access the final outcome?

Answer: You can use “canonical” or possibly “self”. “via” is OK but a bit weird. “via” is more for a forwarding intermediary as in referencing the original source of information “I got this information via so-n-so”

(d)

Question: Is the best way to tell the async operation has completed by the presence of the link header?

Answer: HTTP status code. If client does a GET on http://.../monitor and the process is not yet complete, Return a 202 with the Link header pointing back to the same monitor. If the process is complete, consider doing a redirect to the final location like 302 Found, with the Location header giving the final location.

Follow-up-question: Does that allow for redirect of monitor?

Answer: Someone would need to understand how to handle 202, since 202 is a success response, you can, for instance, return html that includes an auto-refresh statement. So if the client is a browser, it will autorefresh to check status, then will automatically redirect to the final location when complete. Using 202 Accepted when GETting the monitor url will avoid accidentally sending clients into a redirect loop so we are talking monitor redirect. The flow would look like…

Request_0:

POST /foo

Response_0:

202 Accepted

Link: <http://.../monitor> (http://.../monitor%3E); rel="monitor"

Request_1:

GET http://.../monitor

Response_1:

202 Accepted

Retry-After: 10

Link: <http://.../monitor> (http://.../monitor%3E); rel="monitor"

Request_2:

GET http://.../monitor

Response_2:

202 Accepted

Retry-After: 10

Link: <http://.../monitor> (http://.../monitor%3E); rel="monitor"

Request_3:

GET http://.../monitor

Response_3:

302 Found

Location: http://.../foodone

The first two GET’s return 202 Accepted. The client see’s that and just tries again after 10 seconds. The third attempt results in a 302 Redirect. 303 could work too. Either 303 or 302.

(e)

Question: Have you considered canceling async operations? would DELETE monitor be appropriate for that?

Answer: Yes, that would work great so long as the monitor URL is specific to that one async operations e.g. DELETE http://.../monitor/123 where 123 is like a process ID… doing a GET on the monitor url can return a status resource too.. along with the 202 Accepted.

(f)

Question: What status code should be used when a request (async or otherwised) has been canceled?

Answer: 200 OK or 204 No Content

Follow-up question: That’s from the DELETE request - what about from the cancel request?

Answer: DELETE /monitor/123 would cancel that process… response would be 200 or 204

(g)

Question: What happens when a regular http request is canceled out of band - what code is returned? e.g., an admin killed the server thread that was executing the request generated from the browser HTTP request

Answer: I would expect just to get a 404 back. When I try to GET the monitor … it would say 404 and possibly include some html that gives a detailed explanation

(h)

Question: Can a delete to the monitor return a 202?

Answer: Sure. why not? If the process cannot be deleted right away, then the cancelation could be async also

(i)

Question: Consider two cases (1) If the cancel fails - what happens (2) if the cancel fails - what happens (2) if the cancel succeeds what happens

Answer: For (1).. imagine a flow like…

Request_1:

DELETE /monitor/123

Response_1:

202 Accepted

Link: <http://.../delete/monitor> (http://.../delete/monitor%3E); rel="monitor"

Request_2:

GET http://.../delete/monitor

Response_2:

302 Found

Location: http://.../delete/status

Request_3:

GET http://.../delete/status

Response_3:

4xx Failed

Content-Type: application/json

{"status": "process could not be canceled"}

basically, the monitor would complete as expected, returning a 302 to the final status URL doing a GET on that URL would return something like a 4xx that indicates that the original request failed and could contain a resource that describes why it failed

For (2) … when I do GET http://.../delete/status, it would return 204 No Content to indicate success

Follow-up question: for (1) would I do a GET on monitor/123 to monitor the original operation?

Answer: Yes - if you cancel is asynchronous, you have to assume that the original monitor is still active and valid until the process is successfully canceled or completed. Once the cancelation is complete, doing a GET on the original monitor url would return a 404 If cancelation does not complete, doing a GET on the original monitor url would continue acting as if cancelation was never requested I’ve been wanting to write all this up in detail. haven’t had the chance… I probably should go ahead and do it.

(j)

Question: How do you distinguish 404 cancel and 404 not found on original monitor?

Answer: Strictly speaking you wouldn’t really need to… the end result is the same in either case… nothing to monitor anymore.. but if you needed that level of detail, a resource could be included in the response that describes what happened something like this: http://tools.ietf.org/html/draft-nottingham-http-problem–01 could be used to describe the specific circumstances of the 404

In conclusion the next steps are further fleshing out a proposal.

Update:

Mike will edit the discussion document for readability and upload it into kavi.

(short ten minutes break)

12 Review TC timeline and next steps [TL_REF]

Context:

List and Diagram

Discussion:

13 Scoping and URL Issues 32/73/36/144/38

Discussion:

13.1 ODATA–32

ODATA–32
“Allow filtering of expanded to-many navigation properties” [components: OData Protocol, OData URL Conventions] is Open.

Discussion:

Hubert:

I move to resolve OData issue 32 as proposed. Mike seconds.

No further discussion. No objections. The motion passes.

ODATA–32
“Allow filtering of expanded to-many navigation properties” [components: OData Protocol, OData URL Conventions] is proposed with no objections.

13.2 ODATA–73

ODATA–73
“Retrieve the count of related entities together with the base entity” [component: OData URL Conventions] is New.

Mike:

I move we close ODATA–73 as resolved by ODATA–32. Martin seconds.

No further discussion. No objections. The motion passes.

ODATA–73
“Retrieve the count of related entities together with the base entity” [component: OData URL Conventions] is closed with no objections.

13.3 ODATA–36

ODATA–36
“Make $expand implicit if navigation properties are mentioned in $select or $aggregate” [components: OData Protocol, OData URL Conventions] is New.

Ralf:

I move to close ODATA–36. Martin seconds.

No further discussion. No objections. The motion passes.

ODATA–36
“Make $expand implicit if navigation properties are mentioned in $select or $aggregate” [components: OData Protocol, OData URL Conventions] is closed with no objections.

13.4 ODATA–144

ODATA–144
"“‘Scoping’ syntax for $select and $aggregate”" [component: OData URL Conventions] is New.

Discussion: * New comment created during meeting (2012–11–09) by Mike in updating the proposal saying that the issue (as before the meeting) is no longer relevant

Hubert:

I move to resolve ODATA–144 as proposed. Ralf seconds.

No further discussion. No objections. The motion passes.

ODATA–144
"“‘Scoping’ syntax for $select and $aggregate”" [component: OData URL Conventions] is closed with no objections.

13.5 ODATA–38

ODATA–38
“Recursive $expand and $select” [components: OData Protocol, OData URL Conventions] is New.

Discussion:

Stefan:

I move to resolve ODATA–38 as proposed. Mike seconds.

No further discussion. No objections. The motion passes.

ODATA–38
“Recursive $expand and $select” [components: OData Protocol, OData URL Conventions] is proposed with no objections.

14 Next meeting (phone call/conference)

Next phone call/conference will be on 2012–11–29, since it has been decided to not have a TC meeting in the week after the face-to-face and the week thereafter skipped due to holidays.

15 AOB

None.

Meeting adjourned on 17:46 EST.

Appendices

Timeline Reference

Goal:

Deliver core Work Products as close as possible to the timeline mentioned in the TC charter and extension Work Products soon after.

Note:

The purpose of this timeline exercise is to create a map of the future milestones (based on current knowledge) and lay out a probable path for traversing the various future milestones. As with all things, there are unknowns that may stretch the timeline. For example, what if there are many public comments? What if it takes more time for the TC to address existing and as yet unknown issues? Those unknowns may stretch the timeline in terms of having to produce multiple Committee Specification Drafts until we address all the issues and feel confident to advance the Work Products to Committee Specification.

Draft timeline for core Work Products:

Draft timeline for extension Work Products: