RE: UPDATE: [odata] Agenda for OData TC meeting on 2017-07-13

[16:53] Stefan Hagen: RegInfo:{Voting Members: 1 of 12 (8%) (used for quorum calculation)}

[17:00] Stefan Hagen: RegInfo:{Voting Members: 1 of 12 (8%) (used for quorum calculation)}

[17:01] Stefan Hagen: @George: I registered you

[17:01] anonymous1 morphed into Matt Borges (SAP)

[17:01] Stefan Hagen: @Mark: I registered you

[17:01] Ralf Handl (SAP SE): Voting Members: 5 of 12 (41%) (used for quorum calculation)

[17:03] Ralf Handl (SAP SE): Voting Members: 6 of 12 (50%) (used for quorum calculation)

[17:07] Ralf Handl (SAP SE): 2.Approve agenda [8:05 am PT]

[17:09] Ralf Handl (SAP SE): 5.a.ii: new public review comment

[17:09] Ralf Handl (SAP SE): Agenda is approved

[17:09] Ralf Handl (SAP SE): 3.Approve minutes from previous meeting(s) [8:10 am PT]

a.Minutes from July 06, 2017 TC meeting: https://www.oasis-open.org/committees/download.php/61164/odata-meeting-180_on-20170706-minutes.html

[17:09] Ralf Handl (SAP SE): Minutes are approved

[17: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] [8:15am PT]

a.Action items due

i.None

[17:10] Ralf Handl (SAP SE): 5.Version 4.01 Public Review - 05 July 2017 to 03 August 2017

a.Issues

[17:10] Ralf Handl (SAP SE): i.ODATA-1091 Special values of numeric types (public comment c201707e0002)

[17:10] Ralf Handl (SAP SE): Proposal:

1) Restrict the 'special' numeric values to types Single, Double, and Decimal

2) keep 4.0 behavior for div operator - fail for division by zero

3) restrict fail-safe division by zero (resulting in -INF, INF, or null) to new divby operator

[17:11] Ralf Handl (SAP SE): DB2 DECFLOAT DIV is in sync with our proposal

[17:12] Ralf Handl (SAP SE): 1) Restrict the 'special' numeric values to types Single, Double, and Decimal(Scale=floating)

[17:13] Ralf Handl (SAP SE): 2) keep 4.0 behavior for div operator - fail for division by zero for dividends other than Single, Double, and Decimal(Scale=floating)

[17:14] Michael Pizzo: 3) restrict fail-safe division by zero (resulting in -INF, INF, or null) to new divby operator

[17:17] Ralf Handl (SAP SE): Defer motion until we have quorum

[17:18] Ralf Handl (SAP SE): ii.ODATA-1092 Navigation Property Binding (public comment c201707e0004)

[17:18] Ralf Handl (SAP SE): https://issues.oasis-open.org/browse/ODATA-1092

[17:18] Ralf Handl (SAP SE): Description:

Public Review Comment https://lists.oasis-open.org/archives/odata-comment/201707/msg00004.html

This comment concerns navigation property bindings. There are two parts, a general issue with 4.0 and a similar issue that has been introduced with 4.01. The comment refers to:

OData Common Schema Definition Language (CSDL) XML Representation Version 4.01

Committee Specification Draft 02 / Public Review Draft 02

 8.4 says:

> Containment navigation properties define an implicit entity set for each instance of its declaring structured

> type

 13.4 says:

> If the entity type of an entity set or singleton declares navigation properties, a navigation property binding

> allows describing which entity set or singleton will contain the related entities

It therefore makes sense that a Binding Target must identify a single entity set.

My issue is that this path is allowed to be a path to any "containment navigation property in scope". Such a path only identifies an entity set uniquely in cases where the path includes a singleton. If the path includes an EntitySet then, as per 8.4, it will be pointing to a set of EntitySets, one per entity instance.

 15.4 contains an example that highlights the problem:

> MySchema.MyEntityContainer/MyEntitySet/MyContainmentNavigationProperty

This issue applies to both version 4.0 and 4.01. The resulting navigation property is only weakly bound. Anyone attempting to validate a link must exhaustively search every instance of MyEntitySet to determine the validity of the link. You also have the strange situation that a bound navigation property may link to two different entities WITH THE SAME KEY. (There is no requirement that keys are unique across entity sets.) This contravenes one of the methods of addressing entities in URLs:

OData Version 4.01. Part 2: URL Conventions  4.9

> For [ ... ] collection-valued navigation properties with a NavigationPropertyBinding or ContainsTarget=true specification, members of the collection can be addressed by convention by appending the parenthesized key to the URL specifying the collection of entities

So the above is already a problem IMO and I propose that the target paths be restricted to traversing Singletons (that is, if an entity set is specified it must be the last component of the path).

Coming on to the new issue in 4.01...

Version 4.01 has modified the way navigation bindings work to allow a single navigation property to be bound, simultaneously, to multiple entity sets based on the type of the target. Straight away this triggers the same issue, that bound navigation properties no longer have unique keys.

I'm unhappy with the idea that a binding may now bind to multiple entity sets as it would involve removing the ability to append a key to uniquely identify an entity via a (bound) navigation path. It isn't clear what problem you're trying to solve here but it feels like it is best solved using multiple navigation properties rather than attempting an 'octopus binding'.

Even if you allow a single bound navigation property to bind to multiple entity sets the new feature creates the possibility of a partially bound navigation property. If I have a navigation property called A of type Collection(TypeA) and TypeA has two sub-types, TypeB and TypeC then we can now bind any of the following:

A/TypeA

A/TypeB

A/TypeC

The most specific rule applies so the last two rules override the first two but if we only bind A/TypeC then any instances of TypeB linked to A are unbound. The result is a partially bound navigation property. This could be corrected by requiring a default binding (with no type cast segment) if a type-cast binding is provided.

Hopefully helpful.

Steve

[17:19] Ralf Handl (SAP SE): Proposal:

13.4.2 Binding Target

Clarify that a containment navigation property can only be a target if it directly or indirectly belongs to a singleton - inserted text in square brackets:

    If the target is a target path, it MUST resolve to an entity set, singleton, or

   [direct or indirect] containment navigation property [of a singleton] in scope."

15.4 Target Path - Example 67

Replace "MyEntitySet" with "MySingleton" in third and fourth example to avoid confusion.

13.4.1 Binding Path and 13.4.2 Binding Target - Example 37

Part 3) of ODATA-674 was not applied - binding path may traverse collection-valued segments, binding applies to all members. Example 37 is supposed to show this. Add missing text for Part 3) of ODATA-674 and refer to it in example 37.

[If the path traverses collection-valued complex properties or collection-valued containment navigation properties, the binding applies to all items of these collections.]

13.4.1 Binding Path with type-cast segment ("octopus binding") and Part 2, 4.9 Addressing a Member within an Entity Collection

A) do not allow "octopus binding" depending on type of target - this avoids incomplete bindings and guarantees addressability via an appended key segment as advertised in Part 2, section 4.9

B) add complicated wording to 13.4.1 and Part 2, section 4.9 to exactly capture under which circumstances a member of a navigation property with "octopus binding" can still be addressed via its key.

(Ralf is in favor of A

[17:26] Ralf Handl (SAP SE): Voting Members: 7 of 12 (58%) (used for quorum calculation)

[17:26] Ralf Handl (SAP SE): Quorum achieved: yes

[17:32] anonymous morphed into Ramesh Reddy

[17:32] Ramesh Reddy morphed into Ramesh Reddy(Red Hat)

[17:50] Ralf Handl (SAP SE): Bindings:

- Related/Type.A --> Foo

- Related/Type.B --> Bar

[17:50] Ralf Handl (SAP SE): X(42)/Related/Type.A(1)

[17:50] Ralf Handl (SAP SE): X(42)/Related/Type.A(1) --> Foo(1)

[17:51] Ralf Handl (SAP SE): X(42)/Related/Type.B(1) --> Bar(1)

[17:51] Ralf Handl (SAP SE): EntitySet X

[17:53] Ralf Handl (SAP SE): X(42)/Related(1) --> ???

[17:56] Matt Borges (SAP): I have to drop off for another call, I should be back in a few minutes

[18:03] Stefan Hagen: Stefan has to drop off now and abiding with Robert's Rules is trustfully leaving all in the other participants hands

[18:11] Michael Pizzo: Clients can always get the canonical URL for a member of a collection with a navigation property binding by appending the key to the target specified in the navigation property binding for the collection.  However, addressing an entity by appending the key to the navigation property is only supported if there is a single target entity set, otherwise we can't guarantee the keys are unique.

[18:15] Ralf Handl (SAP SE): ODATA-1092 is OPEN

[18:19] George Ericson (Dell): If Entities of different subtypes are in the same EntitySet, all such entities shall have unique keys in the EntitySet.

[18:20] Ralf Handl (SAP SE): @George: yes. The problem we face is for a case where we deal with a collection that is not an entity set

[18:24] Ralf Handl (SAP SE): Mike: two problems:

[18:24] Ralf Handl (SAP SE): - addressing by key in presence of bindings with type-cast

[18:25] Ralf Handl (SAP SE): - completeness of bindings with type-casts

[18:26] Ralf Handl (SAP SE): Need to cover all branches of the inheritance tree

[18:27] Ralf Handl (SAP SE): Could be done by requiring a binding for the declared type of the navigation property as a fallback if no more specific binding exists

[18:34] Ralf Handl (SAP SE): Addressing problem:

[18:34] Ralf Handl (SAP SE): - Binding without type-cast: append key

[18:35] Ralf Handl (SAP SE): - binding with type-cast: append type-cast and key

[18:35] Ralf Handl (SAP SE): - all cases: take target, append key

[18:41] George Ericson (Dell): Back in 5 min

[18:44] George Ericson (Dell): And back

[18:45] Michael Pizzo: Issue 1: Today, the presence of a navigationpropertybinding means that all members of a navigation property exist in the same entity set.  Because they existing in the same entity set, their keys must be unique, so appending the key to the navigation property must uniquely identify the member of the navigation property.

As above, this is what is broken when we introduce multiple navigation property bindings; you are no longer assured that the keys uniquely identify an entity within the collection (just as, in 4.0, you couldn't be sure the keys uniquely identified the entity within the collection if there was no navigation property binding present).

Clients can always get the canonical URL for a member of a collection with a navigation property binding by appending the key to the target specified in the navigation property binding for the collection.

Addressing an entity by appending the key directly to the navigation property is only supported if there is a single target entity set, otherwise we can't guarantee the keys are unique.  In 4.01, there is a single target entity set if there is a single navigation property that does not specify a type cast segment.  If the is a navigation property binding that includes the type in the path, then you can address instances of that type by appending the type, followed by the key, to the navigation property.

If the client is willing to look at the navigation property binding, they can use the target to address the entity. The whole point of appending the key to the navigation property is that you don't need to look up the target, you can address the entity by convention of appending the key to the navigation property.

Issue 2:

We should recommend that services provide navigation property bindings for all instances, either by specifying bindings for all derived types or by specifying a binding that does not include the type, as appropriate. However, we can't enforce this, so we need to cover the case where a member of the collection doesn't match any of the bound paths (i.e., there is no binding for its type and no binding that doesn't specify a type). This is treated the same as today if there was no navigation property binding for that instance.

[18:49] Ralf Handl (SAP SE): https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Capabilities.V1.xml#L268

[18:49] Michael Pizzo: For #1, we *could* introduce a new annotation to directly state that the convention of adding a key to the navigation property applies (i.e., that all members of the collection are uniquely identified by key). This is actually already there in capabilities using the indexable by key annotation.

[18:49] Ralf Handl (SAP SE): <Term Name="IndexableByKey" Type="Core.Tag" DefaultValue="true" AppliesTo="EntitySet Collection">

        <Annotation Term="Core.Description" String="Supports key values according to OData URL conventions" />

      </Term>

[18:56] Michael Pizzo: Proposal for last part:

We retain "octopus binding" with the semantics that:

1) If there is a single nav prop binding with no type, you can reference members by appending the key to the nav prop.

2) If there is a nav prop binding with a type, you must include the type when appending the key segment to the nav prop.

3) If you want to know if you can append the key to the nav prop, you should really be looking at IndexableByKey annotation in the capabilities vocabulary.

4) If no binding matches an instance, it is unbound (same semantics as no navigation property binding today).

[18:56] Hubert Heijkers (IBM): I move to resolve ODATA-1092 as proposed.

[18:57] Michael Pizzo: I second

[18:58] Michael Pizzo: I don't hear anyone; did we lose audio?

[18:58] Ralf Handl (SAP SE): ODATA-1092 is RESOLVED as proposed

[18:58] Hubert Heijkers (IBM): Only you I'm afraid Mike

[18:58] Ralf Handl (SAP SE): 7.Next meetings [9:50 am PT]

a.Thursday July 20, 2017 during 8-10 am PDT?

b.Thursday August 03, 2017 during 8-10 am PDT?

Two-week break mid of August, then back to weekly schedule

c.Thursday August 24, 2017 during 8-10 am PDT?

d.Thursday August 31, 2017 during 8-10 am PDT?

e.Thursday September 07, 2017 during 8-10 am PDT?

[18:58] Michael Pizzo: Oh; okay. I'll log back in...

[19:00] Ralf Handl (SAP SE): Meeting schedule works for Hubert

[19:01] Ralf Handl (SAP SE): Mike won't be able to attend all, but he can't loose voting rights

[19:02] 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, 12. Juli 2017 10:45
To: odata@lists.oasis-open.org
Subject: [odata] UPDATE: [odata] Agenda for OData TC meeting on 2017-07-13

5.a.ii: new public review comment

From: odata@lists.oasis-open.org [mailto:odata@lists.oasis-open.org] On Behalf Of Handl, Ralf
Sent: Dienstag, 11. Juli 2017 10:22
To: odata@lists.oasis-open.org
Subject: [odata] Agenda for OData TC meeting on 2017-07-13

Here [1] is a draft agenda for the OData TC (Technical Committee) meeting scheduled on Thursday July 13, 2017 during 8-10 am PDT (17:00-19:00 CEST). 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=43986

2. Approve agenda [8:05 am PT]

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

a. Minutes from July 06, 2017 TC meeting: https://www.oasis-open.org/committees/download.php/61164/odata-meeting-180_on-20170706-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. Version 4.01 Public Review - 05 July 2017 to 03 August 2017

a. Issues