OData TC meeting #154 Thursday Dec 01, 2016

Acting chair: Ralf

Chat transcript from room: odatatc
2016-12-01 0800-1100 PT

1. Roll call

1.1 Members present

        Gerald Krause (SAP SE)
        Hubert Heijkers (IBM)
        Mark Biamonte (Progress Software)
        Matthew Borges (SAP SE) a.k.a. Matt
        Michael Pizzo (Microsoft) a.k.a. Mike
        Ralf Handl (SAP SE)
        Ramesh Reddy (Red Hat)
        Stefan Hagen (Individual)
        Susam Malaika (IBM)
        Ted Jones (Red Hat)

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

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

2. Approve agenda

Mike: discuss new Jira issues if time permits

Agenda is approved with above addition.

3. Approve minutes from previous meeting(s)

3.1 Minutes from November 17, 2016 TC meeting #152

https://www.oasis-open.org/committees/download.php/59408/odata-meeting-153_on-20161117-minutes.html

Minutes approved unchanged as published.

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

4.1 Action items due

4.1.1 AI#0036 - "Register the OData- headers and preferences with IANA"

Update next week - Action #0036 ongoing.

5. V4.01

5.1 Document Walkthrough

- OData Version 4.01 Part 1: Protocol - OData Version 4.01 Part 2: URL Conventions - OData Version 4.01 Part 3: CSDL - OData Common Schema Definition Language (CSDL) XML Representation Version 4.01 - OData JSON Format Version 4.01 - OData Vocabularies Version 4.0 - odata-vocabularies GitHub repository

5.1.1 OData Version 4.01 Part 1: Protocol

All walk through the document

Mike: do we want to keep the reference to the Atom Format? Open issue to track this.

Ramesh: if we don't want to continue Atom we need to put out a deprecation notice

Ralf: Ralf to follow up with Ram how to deprecate TC work products

Ralf: Finished walk-through, break until 18:20

Mark: I have a hard stop today at 1:00 ET. I will drop off the call at that time

Ralf: Continue walk-through

5.1.2 OData Version 4.01 Part 2: URL Conventions

All walk through the document

Ralf: Discussion on syntax for annotations in URLs, Hubert to open issue

Stefan: Hubert creates an issue as suggested by Mike, so the TC can decide on slash or not in some filter expressions

5.1.3 OData JSON Format Version 4.01

All walk through the document

Mark: Dropping from the call

5.1.4 OData Common Schema Definition Language (CSDL) XML Representation Version 4.01

All walk through the document

5.1.5 OData Vocabularies Version 4.0

Ralf walks all through the document and the corresponding online documentation at github

All discuss possible enhancements for workflow, like building the markdown documents from the xml files more automatically.

5.2 Motion

Stefan I move to close ODATA-545, ODATA-557, ODATA-613, ODATA-614, ODATA-743, ODATA-763, ODATA-786, ODATA-798, ODATA-811, ODATA-827, ODATA-876, ODATA-929, ODATA-933, ODATA-935, ODATA-954, ODATA-959, ODATA-960, ODATA-963, ODATA-964, ODATA-965, ODATA-966, ODATA-969, ODATA-970, ODATA-973, ODATA-974, ODATA-978, ODATA-979, ODATA-980, ODATA-981, ODATA-982, ODATA-983, ODATA-984, ODATA-985, ODATA-986, ODATA-987, ODATA-988, ODATA-989, ODATA-991, ODATA-992, ODATA-993, ODATA-995, ODATA-996, ODATA-997, ODATA-998, ODATA-1001, ODATA-1004, and ODATA-1006 as applied. Ramesh seconds.

Ralf: No objections, motion passes, the listed issues are CLOSED

6. Issue Processing

6.1 Open and new issues

6.1.1 ODATA-1009 - Clarify context url of delta responses for containment navigation properties

Ralf: Change current text:

The context URL of a delta response is the same as the context URL of the root entity set, followed by /$delta.

to new text:

The context URL of a delta response is the context URL of the response to the defining query, followed by /$delta.

If the entities are contained, then entity-set is the top-level entity set followed by the path to the containment navigation property of the containing entity.

Ralf: ODATA-1009 is OPEN

Mike: I move we approve ODATA-1009 as proposed. Matt seconds.

Ralf: ODATA-1009 is resolved as proposed

6.1.2 ODATA-1010 - Represent deleted entities similar to added/changed entities

Ralf: Allow representing deleted entities similar to added/changed entities

  { 
    "@odata.context":"#Orders/$entity", 
    "@odata.id":"Orders(10643)", 
    "ShippingAddress":{ 
    "Street":"23 Tsawassen Blvd.", 
    "City":"Tsawassen", 
    "Region":"BC", 
    "PostalCode":"T2F 8M4" 
    }, 
  }, 
  { 
    "@odata.context":"#Customers/$entityDeletion", 
    "@odata.id":"Customers('ANTON')", 
    "@odata.reason":"deleted", 
    /* optionally properties of the deleted entity */ 
   "CustomerID": "ANTON", 
   ... 
  } 

This would allow using the same serialization template. And it looks more consistent

Ralf: ODATA-1010 is OPEN

Mike: rather than introduce a new context URL suffix use this format in 4.01

Ralf: Could do this just for nested tombstones

Ralf: Would be more consistent to do this for all tombstones in 4.01

Ralf: Add the rule that @odata.id can be omitted if the key properties/values are included

Mike: If we think we might want to add additional information about the deletion, we could define a "removed" annotation and nest things like "reason" under this annotation:

  { 
    "@odata.context":"#Customers/$entityDeletion", 
    "@odata.id":"Customers('ANTON')", 
    "@odata.removed": 
      { 
       "reason":"deleted" 
       "@myannoation.deletedBy":"Mario", 
       "@myannotation.justification":"he didn't pay his bill" 
      }, 
    /* optionally properties of the deleted entity */ 
   "CustomerID": "ANTON", 
   ... 
  }
  

Ralf: Do not allow both tombstone representations in 4.01

Mike: not much value in adding a new suffix

Mike: I move we resolve ODATA-1010 with the revised proposal: Support the new representation with the existing /$deletedEntity everywhere in 4.01. Nest @odata.removed with a reason and additional annotations. Stefan seconds.

Ralf: ODATA-1010 is RESOLVED with the amended proposal

6.1.3 ODATA-1012 - Represent nested deltas as an annotation

Mike: The way we differentiate between these two is, in the case of a nested delta, by annotating the collection property with a context url specifying a delta:

"members@contextUrl":"#$delta", 
"members": [ ... ] 

Alternatively, we could just use a delta annotation prefixed with the property name, as in:

"members@delta": [ ... ] 

Which wouldn't require using the contextUrl annotation to interpret the property.

Matt and Ralf like this

Ralf: Ralf to follow up with client library team

Ralf: ODATA-1012 is OPEN

Stefan: I move to resolve ODATA-1012 as proposed. Matt seconds.

Ralf: ODATA-1012 is RESOLVED

7. Next meetings

7.1 Next Meeting Thursday December 08, 2016 during 07:00-10:00 am PT

Date and time of meeting agreed, note one hour earlier and 3 hours long.

Stefan: Event page updated during the meeting.

8. AOB and wrap up

No other business.

Meeting adjourned by chair.