OData TC meeting #241 Thursday December 20, 2018

Acting chair: Ralf

Chat transcript from room: odatatc
2018-12-20 0800-1000 PST

1. Roll call

1.1 Members present

    George Ericson (Dell)
    Gerald Krause (SAP SE)
    Mark Biamonte (Progress Software)
    Matthew Borges (SAP SE) a.k.a. Matt
    Ralf Handl (SAP SE)
    Stefan Hagen (Individual)
    Ted Jones (Red Hat)

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

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

2. Approve agenda

Ralf: Agenda approved unchanged as published

3. Approve minutes from previous meeting(s)

3.1 Minutes from December 13 2018 Meeting #240

URL = https://www.oasis-open.org/committees/download.php/64435/odata-meeting-240_on-20181212-minutes.html

Minutes are approved unchanged as published.

4. How to proceed with minutes?

Stefan Hagen unfortunately will resign as TC Secretary

Volunteers for TC Secretary?

i.Benefits: permanent voting rights, prominently named on TC home page
ii.Tasks: minutes keeper

Ralf: George volunteers to be secretary

Ralf: I move to approve George Ericson as new secretary. Matt seconds.

Ralf: No objection, motion passes

Ralf: @George: congratulations! And a lot of thanks!

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

5.1 Action items due

Nothing noted

5.2 Action items upcoming

5.2.1 #0037 Concept for Google Protocol Buffers as a data format Hubert Heijkers 2018-09-27

Nothing noted

5.3 Action items pending

5.3.1 #0036 Register the OData- headers and preferences with IANA Mark Biamonte 2018-07-26

Ralf: Mark Nottingham responded to our preference submission:

Hi Chet and Mark,
I agree that some of these are potentially generic. See specific comments below.
Generally, we like to see extensions that are generic being documented in a way that isn't 
specific to one application. For example, WebDAV's previous definitions of HTTP methods and 
status codes is now considered bad practice; if they were done today, we'd make sure to define 
them in their own document.
Note that's not a formal policy for HTTP preferences (AFAIK; ultimately it's up to the experts); 
just a preference that's been expressed and accepted in the community for other extension points 
that seems pretty applicable here. Experience has shown that people who aren't intimately familiar 
with the context will assume that those extensions are limited to that application.
Would there be a willingness in your community to spin some of these extensions into a separate, 
non-ODATA-specific document? Something else from OASIS would be fine, it doesn't need to be an RFC. 
I imagine that ODATA might still have something to say about their specific use in that protocol 
(which might resolve the question below).
> On 19 Dec 2018, at 8:18 am, Chet Ensign <chet.ensign@oasis-open.org> wrote:
> Hi Mark,
> Our thinking is that a number of the preferences may be of general use and are not specific to OData.  
> Looking at each of the preferences the ones we feel are of general interest and independent of OData are
>          callback as an add-on to respond-async can be used with any payload format  respond-async defined in - 
>              https://tools.ietf.org/html/rfc7240 - author is James Snell  
>          maxpagesize as an add-on to the "next" link relation, see https://www.iana.org/assignments/link-relations/link-relations.xhtml.  
>          Can be used in Atom with <link rel="next" ... /> as we do it in the OData Atom format  
>          Can be used with a link header with this relation, see https://tools.ietf.org/html/rfc5988 - author is Mark Nottingham 
>          omit-values  interesting for other JSON or name-value pair formats  
>          track-changes  can be used with other payload formats that allow representing diffs, e.g. JSON PATCH - 
>              https://tools.ietf.org/html/rfc6902 - author is Mark Nottingham 
I think I agree that these are potentially generic. However, their descriptions mention ODATA-specific concepts; e.g., 
"delta links" and ODATA capabilities. Could you factor those out into more generic things, omit them, or move them to 
ODATA-specific text elsewhere?
> The remaining three are less obvious to us as to whether they would be useful in other cases
>          allow-entityreferences  needs a concept and representation of references to be useful  
>          continue-on-error  needs a batch or bulk format  
>          include-annotations  needs annotations 
> Do you or other experts know of existing specs that utilize the concept of references, batch or bulk operations or annotations?  
> If so could any of these remaining three be useful to those specs?
I think I agree that these are less likely to be useful generic. I'd encourage you to continue using the odata.* names.
Mark Nottingham   https://www.mnot.net/

6. Issues

6.1 V4.01

6.1.1 ODATA-1177 - Add "JSON properties" to OData

Ralf: Description

Allow defining "JSON properties" in OData models, i.e. properties whose value is well-formed JSON.
JSON property values are represented "inline" in JSON responses, i.e. "JSONproperty": <well-formed JSON data>
Common expressions (e.g. in $filter) can address parts of JSON data
JSON properties can specify a JSON Schema that describes/restricts their data values
This would finally resolve/replace the long-planned OData Extension for JSON Data.


the type should specify the value range and behaviors
need not be specific to JSON, JSON could be just one of the possible mappings, with e.g. XML being another mapping


Sort of what Edm.Untyped is, but without the restriction on "property names"


fundamentally we want a type system that covers all use cases


in the past we had an XML format in addition to JSON, and non-JSON formats would have to define how to render "JSON property"


identify type by its value restrictions, not by an existing language binding, here "JSON"


is it a new OData type, or is it just Edm.String with certain value restrictions and a special representation in the JSON Format


tend to make it part of the type system

Ralf: ODATA-1177 is OPEN


what about compatibility?


Could say: it is Edm.String and a JSON string in V4 responses, and native embedded JSON in a V4.01 response


leaning towards a type


also leaning towards a type
use Edm.JSONString or something similar

6.1.2 ODATA-1265 - Clarify property paths used in a lambda predicate _expression_

Matt: define what "scope" is

Ralf: Have two examples, one with a direct $filter not nested within $expand

Gerald: AI for Gerald to update proposal of ODATA-1265

Ralf: New in V4.01: https://www.oasis-open.org/apps/org/workgroup/odata/download.php/64157/new-in-odata-v4.01-wd03-2018-10-26.docx

George: Placeholder request to add presentations that introduce OData functionality.

6.1.3 ODATA-1257 - Do URLs within a Batch Request need to be URL Encoded?

Ralf: Proposal:

URLs must be fully percent encoded in the request, including in a multipart batch request
URLs represented as string within a JSON payload, including JSON batch, must be safely encoded. 
Need to define what safely encoded means - colons within the path must be encoded, (and forward-slashes used within data values) percent-encoded.
Question marks within path must be encoded, and hashes must be encoded.
Question: must colons in query string be percent-encoded?

Ralf: Mark will answer this question

6.1.4 ODATA-1249 - edm.xsd: ActionImport and IncludeInServiceDocument

Ralf: Description

The edm.xsd erroneously allows specifying the IncludeInServiceDocument attribute for the edm:ActionImport

Ralf: Proposal:

edm.xsd: restrict IncludeInServiceDocument to edm:FunctionImport as defined in the prose specification

Ralf: ODATA-1249 is OPEN

George: Move to to resolve ODATA-1249. Matt seconds.

Ralf: ODATA-1249 is RESOLVED as proposed

Ralf: I move to close ODATA-1249 as applied and merge https://github.com/oasis-tcs/odata-csdl-schemas/pull/5. Mark sceonds.

Ralf: ODATA-1249 is CLOSED as applied

6.1.5 ODATA-1248 - csdl.schema.json: add descriptions to all schema elements

Ralf: ODATA-1248 is OPEN

George: I move to resolve OData-1248 as proposed. Mark seconds.

Ralf: ODATA-1248 is RESOLVED as proposed

George: I move to close ODATA-1248 as applied. Mark seconds.

Ralf: ODATA-1248 is CLOSED as applied

6.1.6 ODATA-1245 - Extract _expression_ syntax into own sub-section next to $filter

Ralf: ODATA-1245 is OPEN

Ralf: Ralf to prepare a document with this change applied

Mark: I move to have Common Expressions broken out into a separate section as described in ODATA-1245. George seconds.

Ralf: ODATA-1245 is RESOLVED as proposed

6.2 Data Aggregation

6.2.1 ODATA-1072 - Annotation to describe supported aggregation methods


1.Structured term AggregationConstraints as currently proposed introduces ambiguity on how to express no constraints on aggregation methods
2.New proposal: split into separate terms for each aspect, no annotation means no constraint for this aspect

Ralf: ODATA-1072 is OPEN

Gerald: I move to resolve ODATA-1072 as proposed. George seconds.

Ralf: ODATA-1072 is RESOLVED with the new proposal

6.2.2 ODATA-1244 - Add a function to determine aggregated values within common expressions

Nothing noted

7. Next meetings

a.Thursday January 10, 2019 during 8-10 am PST (17:00-19:00 CET)  moderator: Mike Pizzo  minutes keeper: George Ericson
b.Thursday January 17, 2019 during 8-10 am PST (17:00-19:00 CET)
c.Thursday January 21, 2019 during 8-10 am PST (17:00-19:00 CET)

George [Secretary]: Next meeting is Jan 10, 2019....

8. AOB and wrap up

Ralf: Merry Christmas and a Happy New Year!

Meeting adjourned by chair.