Acting chair: Ralf
Chat transcript from room: odatatc 2018-03-01 0800-1000 PST
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.
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
https://www.oasis-open.org/committees/download.php/62583/odata-meeting-204_on-20180222-minutes.html
Minutes approved unchanged as published.
None.
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
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
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
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
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?
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
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
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
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
None
Meeting adjourned by chair.