OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [odata] Agenda for OData TC meeting on 2017-03-16 - chat transcript


[15:53] Stefan Hagen: RegInfo{Voting Members: 1 of 10 (10%) (used for quorum calculation)}
[15:59] Stefan Hagen: RegInfo{Voting Members: 2 of 10 (20%) (used for quorum calculation)}

 

[16:02] Ralf Handl (SAP SE): Voting Members: 5 of 10 (50%) (used for quorum calculation)
[16:03] Ralf Handl (SAP SE): Voting Members: 6 of 10 (60%) (used for quorum calculation)
[16:04] Ralf Handl (SAP SE): Achieved quorum: yes
[16:04] Ralf Handl (SAP SE): Let's still wait another minute or two
[16:08] Ralf Handl (SAP SE): Voting Members: 8 of 10 (80%) (used for quorum calculation)
[16:08] Ralf Handl (SAP SE): 2.Approve agenda [8:05 am PT]
[16:09] Ralf Handl (SAP SE): 3.Approve minutes from previous meeting(s) [8:10 am PT]
a.Minutes from March 09, 2017 TC meeting: https://www.oasis-open.org/committees/download.php/60230/odata-meeting-165_on-20170309-minutes.html
[16:10] Ralf Handl (SAP SE): Minutes are approved
[16:10] 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
i.None
[16:10] Ralf Handl (SAP SE): 5.V4.01 [9:20 am PT]
a.Issues for V4.01_CSD02 ready for resolution
[16:10] Ralf Handl (SAP SE): i.ODATA-760 Add to depth restrictions to Capabilities Vocabulary
[16:12] Ralf Handl (SAP SE): Add MaxLevels property to FilterRestrictionsType, ExpandRestrictionsType, InsertRestrictionsType, UpdateRestrictionsType and DeleteRestrictionsType

 

[16:12] Mike Pizzo: I move we approve ODATA-760 as proposed

 

[16:14] Martin Zurmuehl (SAP SE): I second

 

[16:14] Ralf Handl (SAP SE): ODATA-760 is RESOLVED as proposed
[16:14] Ralf Handl (SAP SE): ii.ODATA-950 Clarify what requests can be delta enabled
[16:14] Ralf Handl (SAP SE): Proposal:
Any GET request to retrieve one or more entities can be delta enabled by the service. 
 
Reasoning: 
 
- The entity set scenario is already well documented so nothing new there. 
 
- The reason for the single entity case is mainly for singletons. If a service has a singleton, a natural defining query would be for the singleton entity possibly with expands. You could make the same argument for just single entities that are not singletons. The main reason I see for allowing a single entity (singleton or otherwise) without any nested entities to be delta enabled is in the case where the entity is very large (i.e. lots of large properties). In that case, the delta protocol could be used to return only the properties that have changed. 
 
- A function can return a collection of entities so it should be able to return a delta link.
[16:18] Ralf Handl (SAP SE): Hubert: make clear that this is not the exclusive, complete list of requests that can be delta-enabled
[16:20] Ralf Handl (SAP SE): Adapt "AppliesTo" to include Singleton
[16:20] Ralf Handl (SAP SE): for term Capabilities.ChangeTracking
[16:20] Ralf Handl (SAP SE): Also add NavigationProperty

 

[16:25] Matt Borges (SAP): Clarify that any GET request to retrieve one or more entities MAY be delta enabled by the service.  A service MAY support delta enabling additional GET requests.
Add Singleton and navigation property to the AppliesTo of the ChangingTracking term.
[16:26] Matt Borges (SAP): Clarify that any GET request to retrieve one or more entities MAY be delta enabled by the service.  A service MAY support delta enabling additional GET requests.
Add Singleton, Navigation Property, and Funtion to the AppliesTo of the ChangingTracking term.
[16:28] Matt Borges (SAP): I move to resolve ODATA-950 as proposed

 

[16:29] Mike Pizzo: I second

 

[16:29] Ralf Handl (SAP SE): ODATA-950 is RESOLVED as proposed
[16:29] Ralf Handl (SAP SE): iii.ODATA-1005 Make sure we have capabilities for all new 4.01 functionality
[16:29] Ralf Handl (SAP SE): Do this in conjunction with conformance, so clients have a way to determine which optional parts of 4.01 are supported by a service. 
 
things to consider: 
- PATCH/DELETE with filter 
- POST/PATCH/DELETE with type cast segment 
- PATCH using delta response format 
- nested collections in delta payload (as delta or replacement) 
- Deep insert/update operations 
- eq/ne null comparisons for nav properties w/max cardinality of 1 (should this be must?) 
- implicit aliasing of parameters 
- in operator, divby, 
- negative indexes for substring 
- key-as-segment (Core vocab, applies to EntityContainer, similar to ConventionalIDs and DereferenceableIDs) 
- use of count of filtered/searchced collection in a common _expression_ 
- equal/non-equal structural comparison 
- PUT/DELETE to $ref of a collection-valued nav prop 
- POST to collections of complex/primitive types 
- $search for all collections 
- headers and query options without prefix, case-insensitive query options 
- $compute 
- indexing into ordered collections and positional insert with $index 
- batch referencing features, JSON batch format 
- use of instance annotations in query options 
- $expand for stream properties and media resources
[16:34] Ralf Handl (SAP SE): Mike will group by topics and prepare term proposals
[16:34] Ralf Handl (SAP SE): iv.ODATA-1018 Allow $expand and $select with modifying requests that return a collection in combination with return=representation to specify the response shape
1.Revisit:       ODATA-615 Allow PATCH and DELETE with $filter on collections to modify or delete all (and only) the matching entities
2.Consider:    ODATA-836 Allow applying actions to a filtered collection of entities
[16:35] Ralf Handl (SAP SE): Skip for now
[16:35] Ralf Handl (SAP SE): v.ODATA-1021 Are additional values needed for the reason property of a removed Annotation
[16:35] Ralf Handl (SAP SE): Proposal:
Close without fixing. 
 
Reasoning: 
 
- Additional values are unnecessary from the point of view of a client applying a delta response because the net result in both cases is the same. 
 
- Having a different value for the reason for a delta response and a delta upload request is an unnecessary complication that doesnt add value and prevents easily passing the a delta response as a delta upload request. 
 
- "change" is a very generic term that we did discuss changing to something more meaningful. However, we were unable to come up with something better. Further, changing this value could break backwards compatibility between 4.0 and 4.01 so it's best to leave it as is.
[16:38] Ralf Handl (SAP SE): ODATA-1021 is OPEN

 

[16:38] Matt Borges (SAP): I move close ODATA-1021 without fixing it

 

[16:39] Mike Pizzo: I second

 

[16:39] Ralf Handl (SAP SE): ODATA-1021 is resolved as WON'T FIX
[16:40] Ralf Handl (SAP SE): vi.ODATA-1033 Interoperability issue when using escaped slash/backslash in URLs
[16:43] Ralf Handl (SAP SE): ODATA-1033 is OPEN
[16:43] Ralf Handl (SAP SE): Add an implicit cast rule that allows binary values in place of string values, where the base64url-encoded binary is the UTF-8 representation of the string value: 
 
GET Categories(binary'Q29tZWR5L011c2ljYWw=')
[16:49] Ralf Handl (SAP SE): Mike: do we require 4.01 services to implement this?
[16:49] Ralf Handl (SAP SE): Mike: do we recommend for generic 4.01 clients to use this?
[16:51] Ralf Handl (SAP SE): %00, %2F
[16:52] Ralf Handl (SAP SE): %5C

 

[16:52] Mike Pizzo: Services are required to support an implicit cast from binary to string (anywhere). Clients are advised to use this form when passing a string value containing a forwardslash, backslash, and a null character (%00, %2F, %5C)

 

[16:54] Ralf Handl (SAP SE): I move to resolve ODATA-1033 with the amended proposal

 

[16:54] Martin Zurmuehl (SAP SE): I second

 

[16:54] Ralf Handl (SAP SE): ODATA-1033 is RESOLVED as proposed
[16:54] Ralf Handl (SAP SE): vii.ODATA-1043 Clean up context URL syntax
[16:55] Ralf Handl (SAP SE): Proposal: 
State in chapter 10 that one purpose of the context URL is to make responses "self-contained" and allow the client to e.g. construct navigation links for selected navigation properties. 
 
Otherwise no action, and no relaxation of the context URL patterns.
[16:56] Ralf Handl (SAP SE): I move to resolve ODATA-1043 as proposed

 

[16:56] Mike Pizzo: I second.

 

[16:57] Ralf Handl (SAP SE): ODATA-1043 is RESOLVED as proposed
[16:57] Ralf Handl (SAP SE): Renamed issue to "Clarify purpose of Context URL"
[16:57] Ralf Handl (SAP SE): viii.ODATA-1047 Rename $IsCollection to $Collection
[16:59] Ralf Handl (SAP SE): ODATA-1047 is OPEN
[17:00] Ralf Handl (SAP SE): Mike: doesn't hurt if we don't resolve ODATA-879
[17:03] Ralf Handl (SAP SE): Mike: make changing the type of $Collection to a number part of ODATA-879
[17:03] Ralf Handl (SAP SE): I move to resolve ODATA-1047 as proposed

 

[17:03] Martin Zurmuehl (SAP SE): I second

 

[17:04] Ralf Handl (SAP SE): ODATA-1047 is RESOLVED as proposed
[17:04] Ralf Handl (SAP SE): ix.ODATA-1048 Move server-driven paging to advanced conformance level
[17:05] Ralf Handl (SAP SE): Mike: clarify that services don't have to implement it, but MUST NOT use any other means for indicating partial results

 

[17:07] Mike Pizzo: updated proposal: Clarify: if a service returns a partial result it MUST include a nextlink.

 

[17:08] Ralf Handl (SAP SE): I move to resolve ODATA-1048 with the modified proposal

 

[17:08] Martin Zurmuehl (SAP SE): I second

 

[17:09] Ralf Handl (SAP SE): No objections to opening this issue retroactively
[17:09] Ralf Handl (SAP SE): No objections to the motion
[17:09] Ralf Handl (SAP SE): ODATA-1048 is RESOLVED as proposed
[17:09] Ralf Handl (SAP SE): x.ODATA-1049 Content referencing in batch requests
[17:09] Ralf Handl (SAP SE): Proposal:
 
Allow referencing values from response bodies in subsequent requests 
- in $filter 
- in request bodies of subsequent modification requests 
 
Value references use JSON Pointer syntax to address parts of the response body, e,g. 
 
$filter=City eq $42/Addresses/3/City
[17:11] Ralf Handl (SAP SE): ODATA-1049 is OPEN
[17:11] Ralf Handl (SAP SE): Mike likes it
[17:11] Ralf Handl (SAP SE): Hubert likes it
[17:12] Ralf Handl (SAP SE): Point out that content-id value must not collide with $root or any other $ literal valid in expressions
[17:14] Ralf Handl (SAP SE): I move ODATA-1049 as proposed with the clarification on $root etc.

 

[17:15] Mike Pizzo: I second

 

[17:15] Ralf Handl (SAP SE): ODATA-1049 is RESOLVED
[17:15] Ralf Handl (SAP SE): xi.ODATA-1050 Change sets: do not require the same content type for all request in a change set
[17:16] Ralf Handl (SAP SE): ODATA-1050 is OPEN
[17:16] Ralf Handl (SAP SE): I move to resolve ODATA-1050 as proposed

 

[17:17] Martin Zurmuehl (SAP SE): I second

 

[17:17] Ralf Handl (SAP SE): ODATA-1050 is RESOLVED as proposed
[17:17] Ralf Handl (SAP SE): x.ODATA-1049 Content referencing in batch requests
[17:17] Ralf Handl (SAP SE): xii.ODATA-1051 Further simplify JSON Batch Format
[17:18] Ralf Handl (SAP SE): Example batch request: 
 
POST /v1.0/$batch HTTP/1.1 
{ 
  requests: [ 
    { 
      id: "1", 
      atomicityGroup: "atom1", 
      method: "post", 
      url: "/users", 
      headers: { 
        "Content-Type": "application/json" 
      }, 
      body: { 
        displayName: "John Smith", 
        userPrincipalName: "jsmith@contoso.com" 
      } 
    }, 
    { 
      id: "2", 
      atomicityGroup: "atom1", 
      dependsOn: ["1"], 
      method: "put", 
      url: "$1/photo", 
      headers: { 
        Content-Type: "image/jpeg" 
      }, 
      body: "FRwvAAIAAAANAA4AFAAhAPNTUAAAAAAAAAAAAAAQUAAAAAAADHrQX+" 
    }, 
    { 
      id: "3", 
      method: "get", 
      url: "/groups?top=10", 
      headers: { 
        Accept: "application/atom+xml", 
      } 
    }, 
    { 
      id: "4", 
      dependsOn: ["atom1"], 
      method: "get", 
      url: "$1/thumbnail", 
      headers: { 
        Accept: "image/jpeg" 
      } 
    } 
  ] 
}
[17:22] Ralf Handl (SAP SE): Response example:
 
{ 
  responses: [ 
    { 
      id: "1", 
      status: 201, 
      headers: { 
        Location: "/users/jsmith" 
      } 
    }, 
    { 
      id: "2", 
      status: 204 
    }, 
    { 
      id: "3", 
      status: 406, 
      error: { 
        message: "Atom Format not supported" 
    }, 
    { 
      id: "4", 
      status: 200, 
      headers: { 
        Content-Type: "image/jpeg" 
      }, 
      body: "FRwvAAIAAAANAA4AFAAhAPNTUAAAAAAAAAAAAAAQUAAAAAAADHrQX+" 
    }, 
  } 
}
[17:26] Ralf Handl (SAP SE): Async processing: don't use a last array item with a 202 status, instead use a next-link
[17:27] Ralf Handl (SAP SE): Next-link can also be used for synchronous batch requests to chunk it up
[17:28] Ralf Handl (SAP SE): For async case a GET request to the next-link MAY result in 202 and the location of a monitor resource
[17:29] Ralf Handl (SAP SE): Can now have also respond-async in individual requests, the 202 response is just another item in the "responses" array
[17:31] Ralf Handl (SAP SE): Mike: could add a @retryAfter annotation to avoid 202 responses: just respond with empty "responses" array, next-link, and retryAfter annotation
[17:33] Ralf Handl (SAP SE): ODATA-1051 is OPEN

 

[17:33] Mike Pizzo: Proposal: Remove the outer object wrapper in the proposed JSON batch format.  Add an "atomicityGroup" property; all requests that have the same value for atomicityGroup are processed as an atomic unit.  Members with the same atomicityGroup must be adjacent in a request payload. dependsOn can reference an individual request that is not within an atomicityGroup, or the identifier for the atomicityGroup if the request is within an atomicityGroup.
 
Support server-driven paging in this format.
 
For an async batch response, the nextLink can return 202 with a location header and retry after.

 

[17:35] Ralf Handl (SAP SE): Rationale for "atomicity group" versus "change set": atomicity groups have different semantics
[17:36] Ralf Handl (SAP SE): - not restricted to changes
[17:36] Ralf Handl (SAP SE): - no "unordering" but may use dependsOn for ordering constraints

 

[17:38] Mike Pizzo: I move we resolve ODATA-1051 as proposed.

 

[17:38] Martin Zurmuehl (SAP SE): I second!

 

[17:38] Ralf Handl (SAP SE): ODATA-1051 is RESOLVED as proposed
[17:39] Ralf Handl (SAP SE): v.ODATA-994 consider replacing SchemaVersion header with $SchemaVersion query option, or root URL versioning
[17:39] Ralf Handl (SAP SE): Proposal:
If the only difference between two request is the SchemaVersion Header value, the response is not cachable in all today-browser-implementations (the 'vary' header is not treated correct). 
--> To enable caching of responses we need differentiating URL's. We should use a $SchemaVersion query option. It is superior to adding a segment to the root url, because clients are anyhow familiar with adding query options. 
The usage of a $SchemaVersion query option in the relative contextURLs is save; according to rfc3986 query options on the base URI are not kept during reference resolution for all relevant cases. 
Depending on the value of the SchemaVersion it may be necessary to percent-encode it before the URI is formed.
[17:43] Ralf Handl (SAP SE): Mike: query options are tricky when composing URLs
[17:51] Ralf Handl (SAP SE): Mike: in favor of replacing SchemaVersion header with $schemaversion query option (any casing, optional $ prefix)
[17:52] Ralf Handl (SAP SE): Hubert: might need to restrict the character set for schema versions

 

[17:52] Mike Pizzo: Remove SchemaVersion header in place of a $SchemaVersion query option.
Limit characters in SchemaVersion to things that don't have to be percent encoded.

 

[17:53] Ralf Handl (SAP SE): Character set: unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"

 

[17:55] Martin Zurmuehl (SAP SE): I move we resolve ODATA-994 as proposed in the chat.

 

[17:55] Ramesh Reddy (Red Hat): I second

 

[17:56] Ralf Handl (SAP SE): ODATA-994 is RESOLVED with the amended proposal
[17:58] Ralf Handl (SAP SE): Last chance to make proposals for the last seven issues in the "leftover" category
[17:59] Ralf Handl (SAP SE): 6.Next meeting [9:50 am PT]
a.Thursday March 23, 2017 during 8-10 am PDT  16:00-18:00 CET  already approved
b.Thursday March 30, 2017 during 8-10 am PDT  17:00-19:00 CEST?
[18:00] Ralf Handl (SAP SE): Hubert can at most make the first half of the next meeting
[18:01] Ralf Handl (SAP SE): b. seems to work for most
[18:01] Ralf Handl (SAP SE): 7.AOB and wrap up [9:55 am PT]
[18:01] Ralf Handl (SAP SE): Stefan: working now as editor of CSAF TC
[18:01] Ralf Handl (SAP SE): Might lead to delays for minutes
[18:02] Ralf Handl (SAP SE): Stefan: also involved with CTI TC
[18:05] Ralf Handl (SAP SE): Meeting is adjourned

 

 

From: odata@lists.oasis-open.org [mailto:odata@lists.oasis-open.org] On Behalf Of Handl, Ralf
Sent: Mittwoch, 15. März 2017 09:04
To: odata@lists.oasis-open.org
Subject: [odata] Agenda for OData TC meeting on 2017-03-16

 

Here [1] is a draft agenda for the OData TC (Technical Committee) meeting scheduled on Thursday March 16, 2017 during 8-10 am PDT (16:00-18:00 CET – one hour earlier than usual for Europeans). For additional information, such as dial-in details and chat room, refer to [2]. For TC timeline, see [3]. Feel free to suggest additions or modifications.

 

Thanks.

 

[1] Agenda

 

1.        Roll call [8:00 am PT]

a.     Self-registration link: https://www.oasis-open.org/apps/org/workgroup/odata/event.php?event_id=43969

 

2.        Approve agenda [8:05 am PT]

 

3.        Approve minutes from previous meeting(s) [8:10 am PT]

a.     Minutes from March 09, 2017 TC meeting: https://www.oasis-open.org/committees/download.php/60230/odata-meeting-165_on-20170309-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

                                  i.    None

 

5.        V4.01 [9:20 am PT]

a.     Issues for V4.01_CSD02 ready for resolution

                                                   i.      ODATA-760 Add to depth restrictions to Capabilities Vocabulary

                                 ii.    ODATA-950 Clarify what requests can be delta enabled

                                iii.    ODATA-1005 Make sure we have capabilities for all new 4.01 functionality

                                iv.    ODATA-1018 Allow $expand and $select with modifying requests that return a collection in combination with return=representation to specify the response shape

1.     Revisit:       ODATA-615 Allow PATCH and DELETE with $filter on collections to modify or delete all (and only) the matching entities

2.     Consider:    ODATA-836 Allow applying actions to a filtered collection of entities

                                 v.    ODATA-1021 Are additional values needed for the reason property of a removed Annotation

                                vi.    ODATA-1033 Interoperability issue when using escaped slash/backslash in URLs

                               vii.    ODATA-1043 Clean up context URL syntax

                              viii.    ODATA-1047 Rename $IsCollection to $Collection

                                ix.    ODATA-1048 Move server-driven paging to advanced conformance level

                                 x.    ODATA-1049 Content referencing in batch requests

                                xi.    ODATA-1050 Change sets: do not require the same content type for all request in a change set

                               xii.    ODATA-1051 Further simplify JSON Batch Format

b.    Issues for V4.01_CSD02 in New or Open state without concrete proposal

                                                   i.      ODATA-868 Describe HTTP encoding for streamed requests and responses

                                 ii.    ODATA-879 Support Arrays of Arrays

                                iii.    ODATA-919 Specify the result type for each operation based on operator types

                                iv.    ODATA-923 $expand (or $include) for $metadata to include referenced schemas

                                 v.    ODATA-994 consider replacing SchemaVersion header with $SchemaVersion query option, or root URL versioning

                                vi.    ODATA-1002 Add build in functions operating on collections of primitive (and complex?) types

                               vii.    ODATA-1003 Allow casting of entities and complex type instances to arbitrary structural type

                              viii.    ODATA-1020 Remove / in reference in instance annotation in filter and orderby _expression_

                                ix.    ODATA-1034 Support the notion of a collection of name/value pairs where the type of the value is known

 

6.        Next meeting [9:50 am PT]

a.     Thursday March 23, 2017 during 8-10 am PDT – 16:00-18:00 CET – already approved

b.     Thursday March 30, 2017 during 8-10 am PDT – 17:00-19:00 CEST?

 

7.        AOB and wrap up [9:55 am PT]

 

[2] References

·         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

 

[3] Timeline

·         https://www.oasis-open.org/committees/download.php/59862/TC%20Timeline-2017-01-25.docx

 

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]