OData TC meeting #205 Thursday March 01, 2018

Acting chair: Ralf

Chat transcript from room: odatatc
2018-03-01 0800-1000 PST

1. Roll call

1.1 Members present

    George Ericson (Dell)
    Gerald Kraue (SAP SE)
    # Hubert Heijkers (IBM)
    # Mark Biamonte (Progress Software)
    # Martin Zurmuehl (SAP SE)
    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)
    Ted Jones (Red Hat)

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

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

2. Approve agenda

Mike: timeline and prioritization of next steps

George: Redfish/Swordfish community seems fine with GitHub-based vocabularies

Ralf: No need for Errata 04 from that perspective

Ralf: https://issues.oasis-open.org/browse/ODATA-1155

Ralf: ABNF: allow omitting default namespaces everywhere in the URL

Ralf: Agenda is approved with these additions

3. Approve minutes from previous meeting(s)

3.1 Minutes from February 22, 2018 TC meeting #204

https://www.oasis-open.org/committees/download.php/62583/odata-meeting-204_on-20180222-minutes.html

Minutes approved unchanged as published.

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

4.1 Action items due

None.

5. Timeline and Prioritization of Next Steps

Ralf: https://www.oasis-open.org/committees/download.php/61677/TC Timeline-2017-09-29.docx

Ralf:

Whats New in OData Version 4.01
  September 2017  Approve Whats New in OData Version 4.01 CN02
OData Core and JSON Version 4.01
  September 2017 Initiate public review of CSD03
  November 2017  Approve OData Core and JSON Version 4.01 CS01
CSDL JSON Version 4.01
  September 2017 Initiate public review of CSD02
  November 2017  Approve CSDL JSON Version 4.01 CS01
    Not achieved
OData Vocabularies Version 4.0
  November 2017 Initiate public review of CSD02
  January 2018  Approve OData Vocabularies Version 4.0 CS01
OData to OpenAPI Mapping Version 1.0
  December 2017 Initiate public review of CND02 based on OpenAPI 3.0.0
  February 2018 Approve OData to OpenAPI Mapping Version 1.0 CN01
Planned next:
  REST Profile for OData Version 4.01
  - February 2018 Initiate public review of CND01
  - April 2018 Approve REST Profile for OData Version 4.01 CN01
  Securing OData Version 4.0
  - December 2017 Initiate public review of CND01
  - February 2018 Approve Securing OData Version 4.0 CN01

Mike: someone needs to prepare proposal for REST Profile

Mike: OpenAPI mapping might be next

George: vocabularies almost done

George: triage remaining vocabulary issues

Ralf:

1. Vocabularies
2. OpenAPI Mapping
3. REST Profile

Ralf: Ralf to ping Stefan regarding "Securing OData"

Ralf:

Extension for Data Aggregation Version 4.0
- July 2018 Initiate public review of CSD04
- September 2018 Approve Extension for Data Aggregation Version 4.0 CS03

Ralf: Mike volunteers to prepare a proposal for the REST profile

Ralf: Vocabularies: issues resolved and applied by end of march

Ralf: OpenAPI mapping: someone (default: Ralf) needs to apply issues identified in last walk-through December 2017

George: RedFish is also working on an OpenAPI mapping

Ralf: George to set up meeting with RedFish folks and Mike

Mike: take March to update OpenAPI mapping document and potentially work in DMTF feedback

Mike: initial REST Profile document by mid of April

Ralf: Ralf to create action item

Ralf: Data Aggregation: walk through "Grid-like Access" sometime within next six weeks to get feedback and direction

Ralf: V4.01 CS02

Mike: keep V4.01 open long enough to get feedback from implementation teams

Ralf: Three "statements of use" needed for progressing V4.01 to Candidate OASIS Standard

George: "OData Essentials" ???

Ralf: Nice name!

Ralf: Ralf to update timeline accordingly

6. Issues

6.1 APPLIED

6.1.1 ODATA-1132 - Propagation of NavigationRestrictions

Ralf: https://github.com/oasis-tcs/odata-vocabularies/pull/11

Ralf: Change: new long description for NavigationRestrictions:
"@Core.LongDescription": "Restrictions specified on an entity set are valid whether the request is directly to the entity set or through a navigation property bound to that entity set. Services can specify a different set of restrictions specific to a path, in which case the more specific restrictions take precedence."

Mike: I move we close ODATA-1132 as applied. George seconds.

Ralf: No objections, ODATA-1132 is CLOSED as applied

6.1.2 ODATA-1153 - Core.Immutable: clarify that value can be provided *by client* in insert

Ralf: https://github.com/oasis-tcs/odata-vocabularies/pull/10

Ralf: Immutable and ComputedDefaultValue: value can be provided by the client

Mike: I move we close ODATA-1153 as applied. George seconds.

Ralf: ODATA-1153 is CLOSED as applied

6.2 V4.01: NEW or OPEN

6.2.1 ODATA-1155 - ABNF: allow omitting default namespaces everywhere in the URL

Ralf: Relax ABNF to allow omitting namespaces for

- functions 
- actions 
- type-cast 
in 
- path 
- query options

Ralf: But NOT in the context URL.

Ralf: ODATA-1155 is OPEN

Mike: I move we make the ABNF consistent with the prose by resolving ODATA-1155 as proposed. George seconds.

Ralf: ODATA-1155 is RESOLVED as proposed

6.2.2 ODATA-1154 - Clarify which OData-Version a service should return

Ralf: The service MUST respond with the minimum of the request's OData-MaxVersion, if specified, and the maximum version of the protocol that the service implements.

Ralf: ODATA-1154 is OPEN

Mike: trickier than it seems at first glance

Mike: Proposed re-wording: The service MUST respond with a payload compliant with the greatest version of the protocol that is less than or equal to the request's OData-MaxVersion, if specified.

George: Add 'supported'

George: The service MUST respond with a payload compliant with the greatest supported version of the protocol that is less than or equal to the request's OData-MaxVersion, if specified.

Mike: potential gap for clients that support only 4:01

Mike: OData-Version should only tell what was used to generate the request body, not the URL

Ralf: Problem are "scared recipients" that stop processing on receiving OData-Version:4.01

George: Rightly so, since a 4.0 client may not understand a 4.01 response.

Mike: If a client only understands the 4.0 payload format (in requests, as well as responses) but wants to use a URL construct introduced in 4.01 (which a 4.0 service is allowed to support), then I would want to say that my request is a 4.0 request (because the payload is a 4.0 payload) but use a 4.01 construct.

Mike: Can either say odata-version only describes the payload, or we can say it describes the request but the request may include compatible extensions introduced in later versions of the payload.

Mike: distinguish version of protocol and version of format

Mike: Probably adds unnecessary complexity to try and separately specify payload version and url/protocol version.

Ralf: Mike to craft a more detailed proposal

Mike: Open Questions:

Questions:
1) What if no OData-MaxVersion is specified?
2) Does specifying an OData-Version limit the constructs that the request can use in the URL? 
   i.e., if I have a 4.0 payload, am I restricted to 4.0 URL constructs, even if I know the service supports them?
3) What if the client *only* support 4.01? Do we have a way to specify NOT to return 4.0?
4) Does a service have to return a 4.01 payload if the request uses a 4.01 construct?

6.2.3 ODATA-1151 - Edm.Stream and Nullable

Ralf: Can stream properties be nullable?

If yes, how would a null value be represented? 
- if expanded: "streamProp":null 
- if not expanded: "streamProp@mediaReadLink":null, i.e. no link?

Ralf: What if that stream property is directly accessed

Ralf: GET es(1)/streamProp

Ralf: Would that be 204, 404, or 200 with Content-Length:0

Ralf: ODATA-1151 is OPEN

Mike: expanded representation makes sense

Mike: you'd need an edit link in order to write/create it

Mike: Can we say:

1) Expanded returns null
2) Link is always valid, returns 204 if the value is null

Ralf: Same behavior as for navigation properties

Ralf: Ralf to craft proposal conforming to discussion and nav prop behavior

6.2.4 ODATA-1150 - Case Sensitivity of Property Names, EntitySets, Singletons and Operations

Ralf: Proposal:

Interoperable clients SHOULD specify identifiers (in payloads and URLs) in the case they are specified in $metadata. 

Services MUST return identifiers (payloads, contextUrl, etc.) in the case defined in $metadata. 

Services SHOULD NOT have identifiers within a uniqueness scope that differ only by case. 

Services MAY support case-insensitive comparisons of identifiers in URLs and request payloads 
if no exact match is found, following the existing precedence rules.

Ralf: ODATA-1150 is OPEN

Ralf: Would prefer MUST for interoperable clients

Ralf: Non-interoperable clients are free to send arbitrary requests

Ralf: MAY also for 4.01 services

Mike: not worth defining a capability for this

Mike: interoperable clients will use $metadata case

Mike: Updated proposal (just changed "SHOULD" to "MUST" for interoperable clients):

Interoperable clients MUST specify identifiers (in payloads and URLs) in the case they are specified in $metadata. 

Services MUST return identifiers (payloads, contextUrl, etc.) in the case defined in $metadata. 

Services SHOULD NOT have identifiers within a uniqueness scope that differ only by case. 

Services MAY support case-insensitive comparisons of identifiers in URLs and request payloads 
if no exact match is found, following the existing precedence rules.

Mike: I move we resolve ODATA-1150 as proposed. Ted seconds.

Ralf: ODATA-1150 is RESOLVED with the modified proposal

6.3 Vocabularies: NEW or OPEN with concrete proposal

6.3.1 ODATA-1064 - Add ability to annotate collections to return only count and NextLink

Ralf:

---------------- 
Add new example to Prefer header to showing use of count and navigation links 
-------------------- 
To OData Version 4.01. Part 1: Protocol, clause 8.2.8.4 Preference include-annotations (odata.include-annotations) 
Add: 
Example 8: a Prefer header requesting that navigation links be returned in the case that the \
  format metadata=minimal is specified in the Accept header. 
      Prefer: include-annotations="odata.navigationLink,odata.count" 

Add paragraph before example 3. 
Regardless of the metadata format specified, annotations specified by the include-annotations preference should be added to response.

-------------------- 
Example: 

------------------ 
Proposed schema 
<EntityType Name="Top"> 
       
      <NavigationProperty Name="Systems" Type="Collection(ComputerSystem)"/> 
       
</EntityType> 
---------- 
Example: GET 

GET /redfish/v1/Top 
Prefer: include-annotations="odata.count,odata.navigationLink" 

Response 
Preferences-Applied: include-annotations="odata.count,odata.navigationLink" 
{ 
"@odata.context": "/redfish/v1/$metadata#Top", 
"@odata.id": "/redfish/v1/Top", 
"@odata.type": "#Top ", 
"Name": "Top", 
 
"Systems@odata.count": 15, 
"Systems@odata.navigationLink": {"/redfish/v1/Systems"} 
 
}

Ralf: Current JSON Format spec text:
In addition, the client may use the include-annotations preference in the Prefer header to request additional control information. Services supporting this MUST NOT omit control information required by the chosen metadata parameter, and services MUST NOT exclude the nextLink, deltaLink, and count if they are required by the response type.

George: Alternative: include-controls preference

Ralf: Note: this paragraph was already in V4

7. Next meetings

Ralf:

Thursday March 08, 2018 during 8-10 am PST (17:00-19:00 CET)
Thursday March 15, 2018 during 8-10 am PST (16:00-18:00 CEST)  Daylight Saving Time in Central Europe

Ralf: Mike might not attend next week

Ralf: Mike to send "minimum list" of vocab issues from his perspective

8. AOB and wrap up

None

Meeting adjourned by chair.