RE: Agenda for OData TC meeting on 2018-10-11

[17:02] Room information was updated by: Ralf Handl (SAP SE)

Here [1] is a draft agenda for the OData TC (Technical Committee) meeting scheduled on Thursday October 11, 2018 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=46277

2.Approve agenda [8:05 am PT]

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

a.Minutes from October 04, 2018 TC meeting: https://www.oasis-open.org/committees/download.php/64018/odata-meeting-232_on-20181004-minutes.html

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

a.Upcoming

i.#0037 Concept for Google Protocol Buffers as a data format  Hubert Heijkers  2018-12-06

b.In progress

i.#0036 Register the OData- headers and preferences with IANA  Mark Biamonte  2018-07-26

5.Issues [8:20 am PT]

a.APPLIED

i.ODATA-1212 pull request https://github.com/oasis-tcs/odata-vocabularies/pull/18

b.V4.01: NEW or OPEN

i.ODATA-1240 Chapter 2: wrong description of how to split URLs into syntax components

ii.ODATA-1239 Define a mechanism to distinguish between inserted and updated entities in a Delta Response

iii.ODATA-1238 Clarifications for select-list in ContextUrl

iv.ODATA-1198 ETag handling deviations from RFC7232 are avoidable if we consider two kinds of ETag (ETag in response header and ETag in response payload)

v.ODATA-1168 Clarify the use of ETags for Avoiding Update Conflicts

vi.ODATA-1165 Describe $expand and $select via prose text and examples, remove ABNF snippets

vii.ODATA-1135 Document use of JSON $schema

viii.ODATA-1064 Add ability to annotate collections to return only count and NextLink

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

c.Data Aggregation: NEW or OPEN

i.ODATA-1218 Transformations for recursive hierarchy processing

ii.ODATA-1207 Clarify need for @odata.id in nested response structures

iii.ODATA-947 Transformation for computing ratios with aggregated values

iv.ODATA-945 Correct examples 53 and 54

d.Vocabularies: NEW or OPEN

i.ODATA-1226 Ambiguity with Capabilities.ChangeTracking annotation

ii.ODATA-1216 Terms for POST/PATCH/PUT with system query options to shape response

iii.ODATA-1214 Annotate constructor actions

iv.ODATA-1200 ODATA-884 / Support sample values for types, parameters, request/response bodies

v.ODATA-1194 Add term Core.Example to allow including annotation examples in term definitions

vi.ODATA-1176 Capabilities: add new term SelectSupported

vii.ODATA-1140 ODATA-884 / Add details to HTTPResponseCode term

viii.ODATA-1099 Add annotations to describe custom query options and custom headers

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

e.Vocabularies: NEW or OPEN that need more discussion

i.ODATA-1177 Allow referencing a (JSON) schema for Edm.Untyped properties

ii.ODATA-1107 Introduce instance annotation to specify which types an instance "implements"

iii.ODATA-1060 Improve specification of element response requirements

6.Next meetings [9:50 am PT]

a.Thursday October 18, 2018 during 8-10 am PDT (17:00-19:00 CEST)

b.Thursday October 25, 2018 during 8-10 am PDT (17:00-19:00 CEST)

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

[2] References

Chat room: http://webconf.soaphub.org/conf/room/odatatc

Conference call & Screen sharing: https://lync.co.sap.com/meet/ralf.handl/Q4QB1098

Conference call details: https://www.oasis-open.org/apps/org/workgroup/odata/download.php/63673/latest/TC%20meeting%20dial-in%20details.htm

[3] Timeline

https://www.oasis-open.org/committees/download.php/62637/TC%20Timeline-2018-03-02.docx

[17:02] Ralf Handl (SAP SE): Voting Members: 3 of 10 (30%) (used for quorum calculation)

[17:04] Ralf Handl (SAP SE): Voting Members: 4 of 10 (40%) (used for quorum calculation)

[17:04] Ralf Handl (SAP SE): Voting Members: 5 of 10 (50%) (used for quorum calculation)

[17:05] Ralf Handl (SAP SE): Voting Members: 6 of 10 (60%) (used for quorum calculation)

[17:05] Ralf Handl (SAP SE): Achieved quorum: yes

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

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

[17:06] Michael Pizzo: Voting Members: 7 of 10 (70%) (used for quorum calculation)

[17:07] Ralf Handl (SAP SE): New issue: ODATA-1241 - Extend in operator to allow comparison with multiple properties

[17:07] Ralf Handl (SAP SE): Hubert's leave of absence

[17:08] Ralf Handl (SAP SE): Agenda is approved with the above changes

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

a.Minutes from October 04, 2018 TC meeting: https://www.oasis-open.org/committees/download.php/64018/odata-meeting-232_on-20181004-minutes.html

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

[17:08] Ralf Handl (SAP SE): 4.Review action items [Action item list: https://www.oasis-open.org/apps/org/workgroup/odata/members/action_items.php?sort_field=due_closed_date] [8:15am PT]

a.Upcoming

i.#0037 Concept for Google Protocol Buffers as a data format  Hubert Heijkers  2018-12-06

b.In progress

i.#0036 Register the OData- headers and preferences with IANA  Mark Biamonte  2018-07-26

[17:09] Ralf Handl (SAP SE): 4.1: Leave of absence for Hubert

[17:10] Ralf Handl (SAP SE): No objections, Hubert will be absent for 3 weeks starting October 15th

[17:10] Ralf Handl (SAP SE): 5.Issues [8:20 am PT]

a.APPLIED

i.ODATA-1212 pull request https://github.com/oasis-tcs/odata-vocabularies/pull/18

[17:11] Ralf Handl (SAP SE): <Term Name="AllowedTerms" Type="Collection(Core.QualifiedTermName)" AppliesTo="Term Property">

        <Annotation Term="Core.Description"

          String="Annotate a property or term of type Edm.AnnotationPath to restrict the terms that can be targeted by the path." />

        <Annotation Term="Core.LongDescription"

          String="Annotation path expressions assigned to the annotated term or property are intended to resolve to annotations with one of the listed terms. For forward compatibility, clients should be prepared for the annotation to reference terms besides those listed." />

        <Annotation Term="Core.RequiresType" String="Edm.AnnotationPath" />

      </Term>

[17:15] Ralf Handl (SAP SE): Change description to "term or property of a structured term"

[17:18] Ralf Handl (SAP SE): Annotate a term of type Edm.AnnotationPath, or a property of type Edm.AnnotationPath that is used within a structured term, to restrict the terms that can be targeted by the path.

[17:22] Ralf Handl (SAP SE): Example:

"RepresentAs":"@UI.LineItem#compact"

[17:24] Ralf Handl (SAP SE): Annotation path expressions are intended to resolve to annotations with one of the listed terms..

[17:24] Ralf Handl (SAP SE): Annotation path expressions are intended to end in a path segment with one of the listed terms...

[17:27] Ralf Handl (SAP SE): More verbose example:

"@UI.Visualization":{

  "RepresentAs":"@UI.LineItem#compact",

...

[17:28] Ralf Handl (SAP SE): "@UI.LineItem#compact": {...},

"@UI.LineItem#informative": {...},

"@UI.Chart#bar": {...},

[17:32] Ralf Handl (SAP SE): New LongDescription:

The annotation path _expression_ is intended to end in a path segment with one of the listed terms. For forward compatibility, clients should be prepared for the annotation to reference terms besides those listed.

[17:35] Ralf Handl (SAP SE): Pull request adapted accordingly

[17:35] Ralf Handl (SAP SE): New definition:

        "AllowedTerms": {

            "$Kind": "Term",

            "$Collection": true,

            "$Type": "Core.QualifiedTermName",

            "$AppliesTo": [

                "Term",

                "Property"

],

            "@Core.Description": "Annotate a term of type Edm.AnnotationPath, or a property of type Edm.AnnotationPath that is used within a structured term, to restrict the terms that can be targeted by the path.",

            "@Core.LongDescription": "The annotation path _expression_ is intended to end in a path segment with one of the listed terms. For forward compatibility, clients should be prepared for the annotation to reference terms besides those listed.",

            "@Core.RequiresType": "Edm.AnnotationPath"

[17:35] Ralf Handl (SAP SE): I move to merge pull request https://github.com/oasis-tcs/odata-vocabularies/pull/18

[17:35] Hubert Heijkers (IBM): I second

[17:36] Ralf Handl (SAP SE): No objection, motion passes

[17:38] Ralf Handl (SAP SE): b.V4.01: NEW or OPEN

[17:38] Ralf Handl (SAP SE): Ralf Handl created ODATA-1241:

---------------------------------

             Summary: Extend in operator to allow comparison with multiple properties

                 Key: ODATA-1241

                 URL: https://issues.oasis-open.org/browse/ODATA-1241

             Project: OASIS Open Data Protocol (OData) TC

          Issue Type: New Feature

          Components: URL Conventions

    Affects Versions: V4.01_CS01

         Environment: Proposed

            Reporter: Ralf Handl

             Fix For: V4.01_CS02

[17:38] Ralf Handl (SAP SE): escription

The in operator allows comparing a property to a list of values, e.g.

$filter=Name in ('Milk', 'Cheese')

For multi-part keys it would be helpful to allow comparison of a tuple of properties to a list of value tuples:

$filter=(Firstname,Lastname) in (('John', 'Doe'),('Jane','Smith'))

 Note that this is natively supported by some databases:

https://docs.oracle.com/cd/B19306_01/server.102/b14200/conditions013.htm

https://dev.mysql.com/doc/refman/8.0/en/comparison-operators.html#function_in

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

Allow using "property tuples" as the left operand of the in operator, and allow "tuples of tuples" as its right operand:

$filter=(Firstname,Lastname) in (('John', 'Doe'),('Jane','Smith'))

 Alternative syntax proposal with array notation:

$filter=[Firstname,Lastname] in [['John', 'Doe'],['Jane','Smith']]

[17:43] Ralf Handl (SAP SE): Name in (["Milk", "Cheese"])

[17:44] Michael Pizzo: $filter=[Firstname,Lastname] in (['John', 'Doe'],['Jane','Smith'])

[17:45] Michael Pizzo: $filter=['Jane','Smith'] in (['John', 'Doe'],['Jane','Smith'])

[17:46] Ralf Handl (SAP SE): ["Jane","Smith"] in (["John", "Doe"],["Jane","Smith"])

[17:49] Michael Pizzo: [1+2]

[17:49] Michael Pizzo: ==[3]

[17:49] Michael Pizzo: Do we just allow expressions in array constructors?

[17:49] Ramesh Reddy(Red Hat): In SQL (Firstname,Latname) is _expression_ that represents a array, I am not sure how that can be used in comparisions

[17:49] Ralf Handl (SAP SE): > let n = [1+2]

undefined

> n

[ 3 ]

[17:50] Ralf Handl (SAP SE): > [n]

[ [ 3 ] ]

[17:51] Michael Pizzo: Taking one step further, do we allow expressions in JSON constructs in the URL?

[17:51] Michael Pizzo: {"foo":1+2}

[17:52] Michael Pizzo: =={"foo":3}

[17:52] Michael Pizzo: {"foo":lastName}

[17:55] Michael Pizzo: Customers?$filter=BusinessAddress eq {"Street":"123","City":"abc","Region":"xyz","ZipCode":HomeAddress/ZipCode}

[17:57] Ralf Handl (SAP SE): Mike: better to extend URL-JSON generically than add a one-off construct for left side of "in"

[17:58] Ralf Handl (SAP SE): Hubert: use commonExpression and not just allow memberExpressions (paths to properties)

[18:05] Mark Biamonte (Progress): I need to drop off of the call.  Will join again next week

[18:06] Ralf Handl (SAP SE): {Street:"Highway"}

[18:07] Ralf Handl (SAP SE): Shortcut for {"Street":"Highway"}?

[18:07] Ralf Handl (SAP SE): Or means: take current value of property Street and use it as the name in the name-value pair?

[18:09] Ralf Handl (SAP SE): Adapted proposal:

llow using common expressions as "values" in URL-JSON. This will allow to construct an array from properties as the left operand of  the in operator:

$filter=[Firstname,Lastname] in (["John","Doe"],["Jane","Smith"])

Note: a list of arrays is already allowed as the right operand.

[18:10] Ralf Handl (SAP SE): ODATA-1241

[18:10] Ralf Handl (SAP SE): is OPEN

[18:11] Ralf Handl (SAP SE): Rename issue

[18:12] Michael Pizzo: Renamed to:"Support common expressions as values in URL-JSON"

[18:13] Ralf Handl (SAP SE): Already allowed: $filter=["Joe","Miller"] in (["John","Doe"],["Jane","Smith"])

[18:14] Michael Pizzo: I move to resolve ODATA-1241 as proposed

[18:14] George Ericson (Dell): second

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

[18:15] Ralf Handl (SAP SE): i.ODATA-1240 Chapter 2: wrong description of how to split URLs into syntax components

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

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

The text currently says

Split undecoded URL into components scheme, hier-part, query, and fragment at first ":", then first "?", and then first "#"

The query part is optional, and the fragment may contain the question mark character, so the descriptio is incorrect.

Don't try to capture the RFC3986 ABNF into concise and correct text.

[18:16] Ralf Handl (SAP SE): Proposal:

Shorten text to

Split undecoded URL into components scheme, hier-part, query, and fragment

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

[18:20] Ralf Handl (SAP SE): The generic URI syntax consists of a hierarchical sequence of

   components referred to as the scheme, authority, path, query, and

   fragment.

[18:21] Ralf Handl (SAP SE): New Proposal:

Shorten text to

Split undecoded URL into components scheme, authority, path, query, and fragment

[18:21] Ralf Handl (SAP SE): [RFC3986] defines three steps for URL processing that MUST be performed before percent-decoding:

       Split undecoded URL into components scheme, hier-part, query, and fragment at first ":", then first "?", and then first "#"

       Split undecoded hier-part into authority and path

       Split undecoded path into path segments at "/"

[18:22] Ralf Handl (SAP SE): [RFC3986] defines three steps for URL processing that MUST be performed before percent-decoding:

       Split undecoded URL into components scheme, authority, path, query, and fragment

       Split undecoded path into path segments at "/"

[18:22] Michael Pizzo: a little more context:

2     URL Components

A URL used by an OData service has at most three significant parts: the service root URL, resource path and query options. Additional URL constructs (such as a fragment) can be present in a URL used by an OData service; however, this specification applies no further meaning to such additional constructs.

Example 2: OData URL broken down into its component parts:

http://host:port/path/SampleService.svc/Categories(1)/Products?$top=2&$orderby=Name

\______________________________________/\____________________/ \__________________/

                  |                               |                       |

          service root URL                  resource path           query options

Mandated and suggested content of these three significant URL components used by an OData service are covered in sequence in the three following chapters.

OData follows the URI syntax rules defined in [RFC3986] and in addition assigns special meaning to several of the sub-delimiters defined by [RFC3986], so special care has to be taken regarding parsing and percent-decoding.

[RFC3986] defines three steps for URL processing that MUST be performed before percent-decoding:

       Split undecoded URL into components scheme, hier-part, query, and fragment at first ":", then first "?", and then first "#"

       Split undecoded hier-part into authority and path

       Split undecoded path into path segments at "/"

After applying these steps defined by RFC3986 the following steps MUST be performed:

       Split undecoded query at "&" into query options, and each query option at the first "=" into query option name and query option value

       Percent-decode path segments, query option names, and query option values exactly once

       Interpret path segments, query option names, and query option values according to OData rules

[18:33] Ralf Handl (SAP SE): Mike: chapter is talking about two things: OData syntax components, and how to parse a URL

[18:34] Ralf Handl (SAP SE): Might just split this into two sections 2.1 OData URLs, and 2.2 URL Parsing

[18:34] Michael Pizzo: Probably better to talk about hier-part in the parsing section, to avoid confusion with resource path in first part.

[18:36] Michael Pizzo: Here is the full text of section 2:

2     URL Components

A URL used by an OData service has at most three significant parts: the service root URL, resource path and query options. Additional URL constructs (such as a fragment) can be present in a URL used by an OData service; however, this specification applies no further meaning to such additional constructs.

Example 2: OData URL broken down into its component parts:

http://host:port/path/SampleService.svc/Categories(1)/Products?$top=2&$orderby=Name

\______________________________________/\____________________/ \__________________/

                  |                               |                       |

          service root URL                  resource path           query options

Mandated and suggested content of these three significant URL components used by an OData service are covered in sequence in the three following chapters.

OData follows the URI syntax rules defined in [RFC3986] and in addition assigns special meaning to several of the sub-delimiters defined by [RFC3986], so special care has to be taken regarding parsing and percent-decoding.

[RFC3986] defines three steps for URL processing that MUST be performed before percent-decoding:

       Split undecoded URL into components scheme, hier-part, query, and fragment at first ":", then first "?", and then first "#"

       Split undecoded hier-part into authority and path

       Split undecoded path into path segments at "/"

After applying these steps defined by RFC3986 the following steps MUST be performed:

       Split undecoded query at "&" into query options, and each query option at the first "=" into query option name and query option value

       Percent-decode path segments, query option names, and query option values exactly once

       Interpret path segments, query option names, and query option values according to OData rules

The OData rules are defined in this document and the [OData-ABNF]. Note that the ABNF is not expressive enough to define what a correct OData URL is in every imaginable use case. This specification document defines additional rules that a correct OData URL MUST fulfill. In case of doubt on what makes an OData URL correct the rules defined in this specification document take precedence. Note also that the rules in [OData-ABNF] assume that URLs and URL parts have been percent-encoding normalized as described in section 6.2.2.2 of [RFC3986] before applying the grammar to them, i.e. all characters in the unreserved set (see rule unreserved in  [OData-ABNF]) are plain literals and not percent-encoded. For characters outside of the unreserved set that are significant to OData the ABNF rules explicitly state whether the percent-encoded representation is treated identical to the plain literal representation. This is done to make the input strings in the ABNF test cases more readable.

For example, one of these rules is that single quotes within string literals are represented as two consecutive single quotes.

Example 3: valid OData URLs:

http://host/service/People('O''Neil')

http://host/service/People(%27O%27%27Neil%27)

http://host/service/People%28%27O%27%27Neil%27%29

http://host/service/Categories('Smartphone%2FTablet')

Example 4: invalid OData URLs:

http://host/service/People('O'Neil')

http://host/service/People('O%27Neil')

http://host/service/Categories('Smartphone/Tablet')

The first and second examples are invalid because a single quote in a string literal must be represented as two consecutive single quotes. The third example is invalid because forward slashes are interpreted as path segment separators and Categories('Smartphone is not a valid OData path segment, nor is Tablet').

[18:37] Michael Pizzo: I would do a 2.1 as Parsing rules and a 2.2 as OData ABNF, keep the three parts of an OData url as top-level

[18:38] Michael Pizzo: And use hier-part in section 2.1

[18:40] Michael Pizzo: 1) Put parsing rules in a 2.1 subsection, and OData ANBF in a 2.2 subsection.

2) In Parsing rules, shorten text of first step to:

 * Split undecoded URL into components scheme, hier-part, query, and fragment

[18:41] Hubert Heijkers (IBM): I move to resolve ODATA-1240 as per the amended proposal

[18:41] Michael Pizzo: I second

[18:41] Ralf Handl (SAP SE): ODATA-1240 is RESOLVED with the amended proposal

[18:41] Ralf Handl (SAP SE): ii.ODATA-1239 Define a mechanism to distinguish between inserted and updated entities in a Delta Response

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

[18:42] Ralf Handl (SAP SE): ODATA-1239 is OPEN

[18:44] Ralf Handl (SAP SE): Mike: concern that delta until now is idempotent, so you can apply the same delta twice, giving the same result

[18:44] Ralf Handl (SAP SE): Indicating that an entity is inserted versus updated might tempt implementations to break this

[18:47] Ralf Handl (SAP SE): Hubert: make sure that we describe that entities in delta payloads are UPSERT-ed

[18:48] Ralf Handl (SAP SE): Hubert: and that UPSERT rules are applied

[18:49] George Ericson (Dell): Use of & is defined in https://tools.ietf.org/html/rfc6570

[18:49] Ralf Handl (SAP SE): iii.ODATA-1238 Clarifications for select-list in ContextUrl

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

[18:50] Michael Pizzo: Currently we say:

Context URL templates:

  {context-url}#{entity-set}{/type-name}{select-list}/$entity

  {context-url}#{singleton}{select-list}

  {context-url}#{type-name}{select-list}

If a single entity contains a subset of properties, the parenthesized comma-separated list of the selected defined or dynamic properties, navigation properties, functions, and actions is appended to the entity-set after an optional type-cast segment and prior to appending /$entity. If the response is not bound to a single entity set, the select-list is instead appended to the

Unknown macro: {type-name}

of the returned entity.

The shortcut * represents the list of all structural properties. Properties defined on types derived from the type of the entity set (or type specified in the type-cast segment if specified) are prefixed with the qualified name of the derived type as defined in [OData-ABNF]. Note that expanded properties are implicitly selected.

OData 4.01 responses MAY use the shortcut pattern namespace.* to represent the list of all bound actions or functions available for entities in the collection, see system query option $select.

[18:51] Michael Pizzo: note the statement: "Note that expanded properties are implicitly selected."

[18:55] Michael Pizzo: Proposal 1: Remove the statement "Note that expanded properties are implicitly selected."  We do not expect that the navigation link is implicitly included just because you expanded the nav prop.

[18:57] Ralf Handl (SAP SE): Agreed

[18:57] Michael Pizzo: Customers?$select=name,Orders =>contextUrl= Customers(name,Orders) => result contains nav link for Orders

[18:58] Michael Pizzo: Customers?$select=name&$expand=Orders => contextUrl Customers(name,Orders()) => results contains expanded orders

[19:00] Ralf Handl (SAP SE): Do we need the Orders() part?

[19:00] Michael Pizzo: Customers?$select=name&$expand=Orders($select=Amount) => ContextUrl = Customers(name,Orders(Amount)) => results contains amount of expanded orders

[19:02] Stefan Hagen: @Ralf: Minutes will be uploaded a few minutes after adjourn ...

[19:04] Michael Pizzo: Customers?$select=name,Orders&$expand=Orders => ContextUrl = Customers(name,Orders,Orders()) => includes both nav link and expanded orders

[19:09] Michael Pizzo: Next issue: If my contextUrl contains only expanded properties, what is selected? i.e., ContextUrl => Customers(Orders())

[19:10] Michael Pizzo: http://host/service/Employees(1)/Sales.Manager?

$expand=DirectReports($select=FirstName,LastName;$levels=4)

http://host/service/$metadata

#Employees/Sales.Manager(DirectReports+(FirstName,LastName))/$entity

[19:11] Michael Pizzo: This implies that if I only have expanded properties in the contextUrl, I am implicitly selecting all properties of the outer resource

[19:12] Ralf Handl (SAP SE): Agreed

[19:13] Michael Pizzo: If we do Customers?$select=Address/City, Address/State => ContextUrl = Customers(Address/City,Address/State)

[19:14] Michael Pizzo: Alternately, you can say Customers?$select=Address(City,State) => ?

[19:15] Michael Pizzo: Assertion: this is just syntactic sugar over the former; the contexturl should be the same as the first example.

[19:16] Michael Pizzo: Next issue: How are functions/actions represented in ContextUrl?

[19:16] Ralf Handl (SAP SE): Agreed, with slight regret

[19:17] Michael Pizzo: 1) Always qualified with (namespace?alias?)

[19:18] Michael Pizzo: in the abnf:

select         = ( "$select" / "select" ) EQ selectItem *( COMMA selectItem )

selectItem     = STAR

               / allOperationsInSchema

               / [ ( qualifiedEntityTypeName / qualifiedComplexTypeName ) "/" ]

                 ( selectProperty

                 / qualifiedActionName

                 / qualifiedFunctionName

selectProperty = primitiveProperty

               / primitiveColProperty [ OPEN selectOptionPC *( SEMI selectOptionPC ) CLOSE ]

               / navigationProperty

               / selectPath [ OPEN selectOption *( SEMI selectOption ) CLOSE

                            / "/" selectProperty

[19:18] Michael Pizzo: qualifiedFunctionName = namespace "." function [ OPEN parameterNames CLOSE ]

[19:24] Ralf Handl (SAP SE): ; The parameterNames uniquely identify the bound function overload

; Necessary only if it has overloads

optionallyQualifiedActionName   = [ namespace "." ] action

optionallyQualifiedFunctionName = [ namespace "." ] function [ OPEN parameterNames CLOSE ]

[19:25] Michael Pizzo: In contextUrl functions w/o parens mean all overloads, functions w/parens mean specific overloads.  actions never have parens.

[19:28] Ralf Handl (SAP SE): Note: bug in ABNF - case of no non-binding-parameters not covered

[19:31] Ralf Handl (SAP SE): 6.Next meetings [9:50 am PT]

a.Thursday October 18, 2018 during 8-10 am PDT (17:00-19:00 CEST)

b.Thursday October 25, 2018 during 8-10 am PDT (17:00-19:00 CEST)

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

[19:31] Ralf Handl (SAP SE): Meeting is adjourned

From: odata@lists.oasis-open.org <odata@lists.oasis-open.org> On Behalf Of Handl, Ralf
Sent: Dienstag, 9. Oktober 2018 15:32
To: odata@lists.oasis-open.org
Subject: [CAUTION] [odata] Agenda for OData TC meeting on 2018-10-11

Here [1] is a draft agenda for the OData TC (Technical Committee) meeting scheduled on Thursday October 11, 2018 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]

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

2. Approve agenda [8:05 am PT]

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

Minutes from October 04, 2018 TC meeting: https://www.oasis-open.org/committees/download.php/64018/odata-meeting-232_on-20181004-minutes.html

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

Upcoming

i. #0037 Concept for Google Protocol Buffers as a data format – Hubert Heijkers – 2018-12-06

In progress

i. #0036 Register the OData- headers and preferences with IANA – Mark Biamonte – 2018-07-26

5. Issues [8:20 am PT]

APPLIED

i. ODATA-1212 pull request https://github.com/oasis-tcs/odata-vocabularies/pull/18

V4.01: NEW or OPEN

i. ODATA-1240 Chapter 2: wrong description of how to split URLs into syntax components

ii. ODATA-1239 Define a mechanism to distinguish between inserted and updated entities in a Delta Response

iii. ODATA-1238 Clarifications for select-list in ContextUrl

iv. ODATA-1198 ETag handling deviations from RFC7232 are avoidable if we consider two kinds of ETag (ETag in response header and ETag in response payload)

v. ODATA-1168 Clarify the use of ETags for Avoiding Update Conflicts

vi. ODATA-1165 Describe $expand and $select via prose text and examples, remove ABNF snippets

vii. ODATA-1135 Document use of JSON $schema

viii. ODATA-1064 Add ability to annotate collections to return only count and NextLink

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

Data Aggregation: NEW or OPEN

i. ODATA-1218 Transformations for recursive hierarchy processing

ii. ODATA-1207 Clarify need for @odata.id in nested response structures

iii. ODATA-947 Transformation for computing ratios with aggregated values

iv. ODATA-945 Correct examples 53 and 54

Vocabularies: NEW or OPEN

i. ODATA-1226 Ambiguity with Capabilities.ChangeTracking annotation

ii. ODATA-1216 Terms for POST/PATCH/PUT with system query options to shape response

iii. ODATA-1214 Annotate constructor actions

iv. ODATA-1200 ODATA-884 / Support sample values for types, parameters, request/response bodies

v. ODATA-1194 Add term Core.Example to allow including annotation examples in term definitions

vi. ODATA-1176 Capabilities: add new term SelectSupported

vii. ODATA-1140 ODATA-884 / Add details to HTTPResponseCode term

viii. ODATA-1099 Add annotations to describe custom query options and custom headers

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

Vocabularies: NEW or OPEN that need more discussion

i. ODATA-1177 Allow referencing a (JSON) schema for Edm.Untyped properties

ii. ODATA-1107 Introduce instance annotation to specify which types an instance "implements"

iii. ODATA-1060 Improve specification of element response requirements

6. Next meetings [9:50 am PT]

Thursday October 18, 2018 during 8-10 am PDT (17:00-19:00 CEST)
Thursday October 25, 2018 during 8-10 am PDT (17:00-19:00 CEST)

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

[2] References

Chat room: http://webconf.soaphub.org/conf/room/odatatc
Conference call & Screen sharing: https://lync.co.sap.com/meet/ralf.handl/Q4QB1098
Conference call details: https://www.oasis-open.org/apps/org/workgroup/odata/download.php/63673/latest/TC%20meeting%20dial-in%20details.htm

[3] Timeline

https://www.oasis-open.org/committees/download.php/62637/TC%20Timeline-2018-03-02.docx

odata message