RE: Agenda for OData TC meeting on 2019-06-06

[‎06.‎06.‎2019 17:01]

Voting Members: 4 of 9 (44%) (used for quorum calculation)

[‎06.‎06.‎2019 17:04]

Voting Members: 5 of 9 (55%) (used for quorum calculation)

[‎06.‎06.‎2019 17:05]

Voting Members: 6 of 9 (66%) (used for quorum calculation)

[‎06.‎06.‎2019 17:05]

Quorum achieved: yes

[‎06.‎06.‎2019 17:06]

2. Approve agenda [8:05 am PT]

[‎06.‎06.‎2019 17:06] Mike Pizzo:

https://issues.oasis-open.org/browse/ODATA-1307

[‎06.‎06.‎2019 17:07]

Add this to 7. Issues

[‎06.‎06.‎2019 17:08]

3. Approve minutes from previous meeting(s) [8:10 am PT]

1. Minutes from May 16, 2019 TC meeting: https://www.oasis-open.org/committees/download.php/65335/Minutes%20of%202019-05-16%20Meeting%20%23259.docx

[‎06.‎06.‎2019 17:09]

No objections, minutes are approved

[‎06.‎06.‎2019 17:09]

4. Review action items [Action item list: https://www.oasis-open.org/apps/org/workgroup/odata/members/action_items.php?sort_field=due_closed_date] [8:15am PT]

1. Upcoming

i. #0037 Concept for Google Protocol Buffers as a data format – Hubert Heijkers – 2019-06-27

1. In progress

i. #0036 Register the OData- headers and preferences with IANA – Mark Biamonte – 2019-06-21

[‎06.‎06.‎2019 17:10]

No Title

5. Face-to-Face Meeting 2019 [8:15 am PT]

1. Date

i. CW 25 2019, June 17-21

ii. Pre-Meeting Tuesday June 18 and Wednesday June 19, attendance is optional

iii. Face-to-Face-Meeting Thursday June 20 and Friday June 21, counts towards voter eligibility

1. Location

i. 228 South Street, Hopkinton, MA 01748…

1. Proposed agenda

i. Tuesday June 18

1. Prepare proposals for all remaining V4.01 issues

2. IANA registration for headers and preferences – only OData-specific versions as suggested by Mark Nottingham?

3. Extension for Temporal Data – discuss new approach for preserving service structure

ii. Wednesday June 19

1. Extension for Data Aggregation – Hierarchies

2. REST-EZ (aka REST Profile for OData)

iii. Thursday June 20

1. Finalize V4.01

2. Repeatable Requests – document walkthrough

3. OData-to-OpenAPI Mapping – document walkthrough (changes only)

iv. Friday June 21

1. REST-EZ (aka REST Profile for OData)

2. Marketing & Rebranding

3. Infrastructure & tools for producing and consuming OData easier

[‎06.‎06.‎2019 17:10]

Ling will join us

[‎06.‎06.‎2019 17:10]

Hubert will join

[‎06.‎06.‎2019 17:10]

Ralf

[‎06.‎06.‎2019 17:10]

Mike

[‎06.‎06.‎2019 17:10]

Gerald

[‎06.‎06.‎2019 17:11]

George will be there

[‎06.‎06.‎2019 17:12]

Mark and Matt can't join in person

[‎06.‎06.‎2019 17:12]

Ted will join via phone, Eastern time zone

[‎06.‎06.‎2019 17:13] Ted Jones:

Correction.. Ted is Central time

[‎06.‎06.‎2019 17:13]

Only formal meetings Thursday and Friday

[‎06.‎06.‎2019 17:16]

Hubert can't make the next meeting

[‎06.‎06.‎2019 17:20]

No Title

1. V4.01: Document Walkthrough [8:20 am PT]

1. Part 1: Protocol – https://www.oasis-open.org/committees/download.php/65201/odata-v4.01-wd06-part1-protocol-2019-04-25.docx

1. Finished

2. Part 2: URL Conventions – https://www.oasis-open.org/committees/download.php/65265/odata-v4.01-wd06-part2-url-conventions-2019-05-09.docx

1. Finished

3. CSDL JSON – https://www.oasis-open.org/committees/download.php/65361/odata-csdl-json-v4.01-wd05-2019-05-23.docx

1. Finished

4. CSDL XML – https://www.oasis-open.org/committees/download.php/65362/odata-csdl-xml-v4.01-wd06-2019-05-23.docx

1. Finished

5. JSON Format – https://www.oasis-open.org/committees/download.php/65363/odata-json-format-v4.01-wd06-2019-05-23.docx

1. Finished

6. What’s New – https://www.oasis-open.org/committees/download.php/65364/new-in-odata-v4.01-wd03-2019-05-23.docx

1. Finished

7. Motion to close all applied issues for V4.01

1. I move to close ODATA-1088, ODATA-1114, ODATA-1141, ODATA-1146, ODATA-1149, ODATA-1150, ODATA-1151, ODATA-1154, ODATA-1164, ODATA-1165, ODATA-1166, ODATA-1168, ODATA-1170, ODATA-1172, ODATA-1173, ODATA-1174, ODATA-1177, ODATA-1178, ODATA-1180, ODATA-1187, ODATA-1188, ODATA-1189, ODATA-1195, ODATA-1196, ODATA-1197, ODATA-1203, ODATA-1207, ODATA-1208, ODATA-1210, ODATA-1211, ODATA-1212, ODATA-1213, ODATA-1217, ODATA-1219, ODATA-1220, ODATA-1221, ODATA-1231, ODATA-1236, ODATA-1238, ODATA-1240, ODATA-1242, ODATA-1243, ODATA-1245, ODATA-1250, ODATA-1251, ODATA-1252, ODATA-1254, ODATA-1257, ODATA-1258, ODATA-1259, ODATA-1260, ODATA-1263, ODATA-1265, ODATA-1266, ODATA-1267, ODATA-1268, ODATA-1270, ODATA-1272, ODATA-1274, ODATA-1277, ODATA-1278, ODATA-1280, ODATA-1282, ODATA-1284, ODATA-1286, ODATA-1288, ODATA-1290, ODATA-1291, ODATA-1292, ODATA-1294, and ODATA-1295 as applied

[‎06.‎06.‎2019 17:21] Ericson, George:

Move to close issues as applied.

[‎06.‎06.‎2019 17:21] Mike Pizzo:

I second

[‎06.‎06.‎2019 17:21]

No objection, motion passes

[‎06.‎06.‎2019 17:22]

Mike volunteers to maintain Jira

[‎06.‎06.‎2019 17:22]

1. Issues [8:20 am PT]

1. V4.01: NEW or OPEN

[‎06.‎06.‎2019 17:23]

i. ODATA-1303 Clarify whether schemas traversed in path expressions must be in scope

[‎06.‎06.‎2019 17:23]

Assume service A references service B, which in turn references service C.

If I annotate an entity type in service A with a path _expression_ using cross-service navigation to services B and C, do I need to reference/include the corresponding schemas of B an C, or is it sufficient to only reference/include the schema of service A containing the targeted entity type?

Example

[‎06.‎06.‎2019 17:23]

It is sufficient to reference service B from service A.

A client/validator needs to read the metadata of service B anyway to find out whether the referenced entity type from service B has a navigation property NavPropToServiceC. Then it can use the references within service B's metadata to figure out where NavPropToServiceC points to, and if necessary follow a reference from service B to service C for the next step of validation.

[‎06.‎06.‎2019 17:27]

Path="to_Order/to_Items/to_Product"

[‎06.‎06.‎2019 17:30] Hubert Heijkers:

FYI have to jump, will be back or not depending on how this next meeting goes.

[‎06.‎06.‎2019 17:31]

ODATA-13 03 is OPEN

[‎06.‎06.‎2019 17:32]

Mike: this is for all paths, also in URLs

[‎06.‎06.‎2019 17:33] Mike Pizzo:

Updated proposal: It is sufficient to reference service B from service A.
A client/validator needs to read the metadata of service B anyway to find out whether the referenced entity type from service B has a navigation property NavPropToServiceC. Then it can use the references within service B's metadata to figure out where NavPropToServiceC points to, and if necessary follow a reference from service B to service C for the next step of validation.
This is true for all path traversal (i.e., in URL) and is in contrast to directly referencing a type defined in service C's schema from service A (which requires a direct reference to service c's schema)

[‎06.‎06.‎2019 17:34] Ericson, George:

Motion to resolve OData-1303 as proposed

[‎06.‎06.‎2019 17:34] Mike Pizzo:

I second

[‎06.‎06.‎2019 17:34]

ODATA-1303 is RESOLVED as proposed

[‎06.‎06.‎2019 17:36]

ii ODATA-1302 Support PUT to replace a collection of entities

[‎06.‎06.‎2019 17:42]

ODATA-1302 is OPEN

[‎06.‎06.‎2019 17:43] Mike Pizzo:

I move we resolve ODATA-3102 as proposed

[‎06.‎06.‎2019 17:45]

I move we resolve ODATA-1302 as proposed

[‎06.‎06.‎2019 17:45] Borges, Matt:

I second

[‎06.‎06.‎2019 17:45]

ODATA-1302 is RESOLVED as proposed

[‎06.‎06.‎2019 17:46]

iii. ODATA-1301 Can nullable singletons be deleted or created?

[‎06.‎06.‎2019 17:47]

Mike: should have same semantics as single-valued navigation property

[‎06.‎06.‎2019 17:48]

Proposal:

If a singleton is null, a service may support upserting it via PATCH or PUT, and can announce this with annotation Capabilities.UpdateRestrictions/Upsertable:true, see ODATA-1005.

If a singleton is nullable, a service may support deleting it via DELETE. By default nullable singletons are deletable, and the service can announce that it is not deletable with annotation Capabilities.DeleteRestrictions/Deletable:false, see ODATA-1005. (Note: the default for this annotation is Deletable:true because it also applies to entity sets and has been around for some time.)

[‎06.‎06.‎2019 17:51]

ODATA-1301 is OPEN

[‎06.‎06.‎2019 17:51] Ericson, George:

Move to resolve OData 1301 as proposed.

[‎06.‎06.‎2019 17:51] Borges, Matt:

I second

[‎06.‎06.‎2019 17:52]

ODATA-1301 is RESOLVED as proposed

[‎06.‎06.‎2019 17:52]

iv. ODATA-1299 Continue-on-Error for Collection requests

[‎06.‎06.‎2019 17:52]

No Title

Description

In a GET against a collection of entities, it is possible that an entity returns an error, for example if a connection to the provider of the entity is lost.

The proposal is to allow a Continue-On-Error preference or a $Continue-On-Error query option for a GET against a collection.

In the event of an error returned by an entity being retrieved, the effect of Continue-On-Error, would be to stop the current page, returning both the entities up to the error and an Error result for the element that returned the error and, if there are additional elements following, a nextLink for use in retrieving the remaining entities in the collection.

Note for discussion, the first result could be split, first returning entities up to but not including the failed entity, with a nextLink to retrieve the error result for the failing entity, And finally more entities, if the last returned a nextLink.

[‎06.‎06.‎2019 17:53]

No Title

Proposal:

Requests to collections (of entities) MAY depend on the preference odata.continue-on-error.

This includes

· GET requests to collections

· PATCH requests to collections with a delta payload

· PATCH requests with .../$each

· DELETE requests with .../$each

For a GET request to a collection continue-on-error means "read as much as possible". If it returns an incomplete result, the response MUST contain a next link for retrieving the "missing" entities. The response SHOULD contain an instance annotation with term Core.Messages in the top-level (wrapper) object explaining what went wrong.
Note: only SHOULD contain Core.Messages because GET requests are allowed to return incomplete results, in which case they MUST contain a next link._

For a PATCH request to a collection with a delta request body continue-on-error means "treat each top-level object as an atomic request", i.e. nested deltas within the top-level entity are applied all-or-nothing. The response MUST be the delta of actually applied changes, and it MUST contain an instance annotation with term Core.Messages in the top-level (wrapper) object. Each item within the array-valued instance annotation SHOULD correspond to a single failed top-level object in the request and SHOULD have a targetwith the id of the failing top-level entity, which may be absolute or relative.

OPEN: how to "target" added/deleted link objects?

For a PATCH request with .../$each the response is a collection payload representing the members of the collection with changes applied. If not all members matching the request were changed, the response MUST contain an instance annotation with term Core.Messages in the top-level (wrapper) object. Each item within the array-valued instance annotation SHOULD correspond to a single failed member matching the request and SHOULD have a target with the id of the failing member, which may be absolute or relative.

OPEN: how to "target" non-entity members, i.e. primitive or complex instances? Even index is problematic

A completely successful DELETE request with .../$each does not have a response. A partially successful request has a response with 200 OK and the response body is a single (wrapper) object that MUST contain an instance annotation with term Core.Messages. Each item within the array-valued instance annotation SHOULD correspond to a single failed member matching the request and SHOULD have a target with the id of the failing member, which may be absolute or relative.

OPEN: how to "target" non-entity members, i.e. primitive or complex instances? Even index is problematic

[‎06.‎06.‎2019 17:58]

Mike: imagine error on fifth item

[‎06.‎06.‎2019 17:58]

Response is four items plus next-link plus error message stating that the fifth could not be retrieved

[‎06.‎06.‎2019 17:59] Hubert Heijkers:

I'm back ;)

[‎06.‎06.‎2019 17:59]

Question: will the next-link request will try to fetch the fifth item, or will it continue with the sixth

[‎06.‎06.‎2019 17:59]

@Hubert: cool :)

[‎06.‎06.‎2019 18:02]

Mike: could inject an "error object" in responses as client needs to specify Prefer:continue-on-error to get this new behavior

[‎06.‎06.‎2019 18:03]

Hubert: current implementation fails the request because something is wron

[‎06.‎06.‎2019 18:04]

Ralf: V2 "multi-origin" implementation returns partial result with next-link that will try to re-fetch the missing parts

[‎06.‎06.‎2019 18:05]

Mike: return a "reference object" with an instance annotation describing the problem

[‎06.‎06.‎2019 18:11] Ericson, George:

An implementation of Continue on Error: https://www.dmtf.org/sites/default/files/standards/documents/DSP0210_2.0.0.pdf

[‎06.‎06.‎2019 18:12] Ericson, George:

And http://www.dmtf.org/standards/published_documents/DSP0223_2.0.pdf

[‎06.‎06.‎2019 18:18]

ODATA-1299 is OPEN

[‎06.‎06.‎2019 18:18]

v. ODATA-1298 Clarify creation choreography for media entities, recommend stream properties

[‎06.‎06.‎2019 18:18]

No Title

Proposal:

Add

· as a second paragraph to Protocol, section 11.2.3 Requesting the Media Stream of a Media Entity using $value, and

· after the second sentence to first paragraph of CSDL JSON/XML, section 6.4 Media Entity Type

the following guidance

Use a media entity if the out-of-band stream is the main topic of interest and the media entity is just structured additional information attached to the stream. Use a normal entity with one or more stream properties if the structured data of the entity is the main topic of interest and the stream data is just additional non-structured information attached to the structured data.

Add green text to first paragraph of Protocol, section 11.4.7.1 Create a Media Entity

A POST request to a media entity's entity set creates a new media entity. The request body MUST contain the media value (for example, the photograph) whose media type MUST be specified in a Content-Type header. The request body is always interpreted as the media value, even if it has the media type of an OData format supported by the service, such as application/json. It is not possible to create a media entity directly.

[‎06.‎06.‎2019 18:20]

Mike: rephrase last sentence

[‎06.‎06.‎2019 18:21]

It is not possible to set the structural properties of the media entity directly.#

[‎06.‎06.‎2019 18:22] Mike Pizzo:

It is not possible to set the structural properties when creating the media entity.

[‎06.‎06.‎2019 18:30] Mike Pizzo:

I move we resolve ODATA-1298 with the revised proposal.

[‎06.‎06.‎2019 18:30] Hubert Heijkers:

I second

[‎06.‎06.‎2019 18:30]

ODATA-1298 is RESOLVED with the revised proposal

[‎06.‎06.‎2019 18:31]

vi. ODATA-1297 JSON Batch: clarify values of body property, context URL, batch in batch, continue-on-error

[‎06.‎06.‎2019 18:31]

No Title

Description

Clarify:

1. Can the body property in request/response object have the value null? If yes, does this mean "empty body" or "no body"? See also next question.

2. Can responses with status:204 have a body?

3. "Textual media types" are represented as a string: what exactly are "textual media types"?

4. RFC 7230 distinguishes between "message body" and "payload body": which one is body, i.e. can a Transfer-Encoding (gzip, chunked, ...) be applied?

5. What is the context URL of a JSON batch request or JSON batch response?

6. Can a request object within a JSON batch request be itself a (JSON) batch request?

7. Why do we allow the preference continue-on-error=false at all? The client can specify explicit dependencies with dependsOn if it wants certain dependency chains to stop at first error.

[‎06.‎06.‎2019 18:33]

ODATA-1297 is OPEN

[‎06.‎06.‎2019 18:33]

No Title

Proposal:

1. Yes, "body":null and omitting the body property both mean "no body"
2. Yes, "body":null
3: Either

· Use base64url encoding also for "textual" media types, only application/jsongets special treatment,

· add an indicator "bodyIsText":true or similar to indicate that the body is not base64url-encoded

4. body content can be compressed/chunked if correctly reflected in Transfer-Encoding header
5. explicitly mention that these don't have a context URL
6. Part 1: Protocol clearly defines which requests can be inside a batch request, and batch is not listed:

Batch requests allow grouping multiple individual requests into a single HTTP request payload. An individual request in the context of a batch request is a Metadata Request, Data Request, Data Modification Request, Action invocation request, or Function invocation request.

7. If processing stops on error the batch response can be incomplete, whereas with dependsOn the batch response would contain a response for each individual request which has status:412 if the request has been skipped due to a failed dependency

[‎06.‎06.‎2019 18:37]

Mike: agree to all except 3, which may need more discusssion

[‎06.‎06.‎2019 18:37]

Hubert: agree, split out in separate issue

[‎06.‎06.‎2019 18:39] Ericson, George:

Motion to resolve items 1,2, 4, 5, 6 and 7 as proposed.

[‎06.‎06.‎2019 18:40] Mike Pizzo:

I second

[‎06.‎06.‎2019 18:41]

ODATA-1297 is RESOLVED with the revised proposal

[‎06.‎06.‎2019 18:41]

vii. ODATA-1296 Allow all non-whitespace characters in a search word, and allow unbalanced quotes and parentheses

1. https://github.com/oasis-tcs/odata-abnf/pull/18/files

[‎06.‎06.‎2019 18:42]

$search="
$search="b
$search="bl
$search="blu
$search="blue
$search="blue%20
$search="blue%20p
$search="blue%20pi
$search="blue%20pil
$search="blue%20pill
$search="blue%20pill"

[‎06.‎06.‎2019 18:43]

Proposal:

Make $search a pass-through query option, impose no syntax, and impose no other restrictions than what is necessary to parse the URL:

· ampersands and semicolons need to be percent-encoded to allow detecting the end of the query option value both when used at the top level and when nested within $select or $expand

· parentheses need to be balanced to allow use within the /search(...) transformation in the Aggregation extension

Make V4 $search syntax just an optional recommendation.

Add a Capabilities term of type URL that allows pointing to the search syntax supported by the service, which may be the V4 $search syntax. Note: this resolves ODATA-1113.

[‎06.‎06.‎2019 18:45]

Mike: kind of like it, yet it is a pretty big change

[‎06.‎06.‎2019 18:46] Mike Pizzo:

...but concerned about how clients would use $search if they didn't know what they could put there.

[‎06.‎06.‎2019 18:47] Mike Pizzo:

the original point was to have a consistent way for the client to do basic search.

if we wanted to do specific syntaxes, we could do so through alternate query options.

[‎06.‎06.‎2019 18:49] Mike Pizzo:

or a variant of $search that specifies a (registered) sytnax, i.e. $search:lucene= ....

[‎06.‎06.‎2019 18:49]

viii. ODATA-1005 Make sure we have capabilities for all new 4.01 functionality

1. https://github.com/oasis-tcs/odata-vocabularies/pull/45/files

[‎06.‎06.‎2019 18:50]

No Title

Description

Do this in conjunction with conformance, so clients have a way to determine which optional parts of 4.01 are supported by a service.

Things already covered:

· POST/PATCH/PUT with system query options to shape response:

· $select with nested query options:

· $compute with insert/update:

· Deep update: DeepUpdateSupport

Things covered by the referenced pull request:

· Upsert: UpdateRestrictions/Upsertable

· PATCH on collection using delta format - with differentiation "only upsert" and "upsert and delete": UpdateRestrictions/CollectionUpdate

· PATCH with filter path segment: UpdateRestrictions/CollectionUpdate/FilterSegmentSupported

· PATCH with typecast segment: UpdateRestrictions/CollectionUpdate/TypecastSegmentSupported

· DELETE with filter path segment: DeleteRestrictions/FilterSegmentSupported

· DELETE with typecast segment: DeleteRestrictions/TypecastSegmentSupported

· POST with type cast segment: InsertRestrictions/TypecastSegmentSupported

· POST to collections of complex/primitive types: CollectionPropertyRestrictions/Insertable

· /$filter segment for invoking bound actions/functions: OperationRestrictions/FilterSegmentSupported

· Operators in, divby: FilterFunctions, mention that empty list means "just try"

· $compute with read: ComputeSupported on entity set

· $expand for stream properties and media resources: ExpandRestrictions/StreamsExpandable

· headers and query options without prefix, case-insensitive query options: minimum requirement for V4.01: RelaxedSystemQueryOptionNamesSupported

· /$query segment: QuerySegmentSupported

[‎06.‎06.‎2019 18:50]

Pull request https://github.com/oasis-tcs/odata-vocabularies/pull/45

[‎06.‎06.‎2019 18:51]

https://issues.oasis-open.org/browse/ODATA-1307

[‎06.‎06.‎2019 18:52] Mike Pizzo:

GET Products?$expand=Sales($apply=aggregate(Amount with sum as Total))
@odata.context in result should look like:
"@odata.context":"$metadata#Poducts(Salees(Amount)",

[‎06.‎06.‎2019 18:52] Mike Pizzo:

I believe the context should be:
"@odata.context":"$metadata#Products(Sales(Total))",

[‎06.‎06.‎2019 18:53]

ODATA-1307 is OPEN

[‎06.‎06.‎2019 18:53] Ericson, George:

Move to resolve OData-1307 as applied.

[‎06.‎06.‎2019 18:54] Hubert Heijkers:

I second

[‎06.‎06.‎2019 18:54] Krause, Gerald:

I second

[‎06.‎06.‎2019 18:55]

ODATA-1307 is RESOLVED as proposed

[‎06.‎06.‎2019 18:55] Mike Pizzo:

I move we close ODATA-1307 as applied.

[‎06.‎06.‎2019 18:55] Ericson, George:

second

[‎06.‎06.‎2019 18:55]

No objections, motion passes

[‎06.‎06.‎2019 18:56]

8 Next meetings [9:50 am PT]

1. Thursday June 13, 2019 during 8-10 am PDT (17:00-19:00 CEST)

2. Tuesday June 18 & Wednesday June 19, 2019 during 9 am to 6 pm PDT (18:00-03:00+1 CEST)

i. Face-to-face pre-meeting, optional

1. Thursday June 20 & Friday June 21, 2019 during 9 am to 5 pm PDT (18:00-02:00+1 CEST)

i. Face-to-face meeting, official part

[‎06.‎06.‎2019 18:56]

Hubert can't attend on June 13

[‎06.‎06.‎2019 18:56]

9. AOB and wrap up [9:55 am PT]

[‎06.‎06.‎2019 18:58]

Meeting is adjoured

From: odata@lists.oasis-open.org <odata@lists.oasis-open.org> On Behalf Of Handl, Ralf
Sent: Donnerstag, 23. Mai 2019 19:01
To: odata@lists.oasis-open.org
Subject: [CAUTION] [odata] Agenda for OData TC meeting on 2019-06-06

Here [1] is a draft agenda for the OData TC (Technical Committee) meeting scheduled on Thursday June 06, 2019 during 8-10 am PDT (17:00-19:00 CEST). For additional information, such as dial-in details and chat room, refer to [2]. For TC timeline, see [3]. Feel free to suggest additions or modifications.

Thanks.

[1] Agenda

Roll call [8:00 am PT]

Self-registration link: https://www.oasis-open.org/apps/org/workgroup/odata/event.php?event_id=47989

Approve agenda [8:05 am PT]

Approve minutes from previous meeting(s) [8:10 am PT]

Minutes from May 16, 2019 TC meeting: https://www.oasis-open.org/committees/download.php/65335/Minutes%20of%202019-05-16%20Meeting%20%23259.docx

Review action items [Action item list: https://www.oasis-open.org/apps/org/workgroup/odata/members/action_items.php?sort_field=due_closed_date] [8:15am PT]

Upcoming

i. #0037 Concept for Google Protocol Buffers as a data format – Hubert Heijkers – 2019-06-27

In progress

i. #0036 Register the OData- headers and preferences with IANA – Mark Biamonte – 2019-06-21

Face-to-Face Meeting 2019 [8:15 am PT]

Date

i. CW 25 2019, June 17-21

ii. Pre-Meeting Tuesday June 18 and Wednesday June 19, attendance is optional

iii. Face-to-Face-Meeting Thursday June 20 and Friday June 21, counts towards voter eligibility

Location

i. 228 South Street, Hopkinton, MA 01748…

Proposed agenda

i. Tuesday June 18

Prepare proposals for all remaining V4.01 issues
IANA registration for headers and preferences – only OData-specific versions as suggested by Mark Nottingham?
Extension for Temporal Data – discuss new approach for preserving service structure

ii. Wednesday June 19

Extension for Data Aggregation – Hierarchies
REST-EZ (aka REST Profile for OData)

iii. Thursday June 20

Finalize V4.01
Repeatable Requests – document walkthrough
OData-to-OpenAPI Mapping – document walkthrough (changes only)

iv. Friday June 21

REST-EZ (aka REST Profile for OData)
Marketing & Rebranding
Infrastructure & tools for producing and consuming OData easier

V4.01: Document Walkthrough [8:20 am PT]

Part 1: Protocol – https://www.oasis-open.org/committees/download.php/65201/odata-v4.01-wd06-part1-protocol-2019-04-25.docx

Finished

Part 2: URL Conventions – https://www.oasis-open.org/committees/download.php/65265/odata-v4.01-wd06-part2-url-conventions-2019-05-09.docx

Finished

CSDL JSON – https://www.oasis-open.org/committees/download.php/65361/odata-csdl-json-v4.01-wd05-2019-05-23.docx

Finished

CSDL XML – https://www.oasis-open.org/committees/download.php/65362/odata-csdl-xml-v4.01-wd06-2019-05-23.docx

Finished

JSON Format – https://www.oasis-open.org/committees/download.php/65363/odata-json-format-v4.01-wd06-2019-05-23.docx

Finished

What’s New – https://www.oasis-open.org/committees/download.php/65364/new-in-odata-v4.01-wd03-2019-05-23.docx

Finished

Motion to close all applied issues for V4.01

I move to close ODATA-1088, ODATA-1114, ODATA-1141, ODATA-1146, ODATA-1149, ODATA-1150, ODATA-1151, ODATA-1154, ODATA-1164, ODATA-1165, ODATA-1166, ODATA-1168, ODATA-1170, ODATA-1172, ODATA-1173, ODATA-1174, ODATA-1177, ODATA-1178, ODATA-1180, ODATA-1187, ODATA-1188, ODATA-1189, ODATA-1195, ODATA-1196, ODATA-1197, ODATA-1203, ODATA-1207, ODATA-1208, ODATA-1210, ODATA-1211, ODATA-1212, ODATA-1213, ODATA-1217, ODATA-1219, ODATA-1220, ODATA-1221, ODATA-1231, ODATA-1236, ODATA-1238, ODATA-1240, ODATA-1242, ODATA-1243, ODATA-1245, ODATA-1250, ODATA-1251, ODATA-1252, ODATA-1254, ODATA-1257, ODATA-1258, ODATA-1259, ODATA-1260, ODATA-1263, ODATA-1265, ODATA-1266, ODATA-1267, ODATA-1268, ODATA-1270, ODATA-1272, ODATA-1274, ODATA-1277, ODATA-1278, ODATA-1280, ODATA-1282, ODATA-1284, ODATA-1286, ODATA-1288, ODATA-1290, ODATA-1291, ODATA-1292, ODATA-1294, and ODATA-1295 as applied

Issues [8:20 am PT]

V4.01: NEW or OPEN

i. ODATA-1303 Clarify whether schemas traversed in path expressions must be in scope

ii. ODATA-1302 Support PUT to replace a collection of entities

iii. ODATA-1301 Can nullable singletons be deleted or created?

iv. ODATA-1299 Continue-on-Error for Collection requests

v. ODATA-1298 Clarify creation choreography for media entities, recommend stream properties

vi. ODATA-1297 JSON Batch: clarify values of body property, context URL, batch in batch, continue-on-error

vii. ODATA-1296 Allow all non-whitespace characters in a search word, and allow unbalanced quotes and parentheses

https://github.com/oasis-tcs/odata-abnf/pull/18/files

viii. ODATA-1005 Make sure we have capabilities for all new 4.01 functionality

https://github.com/oasis-tcs/odata-vocabularies/pull/45/files…

Data Aggregation: NEW or OPEN

i. ODATA-1218 Transformations for recursive hierarchy processing

ii. ODATA-945 Correct examples 53 and 54

Vocabularies: NEW or OPEN with concrete proposal

i. ODATA-1304 Improve descriptions on Capabilities.NavigationRestrictionsType

https://github.com/oasis-tcs/odata-vocabularies/pull/51/files…

ii. ODATA-1300 Capabilities: add ExpandRestrictions to type NavigationPropertyRestriction

https://github.com/oasis-tcs/odata-vocabularies/pull/50/files…

Vocabularies: NEW or OPEN that need more discussion

i. ODATA-1275 Describing and querying "JSON properties"

ii. ODATA-1214 Annotate constructor actions

iii. ODATA-1140 Add details to HttpResponse

iv. ODATA-1107 Introduce instance annotation to specify which types an instance "implements"

v. ODATA-1060 Improve specification of element response requirements

vi. ODATA-884 Allow describing possible responses to requests for a particular resource (public comment c201510e00019)

Next meetings [9:50 am PT]

Thursday June 13, 2019 during 8-10 am PDT (17:00-19:00 CEST)
Tuesday June 18 & Wednesday June 19, 2019 during 9 am to 6 pm PDT (18:00-03:00+1 CEST)

i. Face-to-face pre-meeting, optional

Thursday June 20 & Friday June 21, 2019 during 9 am to 5 pm PDT (18:00-02:00+1 CEST)

i. Face-to-face meeting, official part

AOB and wrap up [9:55 am PT]

[2] References

Conference call, Chat & Screen sharing: https://lync.co.sap.com/meet/ralf.handl/Q4QB1098
Conference call details: https://www.oasis-open.org/apps/org/workgroup/odata/download.php/63673/latest/TC%20meeting%20dial-in%20details.htm

[3] Timeline

https://www.oasis-open.org/committees/download.php/64563/TC%20Timeline%202019-01-23.docx

odata message