RE: Agenda for OData TC meeting on 2019-10-24

[‎24.‎10.‎2019 16:54]

[1] Agenda

1. Roll call [8:00 am]

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

Voting Members: 1 of 9 (11%) (used for quorum calculation)

We saved this conversation. You'll see it soon in the Conversations tab in Skype for Business and in the Conversation History folder in Outlook.

[‎24.‎10.‎2019 17:01]

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

[‎24.‎10.‎2019 17:01]

Quorum achieved: yes

[‎24.‎10.‎2019 17:03]

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

[‎24.‎10.‎2019 17:04]

2. Approve agenda [8:05 am]

[‎24.‎10.‎2019 17:04]

Agenda is approved

[‎24.‎10.‎2019 17:05]

3. Approve minutes from previous meeting(s)

a. Minutes from October 17, 2019 TC meeting: https://www.oasis-open.org/committees/download.php/66061/Minutes%20of%202019-10-17%20Meeting%20%23271.docx

[‎24.‎10.‎2019 17:05]

Minutes are approved

[‎24.‎10.‎2019 17:05]

No Title

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:15 am]

a. Upcoming

i. #0039 Concept for Compact JSON data format – Hubert Heijkers – 2020-01-31

ii. #0037 Concept for binary data format – Hubert Heijkers – 2020-03-26

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

[‎24.‎10.‎2019 17:06] Mark Biamonte:

Hi Sabrina,

Prior to submission of the Header Registration request to IANA we sent an initial proposal for the request to the email discussion list. In the initial proposal the names of the headers we are looking to register for the OData standard did not include the OData- prefix. I.E that initial request defined an “Isolation” header. We received feedback from the email discussion list (primarily from a Mr Mark Nottingham) that the name “Isolation” was too generic a term. It was also pointed out that although we feel that the Isolation concept as defined by the OData specification is applicable to other standards as well we don’t have other communities that have agreed to the definition as defined by the OData specification. Given that feedback we decided that we would register the header with the more OData specific name “OData-Isolation”.

Outside of the IANA registration process we received feed back from users of the OData standard that having to maintain the OData prefix in all of the headers was cumbersome and too verbose. To address that concern the OData services will recognize headers both with and without their OData- prefix. The registered versions of the headers will have the OData- prefix. Users choosing to use header names without the OData- prefix do so with the knowledge that that un-prefixed header may collide with a header defined by another standard if the OData standard is used in conjunction with that other standard.

It is correct that we don’t make it clear in the spec that the registered name of the header is the version with the OData- prefix. We will discuss rectifying that with the OData standards committee.

[‎24.‎10.‎2019 17:12] Mark Biamonte:

Outside of the IANA registration process we received feed back from users of the OData standard that having to maintain the OData prefix in all of the headers was cumbersome and too verbose. To address that concern the OData services will recognize headers both with and without their OData- prefix. The registered versions of the headers will have the OData- prefix. Existing users choosing to use header names without the OData- prefix today do so with the knowledge that that un-prefixed header may collide with a header defined by another standard if the OData standard is used in conjunction with that other standard.

[‎24.‎10.‎2019 17:14] Mark Biamonte:

Outside of the IANA registration process we received feed back from users of the OData standard that having to maintain the OData prefix in all of the headers was cumbersome and too verbose. To address that concern OData services recognize headers both with and without their OData- prefix. The registered versions of the headers will have the OData- prefix. Existing users choosing to use header names without the OData- prefix today do so with the knowledge that that un-prefixed header may collide with a header defined by another standard if the OData standard is used in conjunction with that other standard.

[‎24.‎10.‎2019 17:21]

5. Repeatable Requests [8:20 am]

a. Document Walkthrough

i. https://www.oasis-open.org/committees/download.php/66069/repeatable-requests-v1.0-wd01-2019-10-10.docx

[‎24.‎10.‎2019 17:24] Ericson, George:

I move that the TC approve Repeatable Requests Version 1.0 Working Draft 01 uploaded as https://www.oasis-open.org/committees/download.php/66071/repeatable-requests-v1.0-wd01-2019-10-17-final.docx as Committee Note Draft 01 and designate the Microsoft Word version as authoritative. I further move that the TC approve submitting the aforementioned Committee Note Draft 01 for 30 days of public review.

[‎24.‎10.‎2019 17:25] Borges, Matt:

[‎24.‎10.‎2019 17:25] Mark Biamonte:

I second

[‎24.‎10.‎2019 17:25] Mike Pizzo:

I second

[‎24.‎10.‎2019 17:26]

No objection, motion passes

[‎24.‎10.‎2019 17:26]

6. Issues [8:50 am]

a. APPLIED

i. None

b. V4.01: NEW or OPEN

i. ODATA-1337 Clarify use of @Core.ContentId in delta update

[‎24.‎10.‎2019 17:34]

ODATA-1337 is OPEN

[‎24.‎10.‎2019 17:35]

Added/changed entities are applied as upserts, and deleted entities as deletions. Non-key properties of deleted entities are ignored. The top-level collection may include added and deleted links, and related entities represented inline are updated according to the rules for treating related entities when updating an entity.

[‎24.‎10.‎2019 17:35]

No Title

Clients MAY associate an id with individual nested entities in the request by using the Core.ContentID term defined in [OData-VocCore]. Services that respond with 200 OK SHOULD annotate the entities in the response using the same Core.ContentID value as specified in the request. Services SHOULD advertise support for deep updates, including support for returning the Core.ContentID, through the Capabilities.DeepUpdateSupport term, defined in [OData-VocCap].

[‎24.‎10.‎2019 17:49] Mike Pizzo:

Proposed wording:
Clients MAY associate an id with individual nested entities in the request by using the Core.ContentID term defined in [OData-VocCore]. Services that respond with 200 OK SHOULD annotate the entities in the response using the same Core.ContentID value as specified in the request.

Services SHOULD advertise support for updating a collection using a delta payload using the DeltaUpdateSupported property of the Capabilities.UpdateRestrictions vocabulary term, and SHOULD advertise support for returning the Core.ContentID in the response to a delta update through the Capabilities.DeepUpdateSupport term, both defined in [OData-VocCap].

[‎24.‎10.‎2019 17:50]

11.4.12 Update a Collection of Entities

[‎24.‎10.‎2019 17:51] Mike Pizzo:

I move to resolve ODATA-1337 as proposed.

[‎24.‎10.‎2019 17:51] Borges, Matt:

I second

[‎24.‎10.‎2019 17:52]

ODATA-1337 is RESOLVED as proposed

[‎24.‎10.‎2019 17:52]

ii. ODATA-1333 Add Terms, Abbreviated Terms, and Symbols sections to specifications

[‎24.‎10.‎2019 17:53]

c. Vocabularies: NEW or OPEN with concrete proposal

i. ODATA-1275 Describe structure of "JSON properties"

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

[‎24.‎10.‎2019 17:54]

Create a type definition Core.JSON, similar to Core.LocalDateTime:

· type Edm.Stream

· annotated with Core.AcceptableMediaTypes, listing application/json

Create a new JSON vocabulary containing terms and functions specific to JSON stream properties.

Term JSON.Schema to allow referencing a JSON Schema describing/restricting the values of a JSON stream property.

Functions for querying JSON properties will be covered by ODATA-1336

[‎24.‎10.‎2019 17:55]

ODATA-1275 is OPEN

[‎24.‎10.‎2019 18:13]

Discussion: JSON annotation values should ideally be inline JSON in CSDL JSON

[‎24.‎10.‎2019 18:14]

Could do this by defining JSON.Schema with type Edm.Stream and annotation it as a "JSON Property"

[‎24.‎10.‎2019 18:14]

Which would allow to annotate the term with itself, pointing to the JSON Schema of JSON Schema

[‎24.‎10.‎2019 18:14]

Open: how to represent Stream annotation values in XML?

[‎24.‎10.‎2019 18:15]

Could allow either <String> or <Binary>, depending on the media type of the encoded stream value, String for textual, Binary otherwise

[‎24.‎10.‎2019 18:15]

Ralf to cross-check with Evan who maybe already has annotations with XML or JSON values

[‎24.‎10.‎2019 18:16]

7. OData Dictionary [9:20 am]

a. Document Walkthrough

i. https://www.oasis-open.org/committees/download.php/66043/odata_dictionary_v1.0.0.docx

ii. https://www.oasis-open.org/committees/download.php/66059/odata_dictionary_v1.0.0.md

[‎24.‎10.‎2019 18:28]

Ralf to put the Word version on the Editor's OneDrive and invite all TC members to edit it

[‎24.‎10.‎2019 18:28]

George to send his latest version to Ralf

[‎24.‎10.‎2019 18:48]

https://en.wikipedia.org/wiki/Multiset

We saved this conversation. You'll see it soon in the Conversations tab in Skype for Business and in the Conversation History folder in Outlook.

[‎24.‎10.‎2019 18:57]

8. Next meetings [9:50 am]

a. Thursday October 31, 2019 during 8-10 am PDT (16:00-18:00 CEST) – one hour earlier in Europe!

b. Thursday November 07, 2019 during 8-10 am PDT (17:00-19:00 CEST)

c. Thursday November 14, 2019 during 8-10 am PDT (17:00-19:00 CEST)

[‎24.‎10.‎2019 18:58]

George cannot make November 14

[‎24.‎10.‎2019 18:59]

November 28 is Thanksgiving in the US, no meeting

[‎24.‎10.‎2019 19:02] Ramesh Reddy:

I can not make any meeting in Nov either

[‎24.‎10.‎2019 19:02]

Ramesh will take a leave-

[‎24.‎10.‎2019 19:02]

of absence

[‎24.‎10.‎2019 19:03]

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

[‎24.‎10.‎2019 19:04]

Ralf to read up TC process re. Electronic Ballot for publishing CS02

[‎24.‎10.‎2019 19:04]

Meeting is adjourned

From: odata@lists.oasis-open.org <odata@lists.oasis-open.org> On Behalf Of Handl, Ralf
Sent: Mittwoch, 23. Oktober 2019 17:18
To: odata@lists.oasis-open.org
Subject: [CAUTION] [odata] Agenda for OData TC meeting on 2019-10-24

Here [1] is a draft agenda for the OData TC (Technical Committee) meeting scheduled on Thursday October 24, 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

1. Roll call [8:00 am]

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

2. Approve agenda [8:05 am]

3. Approve minutes from previous meeting(s)

a. Minutes from October 17, 2019 TC meeting: https://www.oasis-open.org/committees/download.php/66061/Minutes%20of%202019-10-17%20Meeting%20%23271.docx

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:15 am]

a. Upcoming

i. #0039 Concept for Compact JSON data format – Hubert Heijkers – 2020-01-31

ii. #0037 Concept for binary data format – Hubert Heijkers – 2020-03-26

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

5. Repeatable Requests [8:20 am]

a. Document Walkthrough

i. https://www.oasis-open.org/committees/download.php/66069/repeatable-requests-v1.0-wd01-2019-10-10.docx

b. Sample Motion for Public Review

i. I move that the TC approve Repeatable Requests Version 1.0 Working Draft 01 uploaded as https://www.oasis-open.org/committees/download.php/66071/repeatable-requests-v1.0-wd01-2019-10-17-final.docx as Committee Note Draft 01 and designate the Microsoft Word version as authoritative. I further move that the TC approve submitting the aforementioned Committee Note Draft 01 for 30 days of public review.

6. Issues [8:50 am]

a. APPLIED

i. None

b. V4.01: NEW or OPEN

i. ODATA-1337 Clarify use of @Core.ContentId in delta update

ii. ODATA-1333 Add Terms, Abbreviated Terms, and Symbols sections to specifications

c. Vocabularies: NEW or OPEN with concrete proposal

i. ODATA-1275 Describe structure of "JSON properties"

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

d. Vocabularies: NEW or OPEN that need more discussion

i. ODATA-1336 Querying “JSON properties”

ii. ODATA-1326 Enhance syntax of term Validation.OpenPropertyTypeConstraint