Acting chair: Ralf
Chat transcript from room: odatatc 2018-12-20 0800-1000 PST
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.
Ralf: Agenda approved unchanged as published
Minutes are approved unchanged as published.
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!
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). Cheers, > On 19 Dec 2018, at 8:18 am, Chet Ensign <firstname.lastname@example.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. Cheers, -- Mark Nottingham https://www.mnot.net/
Allow defining "JSON properties" in OData models, i.e. properties whose value is well-formed JSON. Requirements: 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
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
George: Placeholder request to add presentations that introduce OData functionality.
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
The edm.xsd erroneously allows specifying the IncludeInServiceDocument attribute for the edm:ActionImport
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
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
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
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
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....
Ralf: Merry Christmas and a Happy New Year!
Meeting adjourned by chair.