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 2016-11-03 - chat transcript


[12:25] Room information was updated by: Stefan Hagen
Register: https://www.oasis-open.org/apps/org/workgroup/odata/event.php?event_id=41487  (please do so as usual, thanks).
Agenda draft: https://www.oasis-open.org/apps/org/workgroup/odata/email/archives/201611/msg00016.html
Minutes draft of previous meeting: https://www.oasis-open.org/committees/download.php/59261/odata-meeting-150_on-20161027-minutes.html
Room Information:
Register: https://www.oasis-open.org/apps/org/workgroup/odata/event.php?event_id=41487  (please do so as usual, thanks).
Agenda draft: https://www.oasis-open.org/apps/org/workgroup/odata/email/archives/201611/msg00016.html
Minutes draft of previous meeting: https://www.oasis-open.org/committees/download.php/59261/odata-meeting-150_on-20161027-minutes.html

 

[15:06] Ralf Handl (SAP SE): Voting Members: 7 of 12 (50%) (used for quorum calculation) - including Matt who was accidentally still tagged as non-voting member
[15:07] Ralf Handl (SAP SE): Quorum achieved: yes
[15:07] Ralf Handl (SAP SE): 2.Approve agenda [7:05 am PT]
[15:07] Ralf Handl (SAP SE): Addition to 5.a.i:
10.          ODATA-993 - 14.2: Explicitly allow annotations on deleted entities

 

[15:07] anonymous morphed into Hubert Heijkers1

 

[15:09] Ralf Handl (SAP SE): 3.Approve minutes from previous meeting(s) [7:10 am PT]
a.Minutes from October 27, 2016 TC meeting: https://www.oasis-open.org/apps/org/workgroup/odata/download.php/59261/latest/odata-meeting-150_on-20161027-minutes.html
[15:09] Ralf Handl (SAP SE): Minutes are approved
[15:09] Ralf Handl (SAP SE): 4.Review action items [Action item list: https://www.oasis-open.org/apps/org/workgroup/odata/members/action_items.php] [7:15am PT]
a.Action items due
i.#0036 Register the OData- headers and preferences with IANA
[15:10] Ralf Handl (SAP SE): Shift until Mark Biamonte joins the call
[15:10] Ralf Handl (SAP SE): 5.V4.01 [7:20 am PT]
a.Issues for V4.01_WD01 in New or Open state
i.Waiting for refined proposal
[15:10] Ralf Handl (SAP SE): 10.          ODATA-993 - 14.2: Explicitly allow annotations on deleted entities
[15:11] Ralf Handl (SAP SE): The delta format identifies deleted entities via their entity id. 
 
For legacy systems that don't store the entity id and only know the underlying key values it would be helpful if the sender would annotate the deleted entity JSON objects with the original key values, e.g. 
 
    { 
      "@odata.context":"#Customers/$deletedEntity", 
      "id":"Customers('ANTON')", 
      "@Legacy.entityKey":{ 
        "ID":"ANTON" 
      }, 
      "reason":"deleted" 
    }
[15:17] Ralf Handl (SAP SE): Mike: also allow for added links and deleted links.
[15:17] Ralf Handl (SAP SE): Mike: can see scenarios where entity references might need annotations
[15:18] Ralf Handl (SAP SE): ODATA-993 is OPEN
[15:23] Ralf Handl (SAP SE): Current text:
Annotations can be applied to any name/value pair in a JSON payload that represents a value of any type from the entity data model (see [OData-CSDL]).
[15:23] Ralf Handl (SAP SE): New text:
Annotations can be applied to any name/value pair in a JSON payload.

 

[15:25] Mike Pizzo: Updated proposal: 
Support annotations in the following:
-AddedLinks
-DeletedLinks
-Deleted Entries
-References
 
In JSON, clients should be prepared for annotations in any object and any name/value pair in a json payload. Clients should never error on an annotation.
[15:26] Mike Pizzo: I move we resolve ODATA-993 as proposed

 

[15:26] Hubert Heijkers1: I second

 

[15:27] Ralf Handl (SAP SE): ODATA-993 is RESOLVED with the modified proposal
[15:32] Ralf Handl (SAP SE): 4.ODATA-920 Specify overflow for int data types (-INF, INF, NaN)

 

[15:34] Mike Pizzo: Proposal 1:
[15:34] Mike Pizzo: "numbers" : [ 
1, 
2, 
{"@odata.numericOverflow":"-INF"}, 
4 
]
[15:36] Mike Pizzo: "numbers" : [ 
     1, 
     2, 
     {
        "@mycomment":"MyFavoriteNumber",
        Value: 3
      }, 
     4 
]

 

[15:38] Ralf Handl (SAP SE): Mike: concern that annotating something now changes the structure of the JSON document
[15:39] Ralf Handl (SAP SE): Mike: also different from hand-crafted JSON

 

[15:42] Mike Pizzo: <Term Name="annotations" Type="Collection(Edm.Untyped)"/> 
 
{ 
"myArray":[1,2,null,4,5], 
"myArray@annotations":[null,null,{"@numericValueException":"NaN"},null,null} 
}

 

[15:44] Ralf Handl (SAP SE): JSON Pointer style
 
{ 
"myArray":[1,2,null,4,5], 
"myArray/2@numericValueException":"NaN" 
}
[15:47] Ralf Handl (SAP SE): { 
"myArray":[1,2,null,4,5], 
"myArray@annotations":{2:{"@numericValueException":"NaN"}} 
}
[15:50] Ralf Handl (SAP SE): JSON Schema:
"type":["number","null"]
[15:51] Ralf Handl (SAP SE): "type":["number","string","null"]
[15:52] Ralf Handl (SAP SE): "anyOf":[{"type":["number","null"]},{"type":"object"}]

 

[16:04] Mike Pizzo: 18.2:
[16:04] Mike Pizzo: When annotating a name/value pair for which the value is represented as a JSON array or primitive value, each annotation that applies to this name/value pair MUST be placed next to the annotated name/value pair and represented as a single name/value pair.

 

[16:15] Ralf Handl (SAP SE): Mark: differentiate between streaming and non-streaming, use in-line objects for streaming, separate array/map for non-streaming

 

[16:23] Mike Pizzo: Annotating an array of arrays through expando-values:
[16:23] Mike Pizzo: "cells": [ 
[ 
{"foo":1,"bar":1}, 
{"foo":2,"bar":2} 
], 
{ 
"value": [ 
{"foo":3,"bar":3}, 
{"foo":4,"bar":4} 
], 
"@my.annotation":"myannotationvalue" 
} 
]

 

[16:34] Ralf Handl (SAP SE): Tentative consensus for placing annotations next to array values instead of injecting wrapper objects
[16:35] Ralf Handl (SAP SE): Mike: separately decide whether to keep @numericValueException or move back to -INF, INF, and NaN string values
[16:38] Ralf Handl (SAP SE): MyArray@odata.count: 3
MyArray/0@odata.count:2
[16:38] Ralf Handl (SAP SE): MyArray/0/0@odata.count:42

 

[16:40] Hubert Heijkers1: MyArray@odata.count:2
[16:40] Hubert Heijkers1: MyArray/0@odata.count:42
[16:41] Hubert Heijkers1: MyArray/1@odata.count:13

 

[16:41] Ralf Handl (SAP SE): MyArray[]@odata.count:[42,13]

 

[16:44] Mike Pizzo: "number":[1,2,3,null],
[16:44] Mike Pizzo: "number@annotated":[1,2,{"@myfavoritenumber":3},{"@numericValueException":"INF"}]
[16:47] Mike Pizzo: "number@":[1,2,{"@comment":"myfavoritenumber","Value":3},{"@numericValueException":"INF"}]

 

[16:50] Ralf Handl (SAP SE): Hubert: add odata preference for only serializing number@

 

[16:50] Mike Pizzo: $select=number@
[16:50] Mike Pizzo: $select=*@

 

[16:51] Ralf Handl (SAP SE): $select=number@Common.FieldControl

 

[16:52] Mike Pizzo: preference="annotated-values"
[16:54] Mike Pizzo: "number@":{"@myannotation":"myfavoritevalue","Value":3}?
[16:57] Mike Pizzo: if preference="annotationobjects", then always and only return annotated primitive values as objects (without the trailing "@")
[16:58] Mike Pizzo: (and arrays)

 

[17:01] Ralf Handl (SAP SE): Current:
NavProp:[...]
NavProp@odata.count:41
[17:01] Ralf Handl (SAP SE): Future:
NavProp:{@odata.count:41,value:[...]}

 

[17:02] Hubert Heijkers1: "number@":{"odata.count":4, "Value":[1,2,{"@comment":"myfavoritenumber","Value":3},{"@numericValueException":"INF"}]}

 

[17:04] Mike Pizzo: Working idea:
{
    "number": 3
    "number@ns.comment":"myfavoritenumber",
    "numbers":[1,2,3,null],
    "numbers@":[1,2,{"@ns.comment":"myfavoritenumber","Value":3},{"@numericValueException":"INF"}]
}
 
With a new preference services could always and only return annotated primitive values as objects (without the trailing "@"):
{
    "number": {"@ns.comment":"myfavoritenumber","Value":3],
    "numbers":[1,2,{"@ns.comment":"myfavoritenumber","Value":3},{"@numericValueException":"INF"}]
}

 

[17:07] Ralf Handl (SAP SE): 5 minutes break
[17:11] Ralf Handl (SAP SE): End of break
[17:14] Ralf Handl (SAP SE): 5.ODATA-964 Need to clarify nested delta representation

 

[17:21] Mike Pizzo: Partial Example: 
{ 
"@odata.type":"#Northwind.Manager", 
"FirstName" : "Patricia", 
"DirectReports@odata.contextUrl" : "#Employees(1)/DirectReports/$delta", 
"DirectReports": [ 
{ 
"@odata.context":"#Employees/$deletedEntity", 
"id":"Employees(3)", 
"reason":"deleted" 
},
[17:23] Mike Pizzo: Would context for deleted entity be: "#Employees/$deletedEntity" or "#Employees(1)/DirectReports/$deletedEntity"
[17:29] Mike Pizzo: could shorten to "/$delta" and "/$deletedEntity"

 

[17:29] Ralf Handl (SAP SE): Hubert: simplify context urls to "$delta", "$deleteEntity" for nested context

 

[17:29] Mike Pizzo: actually "#$delta" and "#$deletedEntity"
[17:34] Mike Pizzo: might want to qualify with the set in order to be common with deleted entities outside of the nesting.
[17:42] Mike Pizzo: Proposal:
Added/Deleted links only appear at the root.
 
Nested content with "#delta" is applied as a delta. Entities are upserted, deleted entities are removed from the collection. If reason:deleted is specified, client knows the related entity is deleted, otherwise (in a non-containment case) all the client knows is that the entity is no longer a member of that collection.  The contextUrl for the nested deleted entity is the same as it would be in the flattened representation.

 

[17:44] Ralf Handl (SAP SE): ODATA-964 is OPEN

 

[17:44] Mike Pizzo: I move we resolve ODATA-964 as proposed.

 

[17:44] Matt Borges (SAP): i second

 

[17:44] Ralf Handl (SAP SE): ODATA-964 is RESOLVED as proposed
[17:45] Ralf Handl (SAP SE): 9.ODATA-980 SchemaVersion header, $SchemaVersion query option, or root URL versioning

 

[17:46] Mike Pizzo: example:
{ 
"@odata.type":"myns.myComplexType, 
"@SchemaVersion":"1.0", 
"prop1":1 
}
[17:46] Mike Pizzo: to annotate a property:
{ 
"prop1@odata.type":"myns.myComplexType, 
"prop1@SchemaVersion":"1.0", 
"prop1":1 
}

 

[17:50] Ralf Handl (SAP SE): Martin: schema version as a request header doesn't go well with caching
[17:52] Ralf Handl (SAP SE): Purpose 1: server tells client which schema version was used to generate response
[17:52] Ralf Handl (SAP SE): Best served by an annotation
[17:52] Ralf Handl (SAP SE): Purpose 2: client tells server which schema version it wants to get
[17:52] Ralf Handl (SAP SE): Maybe better served by a query option than a header

 

[17:56] Mike Pizzo: Revised proposal:
 
Proposal: for CSD01, clarify how the type is annotated, as below, leaving the rest of the semantics as in the current draft.  Annotations are a nice way for the client to know what schema version was used without having to parse a URL and get the query option. For CSD02, consider replacing the SchemaVersion request header with a query option.

 

[17:57] Martin Zurmuehl (SAP): I move to resolve ODATA-980 as proposed.

 

[17:57] Hubert Heijkers1: I second

 

[17:57] Ralf Handl (SAP SE): ODATA-980 is RESOLVED with the revised proposal
[17:58] Ralf Handl (SAP SE): New issue ODATA-994 - consider replacing SchemaVersion header with $SchemaVersion query option, or root URL versioning
[17:59] Ralf Handl (SAP SE): @Stefan: can you speak on 6.ODATA-965 UpdateGeoJSON Reference to RFC7946?
[18:00] Ralf Handl (SAP SE): 8.ODATA-974 Flesh out recommendations around OAuth support in OData

 

[18:10] Stefan Hagen: @Ralf: It should be a breeze to replace the reference, as we took care to only flesh out the prose clean up examples during the RFC process but I will need to go over the data types we use to e.g. to be sure we do not have problems with inner rings and other specialties that were set straight during the community discussions - sorry for being late, but will update the issue accordingly before Monday - so we can put it on next Thursdays agenda.
[18:11] Stefan Hagen: @Ralf: Have to follow on chat only currently

 

[18:23] Ralf Handl (SAP SE): @Stefan: no problem
[18:28] Ralf Handl (SAP SE): 6.Next meeting [10:20 am PT]
a.Thursday November 10, 2016 during 8-10 am PST?
[18:32] Ralf Handl (SAP SE): b.Thursday November 10, 2016 during 6:30-10 am PST?
[18:33] Ralf Handl (SAP SE): 7.AOB and wrap up [10:25 am PT]
[18:34] 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, 2. November 2016 16:51
To: odata@lists.oasis-open.org
Subject: RE: [odata] Agenda for OData TC meeting on 2016-11-03

 

Addition to 5.a.i:

10.          ODATA-993 - 14.2: Explicitly allow annotations on deleted entities

 

From: odata@lists.oasis-open.org [mailto:odata@lists.oasis-open.org] On Behalf Of Handl, Ralf
Sent: Mittwoch, 2. November 2016 13:55
To: odata@lists.oasis-open.org
Subject: [odata] Agenda for OData TC meeting on 2016-11-03

 

Here [1] is a draft agenda for the OData TC (Technical Committee) meeting scheduled on Thursday November 03, 2016 during 7-10:30 am PDT (15:00-18:30 CET). 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 [7:00 am PT]

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

 

2.        Approve agenda [7:05 am PT]

 

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

a.     Minutes from October 27, 2016 TC meeting: https://www.oasis-open.org/apps/org/workgroup/odata/download.php/59261/latest/odata-meeting-150_on-20161027-minutes.html

 

4.        Review action items [Action item list: https://www.oasis-open.org/apps/org/workgroup/odata/members/action_items.php] [7:15am PT]

a.     Action items due

                                  i.    #0036 Register the OData- headers and preferences with IANA

 

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

a.     Issues for V4.01_WD01 in New or Open state

                                  i.    Waiting for refined proposal

1.     ODATA-674 Specify navigation property binding combined with containment

2.     ODATA-879 Support Arrays of Arrays

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

4.     ODATA-920 Specify overflow for int data types (-INF, INF, NaN)

5.     ODATA-964 Need to clarify nested delta representation

6.     ODATA-965 UpdateGeoJSON Reference to RFC7946

7.     ODATA-966 13.4 Add example for navigation property bindings for containment navigation property

8.     ODATA-974 Flesh out recommendations around OAuth support in OData

9.     ODATA-980 SchemaVersion header, $SchemaVersion query option, or root URL versioning

                                 ii.    Scheduled for CSD02

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

2.     ODATA-817 Add client-side function odata.matchesRegularExpression

3.     ODATA-854 Consider use of OPTIONS for discovering formats, other capabilities and features

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

5.     ODATA-884 Add term ErrorCodes to describe possible codes in error messages (public comment c201510e00019)

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

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

 

6.        Next meeting [10:20 am PT]

a.     Thursday November 10, 2016 during 8-10 am PST?

 

7.        AOB and wrap up [10:25 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/document.php?document_id=56024&wg_abbrev=odata

 

 

 



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