OData TC meeting #194 Thursday November 02, 2017

Acting chair: Mike

Chat transcript from room: odatatc
2017-11-02 0800-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
    Ramesh Reddy (Red Hat)
    Stefan Hagen (Individual)
    Ted Jones (Red Hat)

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

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

2. Approve agenda

George: Has to leave before the first hour is finished, thus wants to add for sake of minuting two comments /statements w.r.t. the following planned sections x.6 and x.7 (from agenda draft with x. prepended as these topics were not discussed after iissues section)

x.6. Committee Note on Google Protocol Buffers as an alternative data format
x.6.1 George: describe use case and purpose of the proposed committee note
  A relatively quick look says a lossy transformation from CSDL to protocol 
  buffers is straight forward.  A number of potential clients would like 
  this format.  
  If this is amenable to a style sheet transform, 
  then we should make that available.

x.7. Structural Property with Type=Entity Type versus Containment Navigation Property
x.7.1 George: describe use case and why containment navigation properties arent sufficient
  NavigationProperty has two forms and semantics depending on whether the 
  ContainsTarget attribute is true or false.  
  Syntactically, when true, the definition is exactly like an EntitySet or Singleton, 
  depending on the presence of Collection.   
  Thus, really not navigation  When false, the declaration really is equivalent to 
  a UML AssociationEnd.  
  In the long-run, the meta-model for CSDL is simpler if we do not conflate these two uses.

Hubert: in investigating this type of interface in the past, knowing the size (particularly of arrays) in advance seemed to be a problem.

George: Perhaps can use server side paging?

Hubert: issue is performance, particularly converting numbers to strings (in json) and back to doubles.

Agenda approved as published with the above additions / comments

3. Approve minutes from previous meeting(s)

3.1 Minutes from October 26, 2017 TC meeting #193


Minutes approved unchanged as published.

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

4.1 Action items due


5. Issues

5.1 V4.01 Public Review

5.1.1 ODATA-1126 - Remove a Reference to an Entity (public review comment c201710e00005)


DELETE http://host/service/Customers(1)/Orders/$ref?$id=../../Orders(4711)
Alternate: DELETE http://host/service/Customers(1)/Orders(4711)/$ref
DELETE http://host/service/Customers(1)/BestFriend/$ref
GET http://host/service/Customers(1)/BestFriend/$ref returns {"@odata.id":"Customers(5)"}
DELETE http://host/service/Customers(1)/BestFriend deletes the best friend.

Hubert: don't like it, but consistent with singleton case (which he also doesn't care for)

Mike: Tend to agree. Better syntax, and more consistent, but kinda rubs me wrong...

George: I move to accept OData-1126 as proposed. Hubert seconds.

Mike: OData-1126 resolved as proposed.

5.1.2 ODATA-1127 - clarify support for navigation properties on deleted entries

Matt: are there other ways to do this?

Mike: yes, in a flattened manner. However, we are moving from a flattened representation to the nested representation because it is a more natural representation and in many cases significantly more efficient.

Matt: useful (and consistent) in update case. Maybe not as useful in client case, if the related things are going to be orphaned anyway.

Matt: I move to accept OData-1127 as proposed. HUbert seconds.

Mike: OData-1127 is resolved as proposed.

5.1.3 ODATA-1128 - Clarify function imports in $filter and $orderby

Mike: I think the text was introduced before we introduced $root, and was intended to differentiate between function imports (which are called from the root) and unbound functions (which can be invoked in a $filter or $orderby as a "global" function.) i.e., syntactically, the function import has to be prefixed with the container. A function import "binds" the function to the container.

Mike: Proposal from issue:

Remove this sentence, or change to 

Function imports can be used inside $filter or $orderby if preceded by the $root literal, see [OData-URL].

Mark: I move that OData-1128 be resoved by making the change specified in the proposal. Hubert seconds.

Mike: OData-1128 is resolved as proposed.

5.2 Vocabularies: NEW or OPEN

5.2.1 ODATA-1124 - Authorization vocabulary: KeyLocation - also allow cookie as value?

Mark: is passing security information in a cookie necessarily a good practice? if not, do we want to encourage it?

5.2.2 ODATA-1122 - Add singletons for capability term targets

Mike: ODATA-1122 is open.

Hubert: I move to resolve ODATA-1122 with direction to the editors to apply as appropriate and the application be reviewed when approving the changes. mark seconds.

Mike: OData-1122 is resolved as proposed.

5.2.3 ODATA-1121 - Extend FilterExpressionRestrictions with "MultiPredicate"

Mike: OData-1121 is held over to next week.

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

Mike: OData-884 example:

<Annotation Term="Core.ErrorCodes"> 
<PropertyValue Property="HttpMethod" String="GET" /> 
<PropertyValue Property="HttpStatusCode" String="400" /> 
<PropertyValue Property="ODataErrorCode" String="QueryFilterFunctionNotSupported" /> 
<PropertyValue Property="Description" 
  String="This error indicates that a request was made with a filter function that isnt supported on this entity set. Please refer to the Capabilities.FilterFunctions annotation on this entity set for a list of supported functions, and the exact error message for which function usage triggered this error." /> 

Mike: Questions on proposal: Do we need, then, to define a set of ODataErrorCodes?

Mike: Other questions from issue comments: Would reorganizing (perhaps hierarchically) work better?

Mike: Document for OpenAPI mapping: https://www.oasis-open.org/apps/org/workgroup/odata/download.php/61852/latest

Mike: Discussion on adding version to vocabularies:5.2.1 Proposal: annotate vocabulary schemas with Core.SchemaVersion to make different revisions distinguishable

Major version is 1 will only be changed if we switch to Xxx.V2
Minor version is incremented whenever we add a term, property, or AppliesTo target
Patch version is incremented whenever we fix something typos, descriptions,

6. Next meetings


Thursday November 09, 2017 during 8-10 am PT (17:00-19:00 CET)

7. AOB and wrap up


Meeting adjourned by chair.