Acting chair: Ralf
Chat transcript from room: odatatc 2017-01-19 0800-1000 PT
Gerald Krause (SAP SE) Martin Zurmuehl (SAP SE) Matthew Borges (SAP SE) a.k.a. Matt Michael Pizzo (Microsoft) a.k.a. Mike Ralf Handl (SAP SE) Ramesh Reddy (Red Hat) Stefan Hagen (Individual) Susam Malaika (IBM) Ted Jones (Red Hat)
Quorum achieved. Details cf. normative attendance sheet for this meeting (event_id=43961).
Notes taken by all and subsequently edited for readability by Stefan.
Ralf: Mike opened a new issue ODATA-1027 - Support instance annotations in $orderby
Add it as section 7.2.5
Ralf: Do this after action items, no further changes
Agenda approved as published with additional item "ODATA-1027".
Minutes approved unchanged as published.
- URL = https://www.oasis-open.org/committees/download.php/59831/TC Timeline-2017-01-19.docx
Stefan: directly publish CN01
Mike: may be useful for reviewers of V4.01, so publish it together with CSD02
Gerald: Extension for Data Aggregation
Close open issues
Add enhanced hierarchy handling
Ralf: Do Data Aggregation in parallel to CSDL JSON
Mike: not "backporting" issue resolutions to ERRATA04 will save a lot of work, make instead V4.01 the "current" document set
Mike: can the "latest" link for V4 point to V4.01? Ralf to clarify with TC Admin.
All agree to apply issues to V4.01 only from now on.
Ralf: ODATA-955 is OPEN
Mike: I move we resolve ODATA-955 as proposed. Stefan seconds.
Ralf: ODATA-955 is RESOLVED as proposed
Mike: will need more discussion
Ralf: Assign to Mike
Ralf: Assign to Ralf
Ralf: Assign to Hubert
Ralf: Matt will take this
Ralf: ODATA-1022 is OPEN
Stefan: I move to resolve ODATA-1022 as proposed and regard as pure editorial addition. Matt seconds.
Ralf: ODATA-1022 is RESOLVED
Ralf: ODATA-1023 is OPEN
Mike: I move we resolve ODATA-1023 as proposed. Stefan seconds.
Ralf: ODATA-1023 is RESOLVED
Ralf: ODATA-1024 is OPEN
Mike: I move we resolve ODATA-1024 as proposed. Gerald seconds.
Ralf: ODATA-1024 is RESOLVED
Ralf: ODATA-1025 is OPEN
Ralf: In Section 5.1, System Query Options], of URL Conventions, change:
"The same system query option MUST NOT be specified more than once for any resource."
"The same system query option, irrespective of casing or whether or not it is prefixed with "$", MUST NOT be specified more than once for any resource."
Stefan: I move to resolve ODATA-1025 AS PROPOSED. Ramesh seconds.
Ralf: ODATA-1025 is RESOLVED as proposed
The description of $it says it CAN be used in a number of cases (see section 220.127.116.11 in the URL conventions document) but it isn't specific about when $it MUST be used. We should clarify when $it is required. For example, my understanding is that both of these queries are equivalent (in which case the $it is not required):
http://host/service/Customers?$filter=Orders/any(d:d/Quantity ge Age)
http://host/service/Customers?$filter=Orders/any(d:d/Quantity ge $it/Age)
However, my understanding is that in the case below the $it is required:
http://host/service/Customers?$expand=Orders($filter=$it/Address/City eq ShipTo/City)
Ralf: ODATA-1026 is OPEN
Ralf: Michael Pizzo added a comment - Yesterday 11:57 PM
$it allows referencing the resource identified by the resource path. unqualified property references reference the current "scope". These may be the same thing in a simple request, but are not the same within a $expand (where an unqualified property reference references a property on the expanded nav prop). So in:
http://host/service/Customers?$expand=Orders($filter=$it/Address/City eq ShipTo/City)
Address would refer to a property on a Customer and ShipTo would refer to a property on an Order.
$it is also used:
-when referencing the resource itself (not a property of the resource), and
-when invoking a function or action bound to the resource (to distinguish from an unbound action or function)
Matt: I move we resolve ODATA-1026 as proposed in Mike's comment. Mike seconds.
Ralf: ODATA-1026 is RESOLVED according to Mike's comment
Stefan: I move to resolve ODATA-817 as proposed. Mike seconds.
Ralf: ODATA-817 is RESOLVED as proposed
Instead of an integer value the constant max MAY be specified as a shorthand for the maximum length supported for the type by the service. Responses for OData version 4.01 or later MUST/SHOULD NOT use the symbolic value max and instead specify the concrete maximum length supported for the type by the service.
Ralf: The OData 4.0 use of the symbolic value max in place of an integer value is deprecated in OData 4.01. While OData 4.0 clients MUST be prepared for this value, OData 4.01 and greater services MUST NOT return a value of max for the MaxLength attribute and MAY instead specify the concrete maximum length supported for the type by the service, or omit the attribute entirely.
Matt: I move we resolve ODATA-1008 as proposed in Mike's comment. Ramesh seconds.
Ralf: ODATA-1008 is RESOLVED as proposed
Nav properties specified in the select list of a defining query define the links for which the client is interested in receiving notifications.
Delta responses contain AddedLinks and DeletedLinks entries for navigation properties specified in the select list of the defining request.
Ralf: ODATA-1013 is OPEN
Mike: Alternatively use $expand=NavProp/$ref
Mike: Updated proposal: Nav properties specified in the select list of a defining query are not used to define the scope or contents of the items being tracked. Clients can specify /$ref in order to specify interest in the set of related entities without interest in changes to the content of those related entities.
Delta responses contain AddedLinks and DeletedLinks entries (or, for nested collections, (at least) entity references representing the current membership) for navigation properties expanded with $ref in the defining request.
Ralf: Mike to craft a revised proposal
PropertyPropertyPathPath to the restricted property
AllowedExpressionsFilterExpressionTypeAllowed subset of expressions
SingleValueProperty can be used in a single eq clause
MultiValueProperty can be used in a single in clause
SingleRangeProperty can be used in at most one ge and/or one le clause, separated by and
Add new allowed value
<Record> <PropertyValue Property="Value" String="Pattern" /> <Annotation Term="Core.Description" String="String property can be used as first operand in startswith, endswith, and contains clauses" /> </Record>
for properties representing character large objects.
Mike: "Pattern" might lead to confusion with Validation.Pattern and odata.matchesPattern which allow regular expressions
Ralf: So we need a term for something weaker than regular expressions
Stefan: Text (but not really happy with that ...)
Stefan: I move to resolve ODATA-1017 as proposed. Mike seconds.
Ralf: ODATA-1017 is RESOLVED with the amended proposal
Mike: what about other places, e.g. $select?
Ralf: ODATA-1027 is OPEN
Ralf: Mike to investigate if there are use cases for instance annotations in $select
Ralf: ODATA-674 is OPEN
Ralf: ODATA-854 is OPEN
Ralf: ODATA-868 is OPEN
Ralf: ODATA-884 is OPEN
Ralf: ODATA-919 is OPEN
Ralf: ODATA-962 is OPEN
Ralf: ODATA-994 is OPEN
Ralf: ODATA-1011 is OPEN
No objections, we meet next week usual time
Mike: Public reviews for V4.01 have started, please circulate the news and invite people to give feedback
Mike: Has been contacted by Open Data Institute http://theodi.org/
Mike: They want to list Wales open data OData services in their data catalog
Mike: They would benefit from having a mapping to DCAT https://www.w3.org/TR/vocab-dcat/
Ralf: A self-contained catalog vocabulary that correlates to DCAT would be sufficient
Mike: Link for OData.org community vocabularies: https://github.com/oasis-tcs/odata-vocabularies
Stefan: Has started to change Committee Note "Securing OData Version 4.0" Working Draft 01 - as this work product never progressed for months; he plans to radically simplify the document and shorten it's score (presumably also integrate changes helping resolve ODATA-1011).
Question: Do the members of the TC object to this, or can I go ahead and provide a new revised draft?
All support this and will provide feedback
Ralf: Notes draft never made it into kavi, please store current online version from onedrive in kavi, as archive
Stefan: Will check the current draft from onedrive into kavi, then he will start structural changes to simplify
Ralf: Suggests to keep/handle at least CORS, CSRF, and XSS. Everything else optional.
Stefan: Plans to do so and possibly add OAuth / openID topics to offer resolution for ODATA-1011 - Security experts at RSA suggest adding guidance on the use of OAuth and openID
Meeting adjourned by chair.