OData TC meeting #209 Thursday April 05, 2018

Acting chair: Ralf

Chat transcript from room: odatatc
2018-04-05 0800-1000 PDT

1. Roll call

1.1 Members present

    George Ericson (Dell)
    Hubert Heijkers (IBM)
    Mark Biamonte (Progress Software)
    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=46250).

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

2. Approve agenda

Agenda approved unchanged as published

3. Approve minutes from previous meeting(s)

3.1 Minutes from March 22, 2018 TC meeting #208


Minutes approved unchanged as published.

Additional decisions and suggestions:

Ralf: Section 5.1.3

"initial default version" needs more clarification

Mike: in ODATA-1154: "initial Default Version" needs clarification.

Our intention was that the behavior of the service did not change over time 
with respect to a client that does not specify an OData-MaxVersion header.

Mike: shift Outline for REST Profile / OData Essentials to May 3rd

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

4.1 Action items due


5. Issues

5.1 V4.01: NEW or OPEN

5.1.1 ODATA-1170 - Allow @odata.type next to $EnumMember for isomorphy to CSDL XML


The XML representation of <EnumMember> constant expressions contains 
the enumeration type name of the enumeration value as a prefix: 

<Annotation Term="Namespace1_Alias.TermEnum"> 
     Namespace1_Alias.ENString/String1 Namespace1_Alias.ENString/String3 

The JSON representation does not contain the type name: 

   "$EnumMember": "String1,String3" 

This breaks isomorphy between XML and JSON representation of CSDL. 

The JSON representation was explicitly chosen without type prefix to 
mirror the JSON Format representation of enumeration values in data payloads. 

Allowing an @odata.type control information next to $EnumMember would 
both be consistent with JSON Format and establish isomorphy to CSDL XML: 

   "@odata.type": "Namespace1_Alias.ENString", 
   "$EnumMember": "String1,String3" 


Dynamic enum property in JSON Format:
   "DynEnumProp@odata.type": "Namespace1_Alias.ENString", 
   "DynEnumProp": "String1,String3"

   "$EnumMember@odata.type": "Namespace1_Alias.ENString", 
   "$EnumMember": "String1,String3" 

Alternative (corrected):
   "$EnumMember@odata.type": "#Namespace1_Alias.ENString", 
   "$EnumMember": "String1,String3" 

   "$EnumMember@odata.type": "https://some.other/service/$metadata#Namespace1_Alias.ENString", 
   "$EnumMember": "String1,String3" 

Ralf: ODATA-1170 is OPEN

Mike: do we allow @odata.type or do we require it?

Mike: if term is Edm.Primitive or Edm.Untyped, then required

Ralf: if term is concretely typed, allow it, don't require it

Mike: if we don't require it, then creating the XML representation requires having the term definitions around

Mike: optional is fine, is consistent with payloads

George: follow the same rules as @odata.type in data payloads: required if it cannot be computed

Mike: We should make it optional in the normal case, required if you can't deduce the type; (i.e., if the term cannot be resolved for some reason or the type of the term is Edm.Untyped), as in the data payload.

George: I move to approve OData-1170 as proposed. Hubert seconds.

Ralf: ODATA-1170 is RESOLVED with the amended proposal

5.1.2 ODATA-1168 - Clarify the use of ETags for Avoiding Update Conflicts

Ralf: Description: http://docs.oasis-open.org/odata/odata/v4.0/errata03/os/complete/part1-protocol/odata-v4.0-errata03-os-part1-protocol-complete.html#_Data_Modification states: Use of ETags for Avoiding Update Conflicts 
If an ETag value is specified in an If-Match or If-None-Match header of a Data Modification Request or Action Request, 
the operation MUST only be invoked if the if-match or if-none-match condition is satisfied. 

The ETag value specified in the if-match or if-none-match request header may be obtained from an ETag header of a response 
for an individual entity, or may be included for an individual entity in a format-specific manner. 

Issue requiring clarification: we carefully need to distinguish between ODatas meaning of entity = an instance of an entity type" 
and HTTPs meaning of entity = the thing whose representation is transferred. ETags (= entity tags) refer to the HTTP meaning, 
and thus links/references/relationships are HTTP entities that can have their own ETags.


GET Orders(1) --> ETag: a
GET Orders(1)/Items --> ETag: b
POST Orders(1)/Items,If-Match: b
GET Orders(1)/ShippingDate --> ETag: a
GET Orders(1)/Customer --> ETag: c - is a different OData entity

Mike: to flavors of ETags: ETag header (HTTP) and @odata.etag control information

George: need examples

Mike: I think we agreed to:

An ETag returned as a header represents the entire response. A Conditional GET for the same request 
using that ETag should return a response iff *anything* in the response has changed.

Mike: Question: Under what conditions can I use the ETag for an update?

George: Question w.r.t. current defn of behavior of ETAG for contained entities.


Each entity has its own ETag value that MUST change when structural properties or links from that entity have changed. 
In addition, modifying, adding, or deleting a contained entity MAY change the ETag of the parent entity.

Mike: If the response was a single entity, then the etag can be used for a conditional update.


-What if the request was for a collection? Can the ETag be used in updating the collection? 
Would a POST or DELETE fail if any member of the collection had changed, or only if something had been added/removed from the collection?  
Could I use an ETag header from a GET collection/$ref if I only wanted it to fail if the membership had changed?


GET Orders(1) --> ETag: a
GET Orders(1)?$expand=Items --> ETag: d?

Mike: yes if service supports conditional GET

Ralf: Service could always return 200 OK with latest representation

Mike: Issue:

If I do a GET for customers?$expand=orders, and get back an ETag, and do a conditional GET to the same URL using the same ETag, 
I must get a response back if anything in the payload has changed, otherwise caching will return incorrect responses.


GET Orders(1) --> ETag: a
PATCH Orders(1) must have If-Match
Ralf to write up proposal reflecting this discussion

Georgr: See 13.9 of RFC2616, which proscribes caching with GET requests containing ? parameters.

Ralf: one step back: ODATA-1168 is OPEN (to not waste the discussion

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

Ralf: Postponed until Ralf prepares an example

5.1.4 ODATA-1163 - A Case for Common Expressions


If all parameters are of the same type, the type of the expression is of that type. 
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.


Issues with default cast to string: If expressions are different type (int, boolean) does case really do an implicit cast to string?  
What if an expression is a complex/entity type?

Alternative 1: Require expressions to be cast to compatible types
Alternative 2: Allow the case expression to be Untyped

If we start with 1 (which is more restrictive) we could relax later for alternative 2. 
We could not go the other way...

Ralf: Alternative 1: Mike, Mark, Ralf, George, Hubert, Matt

Ted: would Alternative 1 pose problems for untyped languages?

Mike: Proposed wording to capture alternative 1:

All parameter expressions must be compatible.If all parameters are of the same type, the type of the case expression is of that type. 
If all parameter expressions are of numeric type, the type of the case expression has a numeric type capable of representing any of 
these expressions according to standard type promotion rules. 
If types of parameter expressions are not compatible, then they must be cast to compatible types.

Ralf: Postponed to next meeting

6. Next meetings

Thursday April 12, 2018 during 8-10 am PDT (17:00-19:00 CEST)
Thursday April 19, 2018 during 8-10 am PDT (17:00-19:00 CEST)

George: https://www.omg.org/spec/OCL/2.4/PDF - Object Constraint Language

Mike: can't make next week

Hubert: might be late

7. AOB and wrap up


Meeting adjourned by chair.