Acting chair: Mike
Chat transcript from room: odatatc 2017-11-02 0800-1000 PDT
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.
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 COMMENT: 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 COMMENT: 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
https://www.oasis-open.org/committees/download.php/61889/odata-meeting-193_on-20171026-minutes.html
Minutes approved unchanged as published.
None
Mike:
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.
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.
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.
Mark: is passing security information in a cookie necessarily a good practice? if not, do we want to encourage it?
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.
Mike: OData-1121 is held over to next week.
Mike: OData-884 example:
<Annotation Term="Core.ErrorCodes"> <Collection> <Record> <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." /> </Record> </Collection> </Annotation>
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,
Mike:
Thursday November 09, 2017 during 8-10 am PT (17:00-19:00 CET)
None
Meeting adjourned by chair.