Subject: RE: [odata] Agenda for OData TC meeting on 2017-05-18 - chat transcript
[17:04] Ralf Handl (SAP SE): 1.Roll call [8:00 am PT]
a.Self-registration link: https://www.oasis-open.org/apps/org/workgroup/odata/event.php?event_id=43978
[17:05] Ralf Handl (SAP SE): Dial-in information: https://www.oasis-open.org/apps/org/workgroup/odata/download.php/56760/latest
Online chat room: http://webconf.soaphub.org/conf/room/odatatc
Screen sharing: https://sap.emea.pgiconnect.com/OData-TC/
[17:06] Michael Pizzo: Link to minutes from last meeting should be: https://www.oasis-open.org/apps/org/workgroup/odata/download.php/60730/odata-meeting-174_on-20170511-minutes.html
[17:07] Ralf Handl (SAP SE): Voting Members: 5 of 11 (45%) (used for quorum calculation)
[17:09] Stefan Hagen: Voting Members: 6 of 11 (54%) (used for quorum calculation)
[17:09] Stefan Hagen: Sorry travelling
[17:09] Stefan Hagen: quorum should be reached
[17:09] Ralf Handl (SAP SE): Thanks!
[17:10] Ralf Handl (SAP SE): 2.Approve agenda [8:05 am PT]
[17:11] Ralf Handl (SAP SE): Gerald to share news on the Data Aggregation spec
[17:11] Ralf Handl (SAP SE): Mike: new issue
[17:11] Martin Zurmuehl (SAP SE): I'm in, sorry! Quorum reached.
[17:12] Ralf Handl (SAP SE): ODATA-1077 Include atomicityGroup in JSON Batch Response
[17:12] Ralf Handl (SAP SE): ODATA-1076 If-Match and If-None-Match: align wording with RFC7232
[17:13] Ralf Handl (SAP SE): Mike: start with these two issues before document walkthrough
[17:14] Ralf Handl (SAP SE): Geralds topic after #3
[17:14] Ralf Handl (SAP SE): Agenda is approved with these additions
[17:14] Ralf Handl (SAP SE): 3.Approve minutes from previous meeting(s) [8:10 am PT]
a.Minutes from May 11, 2017 TC meeting: https://www.oasis-open.org/committees/download.php/60691/odata-meeting-173_on-20170504-minutes.html
[17:14] Michael Pizzo: Correct link: https://www.oasis-open.org/apps/org/workgroup/odata/download.php/60730/odata-meeting-174_on-20170511-minutes.html
[17:15] Stefan Hagen: @Mike: Thanks.
[17:16] Ralf Handl (SAP SE): Minutes are approved with these changes
[17:16] Ralf Handl (SAP SE): New agenda item: Gerald on Data Aggregation
[17:20] Ralf Handl (SAP SE): 4.Review action items [Action item list: https://www.oasis-open.org/apps/org/workgroup/odata/members/action_items.php] [8:15am PT]
a.Action items due
[17:21] Ralf Handl (SAP SE): 5.V4.01 [8:20 am PT]
[17:21] Ralf Handl (SAP SE): b.Issues for V4.01_CSD02
[17:21] Michael Pizzo: Gerald introduced idea of new transformation for Data Aggregation. Will send out a document that we can describe at a later meeting.
[17:21] Ralf Handl (SAP SE): ODATA-1076 If-Match and If-None-Match: align wording with RFC7232
[17:22] Ralf Handl (SAP SE): https://issues.oasis-open.org/browse/ODATA-1076
[17:23] Ralf Handl (SAP SE): ODATA-1076 is OPEN
[17:23] Michael Pizzo: from RFC7232:
There are two entity-tag comparison functions, depending on whether
or not the comparison context allows the use of weak validators:
o Strong comparison: two entity-tags are equivalent if both are not
weak and their opaque-tags match character-by-character.
o Weak comparison: two entity-tags are equivalent if their
opaque-tags match character-by-character, regardless of either or
both being tagged as "weak".
Fielding & Reschke Standards Track [Page 10]
RFC 7232 HTTP/1.1 Conditional Requests June 2014
The example below shows the results for a set of entity-tag pairs and
both the weak and strong comparison function results:
| ETag 1 | ETag 2 | Strong Comparison | Weak Comparison |
| W/"1" | W/"1" | no match | match |
| W/"1" | W/"2" | no match | no match |
| W/"1" | "1" | no match | match |
| "1" | "1" | match | match |
[17:27] Michael Pizzo: From RFC7232:
An origin server MUST use the strong comparison function when
comparing entity-tags for If-Match (Section 2.3.2), since the client
intends this precondition to prevent the method from being applied if
there have been any changes to the representation data.
[17:27] anonymous morphed into George Ericson(Dell)
[17:28] Michael Pizzo: Section 3.2 says use weak for If-None-Match:
A recipient MUST use the weak comparison function when comparing
entity-tags for If-None-Match (Section 2.3.2), since weak entity-tags
can be used for cache validation even if there have been changes to
the representation data.
[17:28] Martin Zurmuehl (SAP SE): from rfc 7232
[17:28] Martin Zurmuehl (SAP SE): An entity-tag can be either a weak or strong validator, with strong
being the default. If an origin server provides an entity-tag for a
representation and the generation of that entity-tag does not satisfy
all of the characteristics of a strong validator (Section 2.1), then
the origin server MUST mark the entity-tag as weak by prefixing its
opaque value with "W/" (case-sensitive).
[17:30] Michael Pizzo: Section 2.1:
2.1. Weak versus Strong
Validators come in two flavors: strong or weak. Weak validators are
easy to generate but are far less useful for comparisons. Strong
validators are ideal for comparisons but can be very difficult (and
occasionally impossible) to generate efficiently. Rather than impose
that all forms of resource adhere to the same strength of validator,
HTTP exposes the type of validator in use and imposes restrictions on
when weak validators can be used as preconditions.
A "strong validator" is representation metadata that changes value
whenever a change occurs to the representation data that would be
observable in the payload body of a 200 (OK) response to GET.
A strong validator might change for reasons other than a change to
the representation data, such as when a semantically significant part
of the representation metadata is changed (e.g., Content-Type), but
it is in the best interests of the origin server to only change the
value when it is necessary to invalidate the stored responses held by
remote caches and authoring tools.
Cache entries might persist for arbitrarily long periods, regardless
of expiration times. Thus, a cache might attempt to validate an
entry using a validator that it obtained in the distant past. A
strong validator is unique across all versions of all representations
associated with a particular resource over time. However, there is
no implication of uniqueness across representations of different
resources (i.e., the same strong validator might be in use for
representations of multiple resources at the same time and does not
imply that those representations are equivalent).
Fielding & Reschke Standards Track [Page 5]
RFC 7232 HTTP/1.1 Conditional Requests June 2014
There are a variety of strong validators used in practice. The best
are based on strict revision control, wherein each change to a
representation always results in a unique node name and revision
identifier being assigned before the representation is made
accessible to GET. A collision-resistant hash function applied to
the representation data is also sufficient if the data is available
prior to the response header fields being sent and the digest does
not need to be recalculated every time a validation request is
received. However, if a resource has distinct representations that
differ only in their metadata, such as might occur with content
negotiation over media types that happen to share the same data
format, then the origin server needs to incorporate additional
information in the validator to distinguish those representations.
In contrast, a "weak validator" is representation metadata that might
not change for every change to the representation data. This
weakness might be due to limitations in how the value is calculated,
such as clock resolution, an inability to ensure uniqueness for all
possible representations of the resource, or a desire of the resource
owner to group representations by some self-determined set of
equivalency rather than unique sequences of data. An origin server
SHOULD change a weak entity-tag whenever it considers prior
representations to be unacceptable as a substitute for the current
representation. In other words, a weak entity-tag ought to change
whenever the origin server wants caches to invalidate old responses.
For example, the representation of a weather report that changes in
content every second, based on dynamic measurements, might be grouped
into sets of equivalent representations (from the origin server's
perspective) with the same weak validator in order to allow cached
representations to be valid for a reasonable period of time (perhaps
adjusted dynamically based on server load or weather quality).
Likewise, a representation's modification time, if defined with only
one-second resolution, might be a weak validator if it is possible
for the representation to be modified twice during a single second
and retrieved between those modifications.
Likewise, a validator is weak if it is shared by two or more
representations of a given resource at the same time, unless those
representations have identical representation data. For example, if
the origin server sends the same validator for a representation with
a gzip content coding applied as it does for a representation with no
content coding, then that validator is weak. However, two
simultaneous representations might share the same strong validator if
they differ only in the representation metadata, such as when two
different media types are available for the same representation data.
Fielding & Reschke Standards Track [Page 6]
RFC 7232 HTTP/1.1 Conditional Requests June 2014
Strong validators are usable for all conditional requests, including
cache validation, partial content ranges, and "lost update"
avoidance. Weak validators are only usable when the client does not
require exact equality with previously obtained representation data,
such as when validating a cache entry or limiting a web traversal to
[17:40] Michael Pizzo: Potential issue: according to strict reading of RFC7232, it appears that returning the same etag when $select, $apply, or $expand is applied (which is what we would want) would imply that the etag was weak.
[17:43] Michael Pizzo: Ralf: because these are specified in the query string it's really a different URL...
[17:43] Ralf Handl (SAP SE): ETags and $expand work different than HTTP ETags in general: each expanded entity has its own ETag in the @odata.etag annotation
[17:50] Ralf Handl (SAP SE): So in a response representing a single entity with expanded entities, each entity could have a @odata.etag, which is the strong ETag, and the overall response in the ETag header could have either a weak ETag computed from the "main" entity, or a strong ETag computed collision-free from all involved @odata.etags
[17:50] Ralf Handl (SAP SE): Similar for collection-valued responses
[17:59] Michael Pizzo: https://tools.ietf.org/html/rfc7232
[17:59] Ralf Handl (SAP SE): Will prepare proposal based on this discussion
[18:00] Ralf Handl (SAP SE): Next agenda item: ODATA-1077 Include atomicityGroup in JSON Batch Response
[18:00] Ralf Handl (SAP SE): https://issues.oasis-open.org/browse/ODATA-1077
[18:04] Ralf Handl (SAP SE): ODATA-1077 is OPEN
[18:05] Mark Biamonte (Progress): I move that OData-1077 be resolved as proposed
[18:05] Michael Pizzo: I second
[18:05] Ralf Handl (SAP SE): ODATA-1077 is RESOLVED as proposed
[18:05] Ralf Handl (SAP SE): a.Document walkthrough
[18:06] Ralf Handl (SAP SE): ii.Part 2: URL Conventions https://www.oasis-open.org/committees/download.php/60367/odata-v4.01-wd02-part2-url-conventions-2017-03-24.docx
1.Continue with section 184.108.40.206, String Functions
[18:06] Ralf Handl (SAP SE): Five minutes break until 18:11
[18:14] Ralf Handl (SAP SE): Mike: [1,1,2] subsetof [1,2]?
[18:15] Ralf Handl (SAP SE): [3,1,4] subsetof [4,3,1]?
[18:16] Michael Pizzo: Does it depend on whether the collection is ordered?
[18:18] Michael Pizzo: I would think that, for ordered or non-ordered, the element of the left operand must occur at least as many times in the right operand.
[18:24] Michael Pizzo: For non-ordered collections, [3,1] subsetof [4,1,3] should be true.
[18:24] Michael Pizzo: Question is for ordered collections: is [3,1] subsetof [4,1,3]
[18:32] Michael Pizzo: Reopened ODATA-1002, assigned to Hubert with the following comment:
[18:32] Michael Pizzo: In reviewing the application, two questions came up:
1) is [1,1,2] subsetof [1,2] ? (do elements of the left operand have to occur at least as many times in the right operand)
2) is [3,1] subsetof [4,1,3]? (does order matter)
For #2, if the collections are unordered, then [3,1] subsetof [4,1,3] should be true, but what about for ordered collections?
[18:38] Ralf Handl (SAP SE)5: 220.127.116.11 Lambda Operators
[18:53] Michael Pizzo: Created new issue ODATA-1078 - What happens if lambda variable name matches a (complex) property name?
[18:53] Ralf Handl (SAP SE)5: ODATA-1078 is OPEN
[18:54] Michael Pizzo: https://issues.oasis-open.org/browse/ODATA-1078
[18:55] Michael Pizzo: Proposal:
1) It is not required
2) In case of conflict, lambda variable name wins (you shouldn't pick a lambda variable name that conflicts...)
[18:56] Michael Pizzo: Also; client can always use $it to "back out of" shadowing...
[18:56] Mark Biamonte (Progress): I move to resolve OData-1078 as proposed
[18:57] Michael Pizzo: I second
[18:57] Ralf Handl (SAP SE)5: ODATA-1078 is RESOLVED as proposed
[19:55] Ralf Handl (SAP SE)5: 6.Next meeting [9:50 am PT]
[19:57] Ralf Handl (SAP SE)5: Mike: skip next meeting, use time to pre-read CSDL documents (both of them)
[19:57] Ralf Handl (SAP SE)5: Mark agrees
[19:59] Ralf Handl (SAP SE)5: a.Thursday May 25, 2017: no meeting
b.Thursday June 01, 2017 during 7-10 am PDT (16:00-19:00 CEST)
c. Thursday June 06, 2017 during 8-11 am PDT (17:00-20:00 CEST)
[19:59] Ralf Handl (SAP SE)5: c: June 08, not 06
[19:59] Ralf Handl (SAP SE)5: Mark on vacation on June 08
[19:59] Ralf Handl (SAP SE)5: 7.AOB and wrap up [9:55 am PT]
[20:00] Ralf Handl (SAP SE)5: Meeting is adjourned
Here  is a draft agenda for the OData TC (Technical Committee) meeting scheduled on Thursday May 18, 2017 during 8-11 am PDT (17:00-20:00 CEST). For additional information, such as dial-in details and chat room, refer to . For TC timeline, see . Feel free to suggest additions or modifications.
1. Roll call [8:00 am PT]
a. Self-registration link: https://www.oasis-open.org/apps/org/workgroup/odata/event.php?event_id=43978
2. Approve agenda [8:05 am PT]
3. Approve minutes from previous meeting(s) [8:10 am PT]
a. Minutes from May 11, 2017 TC meeting: https://www.oasis-open.org/committees/download.php/60691/odata-meeting-173_on-20170504-minutes.html
4. Review action items [Action item list: https://www.oasis-open.org/apps/org/workgroup/odata/members/action_items.php] [8:15am PT]
a. Action items due
5. V4.01 [8:20 am PT]
a. Document walkthrough
ii. Part 2: URL Conventions – https://www.oasis-open.org/committees/download.php/60367/odata-v4.01-wd02-part2-url-conventions-2017-03-24.docx
1. Continue with section 18.104.22.168, String Functions
iv. CSDL JSON Representation – https://www.oasis-open.org/committees/download.php/60500/odata-csdl-json-v4.01-wd01-2017-04-10.docx
v. CSDL XML Representation – https://www.oasis-open.org/committees/download.php/60499/odata-csdl-xml-v4.01-wd02-2017-04-10.docx
vi. New in OData 4.01 – https://www.oasis-open.org/committees/download.php/60439/new-in-odata-v4.01-wd01-2017-04-05.docx
i. ODATA-1005 Make sure we have capabilities for all new 4.01 functionality
ii. ODATA-1070 Clarify text related to Canonical URL
iii. ODATA-1071 Nullable Collection Navigation Property
6. Next meeting [9:50 am PT]
a. Thursday May 25, 2017 during 8-10 am PDT (Public Holiday in Netherlands and Germany)
b. Thursday June 01, 2017 during 7-10 am PDT (16:00-19:00 CEST)
7. AOB and wrap up [9:55 am PT]
· Conference call details: https://www.oasis-open.org/apps/org/workgroup/odata/download.php/56760/TC%20meeting%20dial-in%20details.htm
· Chat room: http://webconf.soaphub.org/conf/room/odatatc