OData TC meeting #187 Thursday September 14, 2017

Acting chair: Ralf

Chat transcript from room: odatatc
2017-09-14 800-1000 PDT

1. Roll call

1.1 Members present

    Gerald Krause (SAP SE)
    Hubert Heijkers (IBM)
    Mark Biamonte (Progress Software)
    Michael Pizzo (Microsoft) a.k.a. Mike
    Ralf Handl (SAP SE)
    Ramesh Reddy (Red Hat)
    Stefan Hagen (Individual)
    Ted Jones (Red Hat)

Quorum achieved. Details cf. normative attendance sheet for this meeting (event_id=43995).

Notes taken by all and subsequently edited for readability by Stefan.

2. Approve agenda

Agenda approved unchanged as published.

3. Approve minutes from previous meeting(s)

3.1 Minutes from September 07, 2017 TC meeting #186

https://www.oasis-open.org/committees/download.php/61535/odata-meeting-186_on-20170907-minutes.html

Minutes approved unchanged as published.

4. Review action items [Link to Action item list]

4.1 Action items due

None

5. Version 4.01 Public Review - 05 July 2017 to 03 August 2017 - Issues

5.1 ODATA-1111 - Structural properties: default for $Nullable is true

Ralf: ODATA-1111 is OPEN

Mike: Note: since nullable is the common case for collections, we *could* define it as the default, just for collections, just for JSON, but that would mean that xml and json would be inconsistent and that, within JSON, the defaults for collection would be different from properties and parameters.

Ralf: 7.2.1 Nullable - XML
A Boolean value specifying whether a value is required for the property.
Attribute Nullable
The value of Nullable is one of the Boolean literals true or false.
If no value is specified for a single-valued property, the Nullable attribute defaults to true.
In OData 4.01 responses a collection-valued property MUST specify a value for the Nullable attribute.
If no value is specified for a collection-valued property, the client cannot assume any default value. Clients SHOULD be prepared for this situation even in OData 4.01 responses.

Ralf: 7.2.1 Nullable - JSON
A Boolean value specifying whether a value is required for the property.
$Nullable
The value of $Nullable is one of the Boolean literals true or false. Absence of the member means false.

Ralf: ReturnType - both JSON and XML
$Nullable
The value of $Nullable is one of the Boolean literals true or false. Absence of the member means true.
For single-valued return types the value true means that the action or function MAY return a single null value. The value false means that the action or function will never return a null value and instead will fail with an error response if it cannot compute a result.
For collection-valued return types the result will always be a collection that MAY be empty. In this case the Nullable attribute applies to items of the collection and specifies whether the collection MAY contain null values.

Mike: OpenAPI has nullable:false as default

Mike: JSON Schema requires type "null" to be explicitly mentioned, omission means "no null allowed"

Mike: We seem to be coming to consensus: Clean up the handling of null values in JSON by making $Nullable false the default in all usages within CSDL JSON?

Mike: I move we simplify the handling of null values in JSON by making $Nullable false the default value for all usages in JSON CSDL. Additionally, we clarify the meaning of $Nullable = true for a collection (that it allows null values within the collection) and disallow $Nullable=true for collection-valued navigation properties. Mark seconds.

Ralf: ODATA-1111 is RESOLVED with $Nullable:false as new default for properties, navigation properties, return types, and parameters

5.2 ODATA-1100 - Add mechanism for specifying match type for $search

Mark: I move that we resolve OData -1100 with no action. Mike seconds.

Ralf: ODATA-1100 is CLOSED without action

5.3 ODATA-1109 - Clarify that 'parameter' aliases can also be used to substitute expressions

Mike: Even without passing expressions to functions, we have the problem:

Me?$expand=Friends($filter=BestFriend/Gender eq @p1))&@p1=Gender 

... Does this return all of my friends whose best friend is the same gender as I am, or all of my friends whose best friend is the same gender as they are?

I would have expected that Gender be evaluated in the context of Me, since I am the topic of the current URL path segment.

Similarly for:

People?$expand=Friends($filter=BestFriend/Gender eq @p1))&@p1=Gender 

... Does that find the friends for each person whose best friend is the same gender as the person, or the person's friend?

In either case, the expression is not circular because it is being evaluated within the context of the same URL path segment. The circular references come in when the path segment where the alias is used is not the last path segment of the URL.

If we say that the alias is evaluated relative to the URL path segment (not to be confused with the expression path segment) in which it is used, then the first statement would be evaluated in the context of Me, while a function within the path would be evaluated within the context of that function, i.e., conceptually:

Customers(ID=42)/some.function(par1=@p);@p=FirstName/BestFriend 

... Thoughts?

Note that, no matter what, it makes sense for the *expression* "ID gt 1" to be passed into the $filter segment in:

/Customers/$filter=@f/some.Function()?@ID gt 1 

... Because the type of parameter for a $filter URL segment is an expression.

Hubert:

Me?$expand=Friends($filter=BestFriend/Gender eq @p1;@p1=Gender)

Mike:

Me?$expand=Friends($filter=BestFriend/Gender eq Gender)
Customers?$expand=Orders($filter=ShipTo/City eq @p1))&@p1=HomeAddress/City <= is legal, 
if parsed in context of the Customers but not legal if parsed in context of Orders...

Mike: But we could extend syntax to support

Customers?$expand=Orders($filter=ShipTo/City eq @p1;@p1=ShipFrom/City)

Hubert:

Customers?$expand=Orders($filter=ShipTo/City eq @p1;@p1=$it/HomeAddress/City)

Mike:

Customers?$expand=Orders($filter=ShipTo/City eq $it/HomeAddress/City)

Hubert: The $it literal can be used in expressions to refer to the current instance of the collection identified by the resource path.

Me?$expand=Friends($filter=BestFriend/Gender eq @p1;@p1=@p2)&$p2=Gender
Me?$expand=Friends($filter=BestFriend/Gender eq @p1;@p1=@p2)&@p2=Gender
Dimensions/$filter=@f/head/Hierarchies/$filter=$f/head/some.Function()?@ID gt 1

Mike:

Dimensions/$filter=@f/head/Hierarchies/$filter=@f/head/some.Function()?@f=ID gt 1

Hubert:

Dimensions/foo(@f)/head/Hierarchies/bar(@f)/some.Function?@f=...

Mike: The parameters would be evaluated in the context of the segment in which they are used. So the first @f would be relative to Dimensions, the second would be relative to Hierarchies.

Hubert:

Customers/Orders?$filter=TotalAmount > @max&@max=MaxTotalOrderAmount

Mike: Is this our proposal? Query parameters for $filter segment are always passed in as expressions. All other parameters are evaluated in the context in which they are defined and passed as literals.
We add syntax for nesting parameters within $expand.

Mike: Slightly clarified:
Query parameters for $filter segment are always passed in as expressions (because that is the expected type of the parameter). All other parameters are evaluated in the context in which they are defined and passed as literals.

We add syntax for nesting parameters assignments within $expand.

Ralf: What is the value of:

Me?$expand=Friends($filter=BestFriend/Gender eq @p;@p=Gender) over Me?$expand=Friends($filter=BestFriend/Gender eq Gender)?

Hubert: For a long expression it's nice not to have to repeat it multiple times.

Mike: Note: if we clarify the semantics of the first part we can add the semantics for the second part later.

Ralf: Would like to divide the question; define semantics for the current syntax first, and introduce an issue for the second question.

6. Next meetings

6.1 Next Meeting on Thursday September 21, 2017 during 06:00-09:00 am PDT (15:00-18:00 CEST)

Note: Two hours earlier, one hour longer

6.2 Meetings following the next one

7. AOB and wrap up

None

Meeting adjourned by chair.