OData TC meeting #175 Thursday May 18, 2017

Acting chair: Mike

Chat transcript from room: odatatc
2017-05-18 0800-1100 PDT

1. Roll call

1.1 Members present

    George Ericson (Dell)
    Gerald Krause (SAP SE)
    Mark Biamonte (Progress Software)
    Martin Zurmuehl (SAP SE)
    Matthew Borges (SAP SE) a.k.a. Matt
    Michael Pizzo (IBM) a.k.a. Mike
    Ralf Handl (SAP SE)
    Stefan Hagen (Individual)

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

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

2. Approve agenda

Ralf: Gerald to share news on the Data Aggregation spec

Mike: new issue

Ralf: ODATA-1077 - Include atomicityGroup in JSON Batch Response

Ralf: ODATA-1076 - If-Match and If-None-Match: align wording with RFC7232

Mike: start with these two issues before document walkthrough

Ralf: Geralds topic after #3

Agenda is approved with these additions.

3. Approve minutes from previous meeting(s)

3.1 Minutes from May 11, 2017 TC meeting #174

https://www.oasis-open.org/apps/org/workgroup/odata/download.php/60730/odata-meeting-174_on-20170511-minutes.html

Minutes approved unchanged as published.

4. New agenda item: Gerald on Data Aggregation

Mike: Gerald introduced idea of new transformation for Data Aggregation. Will send out a document that we can describe at a later meeting.

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

5.1 Action items due

None

6. V4.01

6.1 Issues for V4.01_CSD02

6.1.1 ODATA-1076 - If-Match and If-None-Match: align wording with RFC7232

Ralf: ODATA-1076 is OPEN

Mike: from RFC7232:

2.3.2.  Comparison

   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           |
   +--------+--------+-------------------+-----------------+

Mike: 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.

Mike: 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.

Martin: From RFC7232:

   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).

Mike: 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
   recent changes.

Mike: 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.

Ralf:

Because these are specified in the query string it's really a different URL...
ETags and $expand work different than HTTP ETags in general: 
 each expanded entity has its own ETag in the @odata.etag annotation
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
Similar for collection-valued responses

Mike: https://tools.ietf.org/html/rfc7232

Ralf: Will prepare proposal based on this discussion

6.1.2 ODATA-1077 - Include atomicityGroup in JSON Batch Response

Ralf: ODATA-1077 is OPEN

Mark: I move that OData-1077 be resolved as proposed. Mike seconds.

Ralf: ODATA-1077 is RESOLVED as proposed

6.1.3 ODATA-1078 - What happens if lambda variable name matches a (complex) property name?

Ralf: ODATA-1078 is OPEN

Mike: 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...)

Mike: Also; client can always use $it to "back out of" shadowing...

Mark: I move to resolve OData-1078 as proposed. Mike seconds.

Ralf: ODATA-1078 is RESOLVED as proposed

6.2 Document walkthrough

6.2.1 Part 1: Protocol

URL = https://www.oasis-open.org/committees/download.php/60437/odata-v4.01-wd02-part1-protocol-2017-04-05.docx

Finished already.

6.2.2 Part 2: URL Conventions

URL = https://www.oasis-open.org/committees/download.php/60438/odata-v4.01-wd02-part2-url-conventions-2017-04-05.docx

All walk through the document, discuss and perform online changes during the meeting.

Ralf: Continue with section 5.1.1.5, String Functions

Mike: [1,1,2] subsetof [1,2]?

Ralf: [3,1,4] subsetof [4,3,1]?

Mike:

Does it depend on whether the collection is ordered?
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.
For non-ordered collections, [3,1] subsetof [4,1,3] should be true.
Question is for ordered collections: is [3,1] subsetof [4,1,3]

Mike: Reopened ODATA-1002, assigned to Hubert with the following comment:
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?

Ralf: 5.1.1.10 Lambda Operators

Mike: Created new issue ODATA-1078 - What happens if lambda variable name matches a (complex) property name?

Cf. section 6.1.3 above in issue section for processing.

Completed

6.2.3 JSON Format

URL = https://www.oasis-open.org/committees/download.php/60365/odata-json-format-v4.01-wd02-2017-03-24.docx

Completed

6.2.4 CSDL JSON Representation

URL = https://www.oasis-open.org/committees/download.php/60500/odata-csdl-json-v4.01-wd01-2017-04-10.docx

Skipped

6.2.5 CSDL XML Representation

URL = https://www.oasis-open.org/committees/download.php/60499/odata-csdl-xml-v4.01-wd02-2017-04-10.docx

Skipped - Note: Planned to start with this next meeting!

6.2.6 New in OData 4.01

URL = https://www.oasis-open.org/committees/download.php/60439/new-in-odata-v4.01-wd01-2017-04-05.docx

Skipped

7. Next meetings

Mike: skip next meeting [which was scheduled for May 25, 2017] and use time to pre-read CSDL documents (both of them)

Mark: Agrees.

7.1 Next Meeting on Thursday June 01, 2017 during 7-10 am PDT (16:00-19:00 CEST)

All will prepare to start walking through the CSDL XML Representation in that meeting.

7.2 Meeting after that on Thursday June 08, 2017 during 8-11 am PDT (17:00-20:00 CEST)

Mark: On vacation.

8. AOB and wrap up

None

Meeting adjourned by chair.