Ralf Handl (SAP): Voting Members: 7 of 13 (53%) (used for quorum calculation)
Ralf Handl (SAP): Quorum achieved
Ralf Handl (SAP): 2)Approve agenda [6:05am]
Mike Pizzo: New Issues:
Mike Pizzo: 2.ODATA-957 Do we impose a format for SchemaVersion?
ODATA-956 Do we need to add SchemaVersion to ContextURL?
ODATA-953 Consider deprecating structural casting
1.ODATA-954 Key-As-Segment for multi-part keys
Ralf Handl (SAP): Tackle new issues between 5a and 5b
Ralf Handl (SAP): Agenda is approved with this modification
Ralf Handl (SAP): 3)Approve minutes from previous meeting(s) [6:10am]
a)Minutes from June 23, 2016 TC meeting: https://www.oasis-open.org/committees/document.php?document_id=58414&wg_abbrev=odata
Ralf Handl (SAP): Minutes are approved
Ralf Handl (SAP): 4)Review action items [Action item list: https://www.oasis-open.org/apps/org/workgroup/odata/members/action_items.php] [8:15am]
a)Action items due
i)#0036: Register the OData- headers and preferences with IANA (due July 31, 2016)
Ralf Handl (SAP): 5)V4.01 issues [7:00am]
a)Issues for V4.01_WD01 in New or Open state
i)Ripe for resolution
Mike Pizzo: <Term Name="TopSupported" Type="Core.Tag" DefaultValue="true" AppliesTo="EntitySet">
<Annotation Term="Core.Description" String="Supports $top" />
</Term>
Mike Pizzo: <Annotations Target="myEntitySet/myNavProp"><Annotation Term="Core.TopSupported"/><Annotation Term="Core.SkipSupported"/><Annotations>
Mike Pizzo: Revised proposal:
As we don't think we'll break clients, use "EntitySet Collection" in AppliesTo for these terms.
Hubert Heijkers: I move to resolve ODATA-545 as per the amended proposal.
Mike Pizzo: I second
Ralf Handl (SAP): ODATA-545 is resolved as proposed
Ralf Handl (SAP): (3)ODATA-674 Specify navigation property binding combined with containment *
Mike Pizzo: Discussion summary:-Hubert wants to be able to annotate that, wherever a particular type is used, the contents of one nav prop are found in another (containment) nav prop.
-For containment navigation properties, since the type definition defines the storage it might be reasonable to have the navpropbinding be on the type, rather than the entity set. This would not be desireable for navpropbindings for non-containment properties.
-Question on what the target is relative to. Is it relative to the terminus of the path (probably intended and desireable for navpropbindings on an entity set) or is it relative to "wherever the navpropbinding is applied" (which would work well for Hubert's case). Could perhaps address Huberts case by allowing the path within the target element to include things like ".." for "up one level" and "." for "start at the root".
-IN ANY CASE, we need to clarify the existing text around use with containment nav props in particular, and provide examples.
Mike Pizzo: Added to issue: Mike and Hubert will sync offline to go through some examples and create a proposal.
Ralf Handl (SAP): (2)ODATA-948 Versions of vocabularies and their relation with a version of the specification
Mike Pizzo: Current proposal:
1) We should not add 4.01 to the edmx Version element, as we are not defining a new version of the edmx (i.e., no new elements or attributes).
2) If we think "Collection" will break clients, clarify that the new "Collection" value added in ODATA-631 can only be returned for 4.01 and greater payloads
3) For 4.0 clients, the service can include a subset of valid values (i.e., just entityset) or can specify more generically (i.e., property, navigationproperty).
4) Tell 4.01 clients that they should be prepared for this set to expand in the future.
Mike Pizzo: Revised proposal:
Mike Pizzo: 1) We should not add 4.01 to the edmx Version element, as we are not defining a new version of the edmx (i.e., no new elements or attributes).
2) Tell 4.01 clients that they should be prepared for this set to expand in the future.
Mike Pizzo: I move we resolve ODATA-984 as proposed.
Hubert Heijkers: I second
Ralf Handl (SAP): ODATA-948 is resolved as proposed
Ralf Handl (SAP): xmlns:edmx="http://docs.oasis-open.org/odata/ns/edmx"
Ralf Handl (SAP): http://docs.oasis-open.org/odata/ns/edmx
Ralf Handl (SAP): Ralf to check with TC Admin how/whether we can update the edmx/edm XSDs with V4.01
Ralf Handl (SAP): Create action item
Ralf Handl (SAP): (3)ODATA-816 Add Capability term for filter _expression_ restrictions
Ralf Handl (SAP): Extend the term FilterRestriction with an additional property FilterExpressionRestrictions:
<Term Name="FilterRestrictions" Type="Capabilities.FilterRestrictionsType" AppliesTo="EntitySet">
<Annotation Term="Core.Description" String="Restrictions on $filter expressions" />
</Term>
<ComplexType Name="FilterRestrictionsType">
...
<Property Name="FilterExpressionRestrictions" Type="Collection(Capabilities.FilterExpressionRestrictionType)">
<Annotation Term="Core.Description" String="These properties only allow a subset of expressions" />
</Property>
</ComplexType>
<ComplexType Name="FilterExpressionRestrictionType">
<Property Name="Property" Type="Edm.PropertyPath" />
<Property Name="AllowedExpressions" Type="Capabilities.FilterExpressionType" />
</ComplexType>
<EnumType Name="FilterExpressionType">
<Member Name="SingleValue">
<Annotation Term="Core.Description" String="a single eq clause" />
</Member>
<Member Name="MultiValue">
<Annotation Term="Core.Description" String="several eq clauses, separated by or, are possible" />
</Member>
<Member Name="SingleInterval">
<Annotation Term="Core.Description"
String="at most one ge and one le clause, separated by and, alternatively a single eq clause" />
</Member>
</EnumType>
Ralf Handl (SAP): Mike: require use of "in" operator for MultiValue
Ralf Handl (SAP): https://issues.oasis-open.org/browse/ODATA-556
Ralf Handl (SAP): Mike: rename SingleInterval to SingleRange
Ralf Handl (SAP): low <= x <= high
Ralf Handl (SAP): low <= x
Ralf Handl (SAP): x <= high
Ralf Handl (SAP): low = x = high
Ralf Handl (SAP): a <= x <= a
Ralf Handl (SAP): x in (a)
Ralf Handl (SAP): Mark, Ralf: use AllowedValues instead of Enum
Ralf Handl (SAP): ODATA-816 is OPEN
Mike Pizzo: Slightly revised proposal:
Extend the term FilterRestriction with an additional property FilterExpressionRestrictions:
<Term Name="FilterRestrictions" Type="Capabilities.FilterRestrictionsType" AppliesTo="EntitySet">
<Annotation Term="Core.Description" String="Restrictions on $filter expressions" />
</Term>
<ComplexType Name="FilterRestrictionsType">
...
<Property Name="FilterExpressionRestrictions" Type="Collection(Capabilities.FilterExpressionRestrictionType)">
<Annotation Term="Core.Description" String="These properties only allow a subset of expressions" />
</Property>
</ComplexType>
<ComplexType Name="FilterExpressionRestrictionType">
<Property Name="Property" Type="Edm.PropertyPath" />
<Property Name="AllowedExpressions" Type="Capabilities.FilterExpressionType" />
</ComplexType>
<EnumType Name="FilterExpressionType"> <!-- rewrite as allowable values for future extensibility-->
<Member Name="SingleValue">
<Annotation Term="Core.Description" String="Property can be used in a single eq clause" />
</Member>
<Member Name="MultiValue">
<Annotation Term="Core.Description" String="Property can be used in a single in clause" />
</Member>
<Member Name="SingleRange">
<Annotation Term="Core.Description"
String="Property can be used in at most one ge and/or one le clause, separated by and" />
</Member>
</EnumType>
NOTE: the enum should be rewritten as allowable values for future extensibility.
Mark Biamonte (Progress): I move that OData-816 be resolved per the revised proposal
Mike Pizzo: I second.
Ralf Handl (SAP): ODATA-816 is resolved as proposed
Ralf Handl (SAP): (4)ODATA-809 Define non-message format for final response of async request
Mike Pizzo: Revised Proposal:
-For 4.01 clients, or 4.0 clients that do not specify application/http, the final results are not wrapped.
-Add a new response header, "AysncResult", whose value is the result code of the asynchronous operation and whose presence signals that the response has completed and the payload and headers represent the outcome of the asynchronous request. Services should always return this header value on the final result (whether wrapped or not).
Mike Pizzo: Now with improved spelling:
Revised Proposal:
-For 4.01 clients, or 4.0 clients that do not specify application/http, the final results are not wrapped.
-Add a new response header, "AsyncResult", whose value is the result code of the asynchronous operation and whose presence signals that the response has completed and the payload and headers represent the outcome of the asynchronous request. Services should always return this header value on the final result (whether wrapped or not).
Mike Pizzo: ==>Hubert will check with James to see if there was ever a Response header field defined for returning additional information about the outcome of the request (i.e., a status code of an asynchronously executed operation).
Ralf Handl (SAP): ODATA-809
Mike Pizzo: I move we resolve ODATA-809 as proposed, to be applied based on any feedback from James Snell.
Hubert Heijkers: I second
Ralf Handl (SAP): ODATA-809 is resolved as proposed
Ralf Handl (SAP): (5)ODATA-798 Semantic Key or Alternate Key for entity types
Mike Pizzo: Community proposals for alternate keys:
Mike Pizzo: https://github.com/OData/vocabularies/blob/master/OData.Community.Keys.V1.md
https://github.com/OData/vocabularies/blob/master/OData.Community.Keys.V1.xml
Ralf Handl (SAP): https://host/service/customers(customermasterid=987)
https://host/service/customers(DUNSNumber=665544332211)
https://host/service/customers(Branch=ABC,CustomerId=123)
Ralf Handl (SAP): ODATA-798 is OPEN
Mike Pizzo: Revised proposal:
Adopt the following community proposal by adding the term to the OData Core vocabulary and describing the behavior in [URL Conventions]:
https://github.com/OData/vocabularies/blob/master/OData.Community.Keys.V1.md
https://github.com/OData/vocabularies/blob/master/OData.Community.Keys.V1.xml
Mike Pizzo: Should term only be applied to entity sets, or should we allow it on entity types?
Mike Pizzo: Ralf; prefers to support entity type (for consistency with key)
Mike Pizzo: Consensus: term should be applied to entity type, entity set, or nav prop (as per current definition)
Mike Pizzo: Revised: AppliesTo should be EntityType and EntiySet. NavigationProperty would be an exception, is somewhat implied by entity set, and AppliesTo does not prohibit other uses.
Hubert Heijkers: I move to resolve ODATA-798 as per the revised proposal
Mark Biamonte (Progress): I second
Ralf Handl (SAP): ODATA-798 is resolved as proposed
Ralf Handl (SAP): (6)ODATA-938 In 4.01 decide if we can support invoking actions with no params with no body
Ralf Handl (SAP): ODATA-938 is OPEN
Mike Pizzo: Slightly modified proposal, based on discussion:
OData 4.01 services MUST support no content (as well as empty object), but as this was not called out until 4.01 clarify that interoperable clients should pass an empty json object in the body of the request.
Hubert Heijkers: I move to resolve ODATA-938 as proposed
Mike Pizzo: I second.
Ralf Handl (SAP): ODATA-938 is resolved as proposed
Ralf Handl (SAP): (7)ODATA-935 Allow singletons to be members of an entity set
Ralf Handl (SAP): ODATA-935 is open
Mike Pizzo: The NavigationPropertyBinding should not be returned for 4.0 clients.
Mike Pizzo: Discussion:
Allow singletons to be members of entity sets.
Consistent with how we define NavigtaionPropertyBindings on EntitySets, and Singletons today, we could extend the NavigationPropertyBinding within a singleton to support Path="." (or Path=empty string) to say that the binding is being applied to the singleton itself.
Any incompatible NavigationPropertyBinding should not be returned for 4.0 clients.
Ralf Handl (SAP): Park until ODATA-674 is resolved
Ralf Handl (SAP): (ODATA-952 Replace multiple batch capability term with single "BatchSupport" term
Ralf Handl (SAP): ODATA-952 is OPEN
Mike Pizzo: I propose we resolve ODATA-952 as proposed.
Martin Z. SAP SE: I second.
Ralf Handl (SAP): ODATA-952 is resolved as proposed
Ralf Handl (SAP): (9)ODATA-541 Allow the If-Match header to reference the ETag that resulted from an earlier operation in a batch request
Matt Borges (SAP): I move to resolve ODATA-541 as proposed
Hubert Heijkers: I second
Ralf Handl (SAP): ODATA-541 is resolved as proposed
Ralf Handl (SAP): 6)Next meeting [9:50am]
a)Thursday July 14, 2016 8-10am PT short meeting
b)Thursday July 21, 2016 6-10am PT again a longer meeting
Mike Pizzo: Please look at ODATA-923, especially questions in comments, and add your thoughts.
Ralf Handl (SAP): Both a) and b)
Ralf Handl (SAP): Next week: OpenAPI
From: odata@lists.oasis-open.org [mailto:odata@lists.oasis-open.org]
On Behalf Of Handl, Ralf
Sent: Dienstag, 5. Juli 2016 13:17
To: odata@lists.oasis-open.org
Subject: [odata] Agenda for TC meeting 2016-07-07
Here [1] is the agenda for the OData TC (Technical Committee) meeting
scheduled on Thursday July 07, 2016 during 6-10am Pacific Time. 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 [6:00am]
a)
Self-registration link:
https://www.oasis-open.org/apps/org/workgroup/odata/event.php?event_id=41470
2)
Approve agenda [6:05am]
3)
Approve minutes from previous meeting(s) [6:10am]
a)
Minutes from June 23, 2016 TC meeting:
https://www.oasis-open.org/committees/document.php?document_id=58414&wg_abbrev=odata
4)
Review action items [Action item list:
https://www.oasis-open.org/apps/org/workgroup/odata/members/action_items.php]
[8:15am]
a)
Action items due
i)
#0036: Register the OData- headers and preferences with IANA
(due July 31, 2016)
5)
V4.01 issues [7:00am]
a)
Issues
for V4.01_WD01 in New or Open state
i)
Ripe for resolution
(1)
ODATA-545 Allow applying Capability terms CountRestrictions, TopSupported, SkipSupported etc. to all resources returning
collections
(2)
ODATA-948 Versions of vocabularies and their relation with a version of the specification
(3)
ODATA-816
Add Capability term for filter _expression_ restrictions
(4)
ODATA-809 Define
non-message format for final response of async request
(5)
ODATA-798
Semantic Key or Alternate Key for entity types
(6)
ODATA-938 In 4.01 decide if we can support invoking actions with no params with no body
(7)
ODATA-935 Allow singletons to be members of an entity set
(8)
ODATA-952 Replace multiple batch capability term with single "BatchSupport" term
(9)
ODATA-541
Allow the If-Match header to reference the ETag that resulted from an earlier operation in a batch request
(10)ODATA-923 $expand for $metadata to include referenced
schemas
(11)ODATA-798 Semantic Key or Alternate Key for Entity Types
b)
OData Protocol
(1)
ODATA-919 Specify the result type for each operation based on operator types
(2)
ODATA-942 How should headers applied to a batch affect statements within a batch?
c)
Annotations
(1)
ODATA-571 Add annotation for properties that are (not) part of the default selection if no $select is specified
(2)
ODATA-735 Enhance the CSDL for instance annotations
(3)
ODATA-811 Define propagation and (partial) overriding of annotations
(4)
ODATA-859 Define term, semantics for inserting error information into a (mostly) successful response
(5)
ODATA-884 Add term ErrorCodes to describe possible codes in error messages (public comment c201510e00019)
d)
New Query Capabilities
(1)
ODATA-614 Allow $expand, $select, ... with POST/PATCH/PUT in combination with return=representation to specify the response
shape
(2)
ODATA-827 introduce $compute query option
(3)
ODATA-933 Allow using instance annotations in $filter
e)
Set Operations
(1)
ODATA-836 Allow applying actions to a filtered collection of entities
f)
Enumerations
(1)
ODATA-849 Add possibility for enumeration types to "extend" another enumeration type
(2)
ODATA-494 Define inheritance for enumeration types
(3)
ODATA-874 Allow Edm.String as underlying type for enumeration types
g)
OData CSDL
(1)
ODATA-618 Allow using term names in positions that allow type names
(2)
ODATA-929 Nullable facet should default to false for collection types, rather than being unspecified
(3)
ODATA-674
Specify navigation property binding combined with containment *
h)
JSON Format
(1)
ODATA-868 Describe format for In-Stream errors
(2)
ODATA-557 Allow exponential notation for Edm.Decimal
i)
Interfaces
(1)
ODATA-619 Attach action and function signatures to terms, i.e. make a term definition an interface definition
6)
Next meeting [9:50am]
a)
Thursday July 14, 2016 8-10am PT – short meeting
b)
Thursday July 21, 2016 6-10am PT – again a longer meeting
7)
AOB and wrap up [9:55am]
[2] References
- Conference call details:
https://www.oasis-open.org/apps/org/workgroup/odata/download.php/56760/TC%20meeting%20dial-in%20details.htm
- Chat room:
http://webconf.soaphub.org/conf/room/odatatc
[3] Timeline