RE: [odata] Agenda for OData TC meeting on 2016-10-27

[17:47] Room information was updated by: Stefan Hagen

Register: https://www.oasis-open.org/apps/org/workgroup/odata/event.php?event_id=41486  (please do so as usual, thanks).

Agenda draft: https://www.oasis-open.org/apps/org/workgroup/odata/email/archives/201610/msg00148.html

Minutes draft of previous meeting: https://www.oasis-open.org/committees/download.php/59196/odata-meeting-149_on-20161020-minutes.html

[17:48] Stefan Hagen: Quorumistics:: Voting Members: 1 of 12 (8%) (used for quorum calculation)

Room Information:

Register: https://www.oasis-open.org/apps/org/workgroup/odata/event.php?event_id=41486  (please do so as usual, thanks).

Agenda draft: https://www.oasis-open.org/apps/org/workgroup/odata/email/archives/201610/msg00148.html

Minutes draft of previous meeting: https://www.oasis-open.org/committees/download.php/59196/odata-meeting-149_on-20161020-minutes.html

[17:54] Stefan Hagen: Quorumistics:: Voting Members: 3 of 12 (25%) (used for quorum calculation)

[18:02] Stefan Hagen: Quorumistics:: Voting Members: 6 of 12 (50%) (used for quorum calculation)  (1 missing for quorum ...)

[18:02] Ralf Handl (SAP SE): Voting Members: 8 of 12 (66%) (used for quorum calculation)

[18:03] Ralf Handl (SAP SE): Achieved quorum: yes

[18:03] Ralf Handl (SAP SE): 2.Approve agenda [9:05 am PT]

[18:04] Ralf Handl (SAP SE): New Jira issue ODATA-992 - Prefer numeric representation of enumeration values

[18:04] Ralf Handl (SAP SE): Agenda is approved

[18:04] Ralf Handl (SAP SE): 3.Approve minutes from previous meeting(s) [9:10 am PT]

a.Minutes from October 20, 2016 TC meeting: https://www.oasis-open.org/committees/download.php/59196/odata-meeting-149_on-20161020-minutes.html

[18:04] Ralf Handl (SAP SE): Minutes are approved

[18:05] Ralf Handl (SAP SE): 4.Review action items [Action item list: https://www.oasis-open.org/apps/org/workgroup/odata/members/action_items.php] [9:15am PT]

a.Action items due

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

[18:05] Ralf Handl (SAP SE): Mark finished document for header registration

[18:05] Ralf Handl (SAP SE): Working on document for preferences registration

[18:05] Ralf Handl (SAP SE): Will add it to TC document repository for review next week

[18:06] Ralf Handl (SAP SE): 5.V4.01 [9:20 am PT]

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

i.Ready for resolution

1.ODATA-557 Allow exponential notation for Edm.Decimal

[18:06] Ralf Handl (SAP SE): Allow exponential notation for Edm.Decimal literals.

Add new symbolic value Scale="floating" for DECFLOAT values. The Precision attribute will specify the number of digits in the mantissa.

[18:07] Ralf Handl (SAP SE): Just to confirm;

1) Services would only allow scale="Floating" for 4.01 and versions of metadata,

2) As per OData-771, services should only return values in exponential notation if the ExponentialDecimals format parameter is specified

3) Also, as per OData-771, clients should only supply values in exponential notation if SupportedFormats returns ExponentialDecimals

For 4.01, rather than burdening the media type with additional format parameters, should we just say that 4.01 clients and services have to be prepared to receive decimals in exponential format? Do we still need the ExponentialDecimals format parameter for 4.0 clients to say they will accept decimals in exponential format, or should we not apply OData-771?

[18:11] Ralf Handl (SAP SE): Mike: 4.01 payloads by default may use exponential notation

[18:11] Ralf Handl (SAP SE): Mike: no use for keeping this format parameter for disabling exponential notation

[18:12] Ralf Handl (SAP SE): Keep format parameter for V4, and state that it has no meaning for V4.01

[18:13] Mike Pizzo: Additions to proposal:

[18:13] Mike Pizzo: Services would only allow scale="Floating" for 4.01 and versions of metadata,

For 4.01 JSON payload, exponential decimals is always assumed and format parameter is not needed.

[18:13] Mike Pizzo: Fixed typos:

[18:13] Mike Pizzo: Services would only allow scale="Floating" for 4.01 and later versions of metadata,

For 4.01 JSON payloads, exponential decimals is always assumed and format parameter is not needed or used.

[18:16] Hubert Heijkers1: I move to resolve ODATA-557 as per the amended proposal

[18:16] Mark Biamonte (Progress): I second

[18:16] Ralf Handl (SAP SE): ODATA-557 is RESOLVED with the modified proposal

[18:16] Ralf Handl (SAP SE): 2.ODATA-959 Allow path in an edm:key to also use a primitive property of a non null-able navigation property (recursively) of the entity type.

[18:19] Ralf Handl (SAP SE): Hubert: goal is to simplify deep-insert, where the foreign-key properties would have to be redundantly specified with the nested/related key properties

[18:22] Ralf Handl (SAP SE): Mike: would @odata.id be mandatory in this case, or would it be mandatory to sender-side expand the "foreign key" entities and include the key properties?

[18:28] Ralf Handl (SAP SE): Ralf: including key fields would be beneficial for delta-tombstones. Check if tombstones allow annotations and open issue otherwise.

[18:31] Ralf Handl (SAP SE): Hubert: deep-insert combined with server-generated keys for the principal entities is impossible if the dependent entities contains foreign-key properties.

[18:32] Ralf Handl (SAP SE): Mike: "remote-key" property should be immutable

[18:32] Ralf Handl (SAP SE): Hubert: no problem in targeted use cases

[18:40] Mike Pizzo: Additional Semantics:

In JSON payloads:

1)The id would always have to be written, even in minimal metadata, or

2)The nav properties were expanded to include at least the related ids (service *could* default expand to include the related id fields.)

You can only create the entity if:

a.You include a link to an existing related entity containing the key value, or

b.You do a deep insert that includes the related entity

You can't change the relationship to the related entity containing the key value (so it would have to be single, non-nullable, and immutable)

The referenced property(ies) on the related entity would have to be immutable (or, if changed, would delete the entity with the dependent key)

>>We could restrict this to say that the property of the related entity is a key of the related entity.

Deleting the related entity would delete the entity whose key referenced a property of that entity

[18:44] Ralf Handl (SAP SE): Hubert: restrict this new features to key properties of the related entities

[18:45] Ralf Handl (SAP SE): Mike: if we want to relax this in the future, we should explicitly point this out to clients

[18:50] Ralf Handl (SAP SE): ODATA-798 Semantic Key or Alternate Key for entity types

[18:52] Mike Pizzo: revised proposal:

Allow the path _expression_ to include references to primitive properties of non null-able navigation properties (recursively).

8.3.1 Attribute Name could be simply amended as in:

The edmropertyRef element MUST specify a value for the Name attribute which MUST be a path _expression_ resolving to a primitive property of the entity type itself or to a primitive property of a complex or a single-valued, non-nullable navigation property (recursively) of the entity type. The names of the properties in the path are joined together by forward slashes.

Semantics:

In JSON payloads:

1)The id must be written, even in minimal metadata, or

2)The nav properties must be expanded to include at least the related ids (service *could* default expand to include the related id fields.)

You can only create the entity if:

a.You include a link to an existing related entity containing the key value, or

b.You do a deep insert that includes the related entity

You can't change the relationship to the related entity containing the key value (so it would have to be single, non-nullable, and immutable)

The referenced property(ies) on the related entity must be immutable and must be unique (i.e., are generally a key of the related entity)

Deleting the related entity deletes the entity whose key referenced a property of that entity

[18:55] Martin Zurmuehl (SAP): I move to resolve ODATA-959 as per the amended proposal

[18:55] Mike Pizzo: (clarified intro sentence: Allow the path _expression_ to include references to unique, immutable, primitive (i.e., key) properties of non null-able, immutable navigation properties (recursively).

[18:56] Martin Zurmuehl (SAP): I move to resolve ODATA-959 as per the NEW amended proposal

[18:56] Ralf Handl (SAP SE): ODATA-959 is OPEN

[18:56] Martin Zurmuehl (SAP): I move to resolve ODATA-959 as per the most current amended proposal

[18:56] Hubert Heijkers1: I second

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

[18:57] Ralf Handl (SAP SE): 3.ODATA-969 Chapter 15, Example 32: syntax of "target" URL

[18:58] Ralf Handl (SAP SE): {

  "@odata.context": "http://host/service/$metadata#Employees/$entity",

  "#Model.RemainingVacation(Year)": {

    "title": "Remaining vacation from year...",

    "target": "Employees(2)/RemainingVacation(Year=@Year)"

},

...

[18:59] Ralf Handl (SAP SE): "target": "Employees(2)/RemainingVacation(Year=@abc)"

[19:02] Ralf Handl (SAP SE): "target": "Employees(2)/RemainingVacation({Year})"

[19:05] Ralf Handl (SAP SE): "target": "Employees(2)/RemainingVacation"

[19:05] Ralf Handl (SAP SE): GET Employees(2)/RemainingVacation?@Year=2016

[19:08] Ralf Handl (SAP SE): GET Employees(2)/RemainingVacation(Year=@Year)?@Year=2016

[19:10] Mike Pizzo: Clarification: Clarify in text that functions are invoked by adding the named parameters as query options. The syntax of the url is up to the service.

[19:11] Ralf Handl (SAP SE): ODATA-969 is OPEN

[19:11] Ralf Handl (SAP SE): I move to resolve ODATA-969 with the modified proposal

[19:11] Martin Zurmuehl (SAP): I second

[19:12] Ralf Handl (SAP SE): ODATA-969 is RESOLVED as proposed

[19:12] Ralf Handl (SAP SE): 4.ODATA-979 Recursive containment navigation properties and Partner attribute

[19:12] Ralf Handl (SAP SE): Containment navigation properties MAY specify a Partner attribute. If the containment is recursive, the partner navigation property MUST be nullable and specify a single entity type. If the containment is not recursive, the partner navigation property MUST NOT be nullable.

An entity type hierarchy MUST NOT contain more than one navigation property with a Partner attribute referencing a containment relationship.

[19:13] Ralf Handl (SAP SE): - EntityType Name=FileSystemEntry

  - NavigationProperty Name=Parent Type=this.FileSystemEntry Nullable=true

- EntityType Name=Folder BaseType=this.FileSystemEntry

  - NavigationProperty Name=Children Type=Collection(this.FileSystemEntry) Partner=Parent

- EntityType Name=File BaseType=this.FileSystemEntry

  - NavigationProperty Name=Parent Type=this.Folder Nullable=false

[19:17] Mike Pizzo: Alternate example:

[19:17] Mike Pizzo: - EntityType Name=FileSystemEntry

- NavigationProperty Name=Parent Type=this.FileSystemContainer Nullable=true

- EntityType Name=File BaseType=this.FileSystemEntry

- NavigationProperty Name=Parent Type=this.Folder Nullable=false

- EntityType Name=FileSystemContainer BaseType=this.FileSystemEntry

- NavigationProperty Name=Children Type=Collection(this.Folder) Partner=Parent ContainsTarget=true

- EntityType Name=Folder BaseType=this.FileSystemContainer

- NavigationProperty Name=Parent Type=this.FileSystemContainer Nullable=false

- EntityType Name=Drive BaseType=this.FileSystemContainer

[19:30] Ralf Handl (SAP SE): When a containment navigation property navigates between entity types in the same inheritance hierarchy, the containment is called recursive.

[19:42] Mike Pizzo: Clarify prose text:

Containment navigation properties MAY specify a Partner attribute. If the containment is recursive, the relationship defines a tree; thus the navigation property on the type defined as the partner MUST specify a single entity type and MUST be nullable (for the root of the tree). If the containment is not recursive, the partner navigation property MUST NOT be nullable.

An entity type inheritance chain MUST NOT contain more than one navigation property with a Partner attribute referencing a containment relationship.

[19:43] Ralf Handl (SAP SE): If the containment is not recursive, the partner navigation property MUST NOT be nullable because it leads back to the containing entity.

[19:45] Mike Pizzo: Revised proposal:

[19:45] Mike Pizzo: Clarify prose text:

Containment navigation properties MAY specify a Partner attribute. If the containment is recursive, the relationship defines a tree; thus the navigation property on the type defined as the partner MUST specify a single entity type and MUST be nullable (for the root of the tree). If the containment is not recursive, the partner navigation property MUST NOT be nullable because it leads back to the containing entity.

An entity type inheritance chain MUST NOT contain more than one navigation property with a Partner attribute referencing a containment relationship.

[19:45] Martin Zurmuehl (SAP): I move to resolve ODATA-979 with the modified proposal

[19:46] Ralf Handl (SAP SE): ODATA-979 is OPEN

[19:46] Martin Zurmuehl (SAP): I move to resolve ODATA-979 with the modified proposal

[19:46] Mike Pizzo: I second

[19:46] Ralf Handl (SAP SE): ODATA-979 is RESOLVED as proposed

[19:46] Ralf Handl (SAP SE): 5.ODATA-980 SchemaVersion header, $SchemaVersion query option, or root URL versioning

[19:48] Ralf Handl (SAP SE): The SchemaVersion header and accompanying annotation are intended to allow breaking changes without having to change the service root URL.

How does this combine with type referencing in the @odata.type annotation?

We could annotate the @odata.type annotation with the @Core.SchemaVersion:

    "@odata.type":"https://some.whe.re/$metadata"

    "@odata.type@Core.SchemaVersion":"2.0.1",

Or we could add a system query option and make the schema version part of the URL:

    "@odata.type":"https://some.whe.re/$metadata?$SchemaVersion=2.0.1",

Or we could reconsider this and fall back to root URL versioning:

    "@odata.type":"https://some.whe.re;v=2.0.1/$metadata",

[19:55] Ralf Handl (SAP SE): JSON Format:

[19:55] Ralf Handl (SAP SE): Request payloads MAY include a context URL as a base URL for relative URLs in the request payload.

Example 4:

  "@context": "http://host/service/$metadata#Customers/$entity",

  "@metadataEtag": "W/\"A1FF3E230954908F\"",

  "@Core.SchemaVersion": "2.0.1",

...

[20:04] Ralf Handl (SAP SE): Homework: reconsider schema version mechanism, e.g. based on query option instead of request header

[20:05] Ralf Handl (SAP SE): ODATA-980 is OPEN

[20:06] Mike Pizzo: sorry; call dropped.  calling back in...

[20:06] Ralf Handl (SAP SE): New proposal that reflects the homework: Add a $schemaversion system query option instead of a SchemaVersion header and use this in @odata,type URLs if the type needs refering to a specific schema version.

[20:08] Ralf Handl (SAP SE): Move issue into category "Needs refined proposal"

[20:08] Ralf Handl (SAP SE): 6.ODATA-983 Chapter 15/16: advertise actions on collection-valued properties

[20:08] Ralf Handl (SAP SE): Prefix the advertisement with the primitive- or collection-valued property name and place it next to the navigation property, similar to annotations on navigation properties:

  "NavProp#Model.SomeAction": {

    "title": "Do Something",

    "target": "Managers(22)/Employees/DoSomething"

},

    "NavProp": [ ... ]

Services must only returned this syntax in an OData 4.01 response.

[20:09] Ralf Handl (SAP SE): Mike: question is when this annotation is returned

[20:09] Ralf Handl (SAP SE): Question from discussion in 2016-10-13 meeting: when does this appear?

1) Only when expanded?

2) Only when expanded and selected?

3) If I expand and select only action, do I have the object or just the action advertisement?

[20:13] Ralf Handl (SAP SE): $expand=NavProp($select=Model.SomeAction)

[20:13] Ralf Handl (SAP SE): would return just

NavProp#Model.SomeAction

[20:13] Ralf Handl (SAP SE): $expand=NavProp/$count

[20:14] Ralf Handl (SAP SE): NavProp@odata.count

[20:15] Ralf Handl (SAP SE): Question from discussion in 2016-10-13 meeting: when does this appear?

1) Only when expanded?

2) Only when expanded and selected?

3) If I expand and select only action, do I have the object or just the action advertisement?

[20:16] Mike Pizzo: proposed answers to questions from 2016-10-13:

Advertisement can appear any time.

If must appear if explicitly requested (i.e., through expand that explicitly selects the action/function).

If only the function/action is selected in the expand, then the nav property itself does not need to be included

[20:19] Mike Pizzo: Revised proposal:

Prefix the advertisement with the primitive- or collection-valued property name and place it next to the property, similar to annotations on navigation properties:

  "NavProp#Model.SomeAction": {

    "title": "Do Something",

    "target": "Managers(22)/Employees/DoSomething"

},

    "NavProp": [ ... ]

Services must only returned this syntax in an OData 4.01 response.

These advertisement can appear any time.

They don't need to be included in an expand if not explicitly requested.

They must appear if explicitly requested (i.e., through expand that explicitly selects the action/function).

If only the function/action is selected in the expand, then the nav property itself does not need to be included

[20:21] Mike Pizzo: I move we resolve ODATA-983 as proposed.

[20:21] Martin Zurmuehl (SAP): I second

[20:21] Ralf Handl (SAP SE): ODATA-983 is RESOLVED as proposed

[20:22] Ralf Handl (SAP SE): 7.ODATA-985 The HTTP Specification document referenced in the OData Protocol Spec has been obsoleted

[20:22] Ralf Handl (SAP SE): Proposal:

Substitute [RFC2617] by [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, September 2015. http://www.ietf.org/rfc/rfc7617.txt

[20:23] Martin Zurmuehl (SAP): But we still use the also obsolete RFC2617 (HTTP Authentication: Basic and Digest Access Authentication) in the protocol spec.

Documents updating RFC 2617 are

"Hypertext Transfer Protocol (HTTP/1.1): Authentication" ([RFC7235], defining the authentication framework),

"The 'Basic' HTTP Authentication Scheme" ([RFC7617] updating the definition of the

   "Basic" authentication scheme),

"HTTP Digest Access Authentication" ([RFC7616], updating

   the definition of the "Digest" authentication scheme), and

 "HTTP Authentication-Info and Proxy-Authentication-Info Response Header

   Fields" ([RFC7615]).

Taken together, these four documents obsolete RFC2617.

We have 3 references to RFC2617 in the document; all 3 are pointing to the "basic authentication".

--> We should substitute RFC2617 by [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, September 2015. http://www.ietf.org/rfc/rfc7617.txt

There are no substantive changes from our perspective; the RFC7617 states:

"Changes from RFC 2617

   The scheme definition has been rewritten to be consistent with newer

   specifications such as [RFC7235].

   The new authentication parameter 'charset' has been added. It is

   purely advisory, so existing implementations do not need to change,

   unless they want to take advantage of the additional information that

   previously wasn't available.

I updated the proposal accordingly.

[20:24] Martin Zurmuehl (SAP): Substitute [RFC2617] by [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, September 2015. http://www.ietf.org/rfc/rfc7617.txt

[20:25] Mark Biamonte (Progress): I move that ODATA-985 be resolved as proposed

[20:25] Mike Pizzo: I second

[20:25] Ralf Handl (SAP SE): ODATA-985 is RESOLVED as proposed

[20:26] Ralf Handl (SAP SE): 8. ODATA-992 Prefer numeric representation of enumeration values

[20:26] Ralf Handl (SAP SE): Part 3: CSDL states that enumeration values are sorted and compared using their numeric value because it allows synonym symbolic names with the same numeric value.

Part 3: CSDL also only allows symbolic values in annotations.

JSON Format on the other hand states that the symbolic name, represented as a string, is preferred.

This makes life unnecessarily complicated for clients to evaluate conditional annotation expressions based on enums as they can't compare enum values in annotations and payloads without internally translating them into numeric values, which they can only know after reading vocabulary files.

[20:32] Ralf Handl (SAP SE): Mike: leave enumeration types as they are. If no flags or synonyms/symbolic names are required/desired, use annotation Validation.AllowedValues instead.

[20:39] Mike Pizzo: My Proposal would be:

Keep enumerations as-is; maps to programming enumerations and there has been a strong desire in the past to optimize for the string representation (the only reason we have underlying numeric values is for flags).

Call out that services that want a discrete set of numeric should use AllowedValues.

[20:41] Ralf Handl (SAP SE): ODATA-992 is OPEN

[20:43] Mike Pizzo: I move we resolve ODATA-992 as proposed (leaving enums as they are and recommending allowedvalues for purely numeric representations)

[20:44] Martin Zurmuehl (SAP): i second

[20:44] Ralf Handl (SAP SE): ODATA-992 is RESOLVED as proposed

[20:49] Ralf Handl (SAP SE): Vocabularies: move forward on placing them into a separate work product and get "latest-version" links for them.

[20:49] Ralf Handl (SAP SE): ii.Waiting for refined proposal

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

[20:49] Ralf Handl (SAP SE): 8.ODATA-966 13.4 Add example for navigation property bindings for containment navigation property

[20:51] Ralf Handl (SAP SE): 2.ODATA-743 Restructure Part 3: CSDL into CSDL Core, CSDL XML, and CSDL JSON

[20:52] Ralf Handl (SAP SE): Mike: 16 changes from Part 1 & 2 to Part 3 that would have to be changed to CSDL XML Format

[20:53] Ralf Handl (SAP SE): Proposal: publish CSD01 without Part 3, reconsider this for CSD02

[20:54] Mike Pizzo: For CSD01:

Update [OData-CSDL] normative reference to be to CSDL-XML.

For CSD02:

Format-independent draft: https://www.oasis-open.org/committees/download.php/59121/odata-v4.01-wd01-part3-csdl-2016-10-12.docx

Pure format spec draft (chapters 1 to 11): https://www.oasis-open.org/committees/download.php/59177/odata-csdl-xml-v4.01-wd01-min.docx

[20:55] Mike Pizzo: I move we resolve ODATA-743 as proposed.

[20:55] Martin Zurmuehl (SAP): I second

[20:55] Ralf Handl (SAP SE): ODATA-743 is RESOLVED as proposed

[20:55] Ralf Handl (SAP SE): 3.ODATA-879 Support Arrays of Arrays

[20:56] Ralf Handl (SAP SE): Related to 5.ODATA-920 Specify overflow for int data types (-INF, INF, NaN)

[20:56] Ralf Handl (SAP SE): 4.ODATA-919 Specify the result type for each operation based on operator types

[20:57] Ralf Handl (SAP SE): 6.ODATA-964 Need to clarify nested delta representation

[20:59] Ralf Handl (SAP SE): 6.Next meeting [11:50 am PT]

a.Thursday November 03, 2016 during 7-10:30 am PT

[21:00] Ralf Handl (SAP SE): 7.AOB and wrap up [11:55 am PT]

[21:00] Ralf Handl (SAP SE): Meeting is adjourned

[21:00] Stefan Hagen: @All/offrecord: Very productive, looking forward to condense in minutes

From: odata@lists.oasis-open.org [mailto:odata@lists.oasis-open.org] On Behalf Of Handl, Ralf
Sent: Montag, 24. Oktober 2016 11:15
To: odata@lists.oasis-open.org
Subject: [odata] Agenda for OData TC meeting on 2016-10-27

Here [1] is a draft agenda for the OData TC (Technical Committee) meeting scheduled on Thursday October 27, 2016 during 9-12 am PDT (18:00-21: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 [9:00 am PT]

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

2. Approve agenda [9:05 am PT]

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

a. Minutes from October 20, 2016 TC meeting: https://www.oasis-open.org/committees/download.php/59196/odata-meeting-149_on-20161020-minutes.html

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

a. Action items due

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

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

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