OData TC meeting #188 Thursday September 21, 2017

Acting chair: Ralf

Chat transcript from room: odatatc
2017-09-21 800-1000 PDT

1. Roll call

1.1 Members present

    George Ericson (Dell)
    Gerald Krause (SAP SE)
    Hubert Heijkers (IBM)
    Mark Biamonte (Progress Software)
    Martin Zurmuehl (SAP SE)
    Matthew Borges (SAP SE) a.k.a. Matt
    Michael Pizzo (Microsoft) a.k.a. Mike
    Ralf Handl (SAP SE)
    Ramesh Reddy (Red Hat)
    Stefan Hagen (Individual)
    Ted Jones (Red Hat)

Quorum achieved. Details cf. normative attendance sheet for this meeting (event_id=43996).

Notes taken by all and subsequently edited for readability by Stefan.

2. Approve agenda

Ralf: New issues:
- https://issues.oasis-open.org/browse/ODATA-1114 - If-Then-Else in $batch requests
- https://issues.oasis-open.org/browse/ODATA-1115 - Default values for $Precision and $Scale
Document walkthrough if time permits

Ralf: New issues added to section 5, document walkthrough as section 6

Agenda approved as published with above changes.

3. Approve minutes from previous meeting(s)

3.1 Minutes from September 14, 2017 TC meeting #187

https://www.oasis-open.org/committees/download.php/61567/odata-meeting-187_on-20170914-minutes.html

Minutes approved unchanged as published.

4. Review action items [Link to Action item list]

4.1 Action items due

None

5. Version 4.01 Public Review - 05 July 2017 to 03 August 2017 - Issues

5.1 ODATA-1111 - Structural properties: default for $Nullable is false in CSDL JSON feedback from implementation teams

Mike: feedback in favor of ODATA-1111, false is the better default

Ralf: mixed feedback, often surprise, but no real pushback

Ralf: fits better to SAP mainstream data models

5.2 ODATA-1115 - Default values for $Precision and $Scale

Ralf: $Precision does not have a default value, omission means arbitrary precision, both for Edm.Decimal (already the case) and for temporal types. The latter is in line with the "date-time" format of OpenAPI and JSON Schema for timestamps.

Ralf: $Scale defaults to "variable". This is in line with the "number" type of OpenAPI and JSON Schema.

Ralf: ODATA-1115 is OPEN

Hubert: I move to resolve ODATA-1115 as proposed. Martin seconds.

Ralf: ODATA-1115 is RESOLVED as proposed

5.3 ODATA-1109 - Clarify that 'parameter' aliases can also be used to substitute expressions

Ralf: Proposal:

Query parameters for $filter segment are always passed in as expressions (because that is the expected type of the parameter). All other parameters are evaluated in the context in which they are defined and passed as literals.

Open an issue to consider adding syntax for nesting parameters assignments within $expand (and, depending on ODATA-1105, to $select)

Mike: Revised proposal:
Query parameters for $filter segment are always passed in as expressions (because that is the expected type of the parameter). All other parameters are evaluated in the context in which they are defined and passed as literals, where "Context in which they are defined" is the resource identified by the path segment in which they are defined.

Add ability to nest parameters definitions within $expand, in which case they are relative to the resource context of the $expand. Also consider adding to $select when considering ODATA-1105

Mike: Revised wording:
Query parameters for $filter segment are always passed in as expressions (because that is the expected type of the parameter). All other parameters defined in query options are evaluated in the context of the resource identified by the path segment in which they are defined and passed as literals.

Add ability to nest parameters definitions within $expand, in which case they are relative to the resource context of the $expand. Also consider adding to $select when considering ODATA-1105

Mike: Revised/corrected:
Query parameters for $filter segment are always passed in as expressions (because that is the expected type of the parameter). All other parameters defined as query options are evaluated in the context of the resource identified by the URL path segment in which they are used and passed as literals.

Add ability to assign values to parameter aliases within $expand, in which case they are evaluated relative to the resource context of the $expand. Also consider adding to $select when considering ODATA-1105.

Mike: I move we resolve ODATA-1109 as proposed. Hubert seconds.

Ralf: ODATA-1109 is RESOLVED as proposed

5.4 ODATA-1105 - Simplify selection of properties of complex type

Ralf: Proposal:
Harmonize syntax for complex properties within $select with syntax for navigation properties within $expand:
- complex property can be followed by parentheses containing
- $expand nested in $select. - $select with same recursive syntax
- $compute to place computed properties within the complex type
- for collection-valued complex properties also $filter, $search, $count, $orderby, $skip, and $top within the parentheses

Extended $select syntax also allowed for $select nested within $expand.

Mike: add:
- support assigning values to parameter aliases within $select

Ralf: Example

$select=Address($select=Street,City,Namespace.AddressWithLocation/Location)
GET Customers(1)/Address?$select=Street,City,Namespace.AddressWithLocation/Location

Mike: Revised proposal:
Harmonize syntax for complex properties within $select with syntax for navigation properties within $expand:
- complex property can be followed by parentheses containing
- $expand nested in $select.
- $select with same recursive syntax
- $compute to place computed properties within the complex type
- for collection-valued structural properties also $filter, $search, $count, $orderby, $skip, and $top within the parentheses
- support assigning values to parameter aliases within $select

Extended $select syntax also allowed for $select nested within $expand.

Hubert: I move to resolve ODATA-1105 as per the amended proposal. Mike seconds.

Ralf: ODATA-1105 is RESOLVED with the amended proposal

5.5 ODATA-1114 - If-Then-Else in $batch

Mike: encountered situations where if-then-else or case would be useful within queries

Ralf: Add an If-Then-Else construct to batch requests that allows executing a sequence of requests depending on a condition, typically the HTTP status code of a preceding request

Example 1:
1. Book specific seat for a sports event
2. if booking failed
2.a. book best-match seat for a sports event
endif

Example 2:
1. Modify shopping cart
2. Convert shopping cart to purchase order (bound action)
3. if success
3.a. GET newly created purchase order
else
3.b. GET modified shopping cart
endif

Mike: In the above scenario, it appears that statement 2a would be dependent upon response code (or success/failure) of statement 1, not on the return value from the statement 1 (unless statement 1 was an action that returned true/false).

Ralf: Basic idea: define a new kind of request object with members "if", "then", and optionally "else".
Value of "if" is a condition - use syntax of CSDL JSON logical expressions for annotations
Values of "then" and "else" are arrays of request objects - may contain further condition objects.

Ralf: Alternative: use $filter syntax for "if"

Ralf: ODATA-1114 is OPEN

Ralf: Defer it to V4.02

Document walk trhough JSON Format

All walk through the editor revision of the JSON Format document in a shared session

6.1 Motion to accept application of issues

George: I move to close the issues ODATA-958, ODATA-1086, ODATA-1087, ODATA-1090, ODATA-1091, ODATA-1092, ODATA-1094, ODATA-1095, ODATA-1096, ODATA-1097, ODATA-1102, ODATA-1103, ODATA-1104, ODATA-1105, ODATA-1108, ODATA-1109, ODATA-1111, and ODATA-1115 as applied. Mike seconds.

Ralf: The above listed issues are CLOSED

7. Next meetings

Ralf: Topics for next meeting:
- progress documents for 4.012
- discuss timeline and next steps

7.1 Next Meeting on Thursday September 28, 2017 during 08:00-10:00 am PDT (17:00-19:00 CEST)

Note: Two hours earlier, one hour longer

7.2 Meetings following the next one

8. AOB and wrap up

None

Meeting adjourned by chair.