OData TC meeting #208 Thursday March 22, 2018

Acting chair: Ralf

Chat transcript from room: odatatc
2018-03-22 0800-1000 PDT

1. Roll call

1.1 Members present

    George Ericson (Dell)
    Gerald Kraue (SAP SE)
    Hubert Heijkers (IBM)
    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=46248).

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

2. Approve agenda

Mike: heads-up on feedback from OASIS directors

Ralf: Citation:

OData adoption is "off the charts"

Ralf: If you know of companies interested in participating in the OData TC, please let Robin Cover (and us) know

Agenda approved unchanged as published

3. Approve minutes from previous meeting(s)

3.1 Minutes from March 15, 2018 TC meeting #207

https://www.oasis-open.org/committees/download.php/62704/odata-meeting-207_on-20180315-minutes.html

Minutes approved unchanged as published.

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

4.1 Action items due

None

5. Issues

5.1 V4.01: NEW or OPEN

5.1.1 ODATA-1165 - Describe $expand and $select via prose text and examples, remove ABNF snippets

Ralf: http://docs.oasis-open.org/odata/odata/v4.01/cs01/part2-url-conventions/odata-v4.01-cs01-part2-url-conventions.html#_Toc505773297

Mike: would be helpful to have an example of how this would look like

Ralf: Just remove ABNF *snippets* from prose spec, keep ABNF as machine-readable work product

Ralf: ODATA-1165 is OPEN

5.1.2 ODATA-1163 - A Case for Common Expressions

Ralf: Proposal:

The case function has the following signatures: 

expression case(Edm.Boolean:expression, ..., Edm.Boolean:expression) 
expression case(Edm.Boolean:expression, ..., Edm.Boolean:expression,expression) 

Each Edm.Boolean:expression parameter is a tuple separated by a colon, 
where the first component evaluates to a Boolean value, and the second component may be an expression of any type. 

The case function returns the expression value of the leftmost parameter, 
whose first component evaluates to true. If none of the parameters match, 
case returns null, unless the last parameter is an expression, whose value is returned otherwise. 

If all parameter expressions are of numeric type, the return value has a numeric type 
capable of representing any of these expressions. Otherwise, the return value is the result 
of casting the expression of the matching parameter to Edm.String.

Mike: if all expressions are of the same type, return that type

Mike: If all expressions are of the same type, the return value is of this type

Mike: Key question: is it important to know the type of the expression? Or can we say that the type is dependent upon the value (i.e., the type of the expression is Edm.Any)

Ralf: Homework: check your (intended) implementations on what they require / can deal with

Hubert: How to handle the unknown type of dynamic properties from open types in case result expressions?

5.1.3 ODATA-1154 - Clarify which OData-Version a service should return

Ralf: Proposed rewording:

The service MUST respond with a payload compliant with the greatest version of the protocol 
that is less than or equal to the request's OData-MaxVersion, if specified. 

Questions: 
1) What if no OData-MaxVersion is specified? 
2) Does specifying an OData-Version limit the constructs that the request can use in the URL? 
   i.e., if I have a 4.0 payload, am I restricted to 4.0 URL constructs, even if I know the service supports them? 
3) What if the client *only* support 4.01? Do we have a way to specify NOT to return 4.0? 
4) Does a service have to return a 4.01 payload if the request uses a 4.01 construct?

Ralf: Ad 1: Current spec says

If OData-MaxVersion is not specified, then the service SHOULD interpret the request as 
having an OData-MaxVersion equal to the maximum version supported by the service.

Ralf: Means: return max version the service implements, i.e. the latest and greatest

Hubert: implemented it that way

Mike: can we leave that up to each service?

Mike: We say that an interoperable odata client should specify the odata-maxversion. in the absence of specifying an odata-maxversion, we should probably leave it up to the service.

Mike: "same request must return same result"

Ralf: This means no MaxVersion is equivalent to MaxVersion:4.0

[16:55] Michael Pizzo: No, it means no maxversion is equivalent to the first (default) version that the service implemented. If it started as a 4.01 service it might always default to 4.01

Ralf: Yes, now

Ralf: Rephrase spec to:

If OData-MaxVersion is not specified, then the service SHOULD interpret the request as 
having an OData-MaxVersion equal to the *initial* version supported by the service

Ralf: to keep the service behavior consistent over time

Mike: 1) "initial default version of the service"

Ralf: 2) Does specifying an OData-Version limit the constructs that the request can use in the URL? i.e., if I have a 4.0 payload, am I restricted to 4.0 URL constructs, even if I know the service supports them?

Mike: can a service accept request URLs with e.g. the "in" operator if the client specifies OData-Version:4.0

Mike: yes

Ralf: OData-Version only has to reflect the payload of the request

Ralf: Current text:

OData clients SHOULD use the OData-Version header on a request to specify the version of the protocol used to generate the request.

Ralf: Rephrase to:

OData clients SHOULD use the OData-Version header on a request to specify the version of the protocol used to generate the request *body*.

Ralf: Or *payload* -> check what we consistently use

Ralf: 3) What if the client *only* support 4.01? Do we have a way to specify NOT to return 4.0?

Ralf: No MinVersion (yet)

Mike: If the client inspects the metadata to determine the service supports 4.01, and requests a maxversion of 4.01, the above rule requires that the service return 4.01.

Ralf: 4) Does a service have to return a 4.01 payload if the request uses a 4.01 construct?

Mike: OData-Version:4.01 OData-MaxVersion:4.0

George: sounds like too much flexibility

Mike: 4) Request and response payloads are independent. The service must honor OData-MaxVersion in a response regardless of the version of the request payload.

Mike: Similar to the fact that the request payload could be different than a response payload.

Mike: Summarized in issue:

1) The same request should return the same response, so in the absence of an odata-maxversion header, 
   the service should return the same payload over time.  "If OData-MaxVersion is not specified, 
   then the service SHOULD interpret the request as having an OData-MaxVersion equal to the 
   *initial default* version produced by the service".
2) Client is allowed to use 4.01 without specifying an OData-Version or OData-MaxVersion of 4.01. 
   A payload MUST specify the OData-Version of the request body.
3) If the client inspects the metadata to determine the service supports 4.01, and requests a maxversion of 4.01, 
   the proposed general rule requires that the service return 4.01 (we can introduce a min version in the future, if required).
4) Request and response payloads are independent. 
   The service must honor OData-MaxVersion in a response regardless of the version of the request payload.

Mike: Proposal:

The service MUST respond with a payload compliant with the greatest supported version of the protocol 
that is less than or equal to the request's OData-MaxVersion, if specified. 

The same request should return the same response, so in the absence of an odata-maxversion header, 
the service should return the same payload over time.  "If OData-MaxVersion is not specified, 
then the service SHOULD interpret the request as having an OData-MaxVersion equal to the 
*initial default* version produced by the service".

Client is allowed to use 4.01 without specifying an OData-Version or OData-MaxVersion of 4.01. 
If a request has a payload, a compliant client MUST specify the OData-Version of the request body.

If the client inspects the metadata to determine the service supports 4.01, and requests a maxversion of 4.01, 
the proposed general rule requires that the service return 4.01 (we can introduce a min version in the future, if required).

Request and response payloads are independent. The service must honor OData-MaxVersion in a response 
regardless of the version of the request payload.

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

Ralf: ODATA-1154 is RESOLVED with the above proposal

5.1.4 ODATA-1149 - Support Delta responses for Singletons

Ralf: need new context URL pattern to distinguish this from "full object"

Ralf:

"@context":"http://host/service/$metadata#Customers/$delta",
"@context":"http://host/service/$metadata#MySingleton/$delta",

Mike: In 4.01, the delta response for a singleton is represented as a single top-level object with (possibly nested) changes.
In 4.0, the response could (in theory) be an array containing a flattened response or a single object with nested content showing the after-image.

George: This also applies to single-valued navigation properties?

Mike: Yes, as well as collection-valued navigation properties (which may not have been clear in 4.0)

Mike: Proposal:

Deltas can be supported for singletons and single-value navigation properties as well 
as entities and collection-valued navigation properties.

The context url for a delta against a singleton (or single-valued nav prop) follows the 
same pattern of appending /$delta to the context url returned by a request against that singleton (or single-valued nav prop).

The 4.01 JSON payload for a delta request/response rooted in a single object is the single object 
with nested changes (i.e., propertyName@delta).

We don't define a 4.0 JSON format for a delta payload for a request/response rooted in a single object.

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

Ralf: ODATA-1149 is RESOLVED with the above proposal

5.1.5 ODATA-1148 - PATCH with nested nav props should not remove omitted resources

Skipped

5.1.6 ODATA-1143 - Extend the Property metatype to allow a type that is an EntityType.

Skipped

5.1.7 ODATA-1141 - Upsert: clarify upsert along nullable single-valued navigation path

Skipped

5.1.8 ODATA-1135 - Document use of JSON $schema

Skipped

5.1.9 ODATA-1088 - Clarify effect of applying an Annotation to an element

Skipped

5.2 Vocabularies: NEW or OPEN with concrete proposal

5.2.1 ODATA-1167 - Add way to specify which batch formats (if any) are supported by a service

Skipped

5.2.2 ODATA-1064 - Add ability to annotate collections to return only count and NextLink

Skipped

5.3 Vocabularies: NEW or OPEN that need more discussion

5.3.1 ODATA-1099 - Add annotations to describe custom query options and custom headers

Skipped

5.3.2 ODATA-1005 - Make sure we have capabilities for all new 4.01 functionality

Skipped

5.3.3 ODATA-884 - Add term ErrorCodes to describe possible codes in error messages (public comment c201510e00019)

Skipped

5.4 Data Aggregation: NEW or OPEN

5.4.1 ODATA-1162 - Fix data type in example model

Skipped

5.4.2 ODATA-1161 - Clarify how to process hybrid results of a transformation in subsequent transformations

Skipped

5.4.3 ODATA-1160 - Clarify example 66 in section 7.5

Skipped

5.4.4 ODATA-1159 - Clarify context URLs for aggregated result sets

Skipped

5.4.5 ODATA-1158 - Transformations for limiting the number of entities in the result of a $apply transformation

Skipped

5.4.6 ODATA-1157 - Transformation for sorting entities created by a $apply transformation

Skipped

5.4.7 ODATA-1137 - Clarify type information for dynamic properties in the aggregated result set

Skipped

5.4.8 ODATA-1073 - Conformance section references wrong annotation term

Skipped

5.4.9 ODATA-1068 - 3.12 Transformation expand: require at least two parameters, with innermost expansion requiring a filter()

Skipped

5.4.10 ODATA-1041 - Broaden definitions of transformations topcount and bottomcount

Skipped

6. Next meetings

Ralf:

Suggested:

Thursday March 29, 2018 during 8-10 am PDT (17:00-19:00 CEST) – back to normal time difference, Easter is coming
Thursday April 05, 2018 during 8-10 am PDT (17:00-19:00 CEST) – Week after Easter?
Thursday April 12, 2018 during 8-10 am PDT (17:00-19:00 CEST)

Ralf: no meeting next week

Agreed:

Thursday April 05, 2018 during 8-10 am PDT (17:00-19:00 CEST) – Week after Easter?
Thursday April 12, 2018 during 8-10 am PDT (17:00-19:00 CEST)

Ralf: On April 05: Gerald can't, Mike and Matt can, George can

7. AOB and wrap up

None.

Meeting adjourned by chair.