RE: [odata] Agenda for OData TC meeting on 2016-08-04

Room information was updated by: Stefan Hagen

Please register at https://www.oasis-open.org/apps/org/workgroup/odata/event.php?event_id=41474

Agenda draft at https://www.oasis-open.org/apps/org/workgroup/odata/email/archives/201608/msg00011.html

Stefan Hagen: Info: Voting Members: 1 of 11 (9%) (used for quorum calculation)

Stefan Hagen: InfoUpdate: Voting Members: 5 of 12 (41%) (used for quorum calculation)

Stefan Hagen: InfoUpdate: Voting Members: 5 of 12 (41%) (used for quorum calculation)

Stefan Hagen: @Ral/Hubertf: Shall I add Hubert to attendance?

Stefan Hagen: Ah, ok.

Stefan Hagen: Info: Voting Members: 6 of 12 (50%) (used for quorum calculation)

Stefan Hagen: @chair: I am still listed as "Leave of Absence", but I kindly requested only until "Last day: 2016-JUL-31"

Ralf Handl (SAP): Hi Stefan, I just changed you back to Secretary. You are already counted as a voting member (unlike Gerald), but the "leave of absence" marker won't go away

Stefan Hagen: @chair: Also Gerald only requested until 2016-JUL-29 ... I do not seem to be able as secretary to change that in roster.

Stefan Hagen: @Ralf: Thanks.

Stefan Hagen: now trying to get called by the gateway ...

Ralf Handl (SAP): Gerald also changed back to Voting Member

Ralf Handl (SAP): Manual calculation yields 7 of 13 voting members, > 50$%

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

Ralf Handl (SAP): Agenda is approved

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

a.Minutes from July 28, 2016 TC meeting: https://www.oasis-open.org/apps/org/workgroup/odata/download.php/58620/latest/odata-meeting-139_on-20160728-minutes.html

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 PT]

a.Action items due

i.0036 Register the OData headers and preferences with IANA (Ram)

Ralf Handl (SAP): No status update from Ram

Ralf Handl (SAP): 5.V4.01 [8:20am PT]

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

i.Ripe for resolution

1.ODATA-923 $expand (or $include) for $metadata to include referenced schemas

Ralf Handl (SAP): Postpone (again)

Ralf Handl (SAP): ii.OData Protocol

1.ODATA-873 Define a default order for deep inserted entities in responses

Ralf Handl (SAP): Proposal:

Ralf Handl (SAP): Introduce a new contentID annotation that the client can specify in the nested entities in the request. A server advertises support for the contentID instance annotation through the Capabilities.DeepInsertSupport annotation. Clients can specify the contentID instance annotation in the nested entities in the request. Services that support the contentID instance annotation MUST annotate the corresponding nested entities in the response when the return=representation preference is applied.

Instance annotation definition:

<Term Name=contentID Type=Edm.String>

    <Annotation Term="Core.Description" String=A unique identifier for nested entities within a request."/>

</Term>

Introduce a new capabilities annotation for deep inserts:

<Term Name="DeepInsertSupport" Type="Capabilities.DeepInsertSupportType" AppliesTo="EntityContainer">

  <Annotation Term="Core.Description" String=Deep Insert Support for the service"/>

</Term>

<ComplexType Name="DeepInsertSupportType">

  <Property Name="Supported" Type="Edm.Boolean" DefaultValue="true">

    <Annotation Term="Core.Description" String="Service supports deep inserts" />

  </Property>

  <Property Name="ContentIDSupported" Type="Edm.Boolean" DefaultValue=true>

    <Annotation Term="Core.Description" String="Service supports accepting and returning nested entities annotated with the contentID instance annotation." />

  </Property>

</ComplexType>

Matt Borges (SAP): <Term Name="BatchSupport" Type="Capabilities.BatchSupportType" AppliesTo="EntityContainer">

  <Annotation Term="Core.Description" String="Batch Support for the service"/>

</Term>

<ComplexType Name="BatchSupportType">

  <Property Name="Supported" Type="Edm.Boolean" DefaultValue="true">

    <Annotation Term="Core.Description" String="Service supports requests to $batch" />

  </Property>

  <Property Name="ContinueOnErrorSupported" Type="Edm.Boolean">

    <Annotation Term="Core.Description" String="Service supports the continue on error preference" />

  </Property>

  <Property Name="ReferencesInRequestBodiesSupported" Type="Edm.Boolean">

    <Annotation Term="Core.Description" String="Service supports Content-ID referencing in request bodies" />

  </Property>

  <Property Name="ReferencesAcrossChangeSetsSupported" Type="Edm.Boolean">

    <Annotation Term="Core.Description" String="Service supports Content-ID referencing across change sets" />

  </Property>

  <Property Name="EtagReferencesSupported" Type="Edm.Boolean">

    <Annotation Term="Core.Description" String="Service supports referencing Etags from previous requests" />

  </Property>

</ComplexType>

Matt Borges (SAP): I move to resolve ODATA-873 as proposed

Hubert Heijkers (IBM): I second

Mark Biamonte (Progress): I second

Ralf Handl (SAP): ODATA-873 is resolved as proposed

Ralf Handl (SAP): 2.ODATA-942 How should headers applied to a batch affect statements within a batch

Ralf Handl (SAP): Mark prepared proposal, will update issue, all to check until next week

Ralf Handl (SAP): Postponed until next meeting

Ralf Handl (SAP): 3.ODATA-950 Clarify what requests can be delta enabled

Ralf Handl (SAP): Link header specification: https://tools.ietf.org/html/rfc5988

Ralf Handl (SAP): Request types we want to delta-enable

Ralf Handl (SAP): Collections of entities

Ralf Handl (SAP): Singletons

Ralf Handl (SAP): Collections of complex type instances - use index as "weak identity" - careful consideration of index shifts due to insertions and deletions

Matt Borges (SAP): GET Customers(101)?$expand=Orders

Ralf Handl (SAP): "Raw" content - media resources, raw property values - using the Link header

Ralf Handl (SAP): Single entity

Ralf Handl (SAP): In theory any GET request

Ralf Handl (SAP): Hubert and Matt will prepare proposal, postpone issue until then

Ralf Handl (SAP): Revisit issue end of September

Ralf Handl (SAP): iii.Annotations

1.ODATA-760 Add to depth restrictions to Capabilities Vocabulary

Ralf Handl (SAP): Back to ODATA-950

Ralf Handl (SAP): No objections to open ODATA-950, is OPEN

Ralf Handl (SAP): ODATA-760 Add to depth restrictions to Capabilities Vocabulary

Ralf Handl (SAP): Services will likely have different limits in the number of levels of depth they support in queries. For example:

Filter on far navigation (e.g. Manager/Manager/Title eq Director )

Nested Any (e.g. Reports/any(Reports: Reports/any  )

Deep expansion 1:M (e.g. $expand=Reports, Reports/Reports)

All those filters are syntactically correct, but create undue server-side load, so services are likely to impose limits on the number of levels of depth for such expressions.

Is this something services should be able to report in Capabilities?

Ralf Handl (SAP): SAP Gateway implementation has limit on insertion - one level, e.g. Orders(42)/Items but not more than two segments

Ralf Handl (SAP): Mark: limit on $expand, only one level

Ralf Handl (SAP): ODATA-760 is OPEN

Ralf Handl (SAP): Hubert: service-wide restriction or specific to parts, e.g. entity sets

Ralf Handl (SAP): Postpone until we have a proposal

Ralf Handl (SAP): Mark will sketch a proposal

Ralf Handl (SAP): 2.ODATA-958 Capabilities: FilterRestrictions and SortRestrictions for navigation properties

Ralf Handl (SAP): <Term Name="FilterRestrictions" Type="Capabilities.FilterRestrictionsType" AppliesTo="EntitySet">

        <Annotation Term="Core.Description" String="Restrictions on $filter expressions" />

      </Term>

      <ComplexType Name="FilterRestrictionsType">

        <Property Name="Filterable" Type="Edm.Boolean" DefaultValue="true">

          <Annotation Term="Core.Description" String="$filter is supported" />

        </Property>

        <Property Name="RequiresFilter" Type="Edm.Boolean" DefaultValue="false">

          <Annotation Term="Core.Description" String="$filter is required" />

        </Property>

        <Property Name="RequiredProperties" Type="Collection(Edm.PropertyPath)" Nullable="false">

          <Annotation Term="Core.Description"

            String="These properties must be specified in the $filter clause (properties of derived types are not allowed here)" />

        </Property>

        <Property Name="NonFilterableProperties" Type="Collection(Edm.PropertyPath)" Nullable="false">

          <Annotation Term="Core.Description" String="These properties cannot be used in $filter expressions" />

        </Property>

        <Property Name="FilterExpressionRestrictions" Type="Collection(Capabilities.FilterExpressionRestrictionType)"

          Nullable="false"

          <Annotation Term="Core.Description" String="These properties only allow a subset of expressions" />

        </Property>

      </ComplexType>

Ralf Handl (SAP): Change type of NonFilterableProperties and NonSortableProperties to Collection(Edm.AnyPropertyPath) - new abstract type introduced in ODATA-516.

Ralf Handl (SAP): Gerald: make it explicit in term documentation that the NonFilterableProperties are actually path prefixes, not only complete paths, e.g. if a complex property is named it also excludes filtering on components

Ralf Handl (SAP): No objections to opening this issue, ODATA-516 is OPEN

Ralf Handl (SAP): Correction, ODATA-958 is OPEN

Hubert Heijkers (IBM): I move to resolve ODATA-958 as proposed

Stefan Hagen: second

Gerald Krause (SAP): I second

Ralf Handl (SAP): no objections, ODATA-958 is resolved as proposed

Ralf Handl (SAP): 3.ODATA-960 Absolute paths in annotations, e.g. capabilities depending on properties of a singleton

Ralf Handl (SAP): Extend Path syntax to allow absolute paths that start with a top-level model element (schema child).

Natural syntax would be a path starting with a forward slash.

Note: current "relative" paths can already start with a type-cast segment which is a qualified type name, so the / prefix or something similar is needed to distinguish "absolute" paths.

Ralf Handl (SAP): Example

<Annotations Target="My.Container/SalesOrders">

  <Annotation Term="Capabilities.InsertRestrictions">

    <Record>

      <PropertyValue Property="Insertable" Path="/My.Container/Me/Permissions/CanCreateOrders" />

    </Record>

  </Annotation>

</Annotations>

Ralf Handl (SAP): ODATA-960 is OPEN

Mark Biamonte (Progress): I move that OData-960 be resolved as proposed

Hubert Heijkers (IBM): I second

Ralf Handl (SAP): ODATA-960 is RESOLVED as proposed

Ralf Handl (SAP): iv.New Query Capabilities

1.ODATA-614 Allow $expand, $select, ... with POST/PATCH/PUT in combination with return=representation to specify the response shape

Ralf Handl (SAP): Last comment by Mike:

What happens if the service can't honor the $expand/$select -- does it still do the update? Does it still return results even if it can't honor the expand/select?

=>Operation should never fail based on these query options, but if the service returns data it MUST have the query options appropriately applied.

=>Need to define capability term for this..

Ralf Handl (SAP): Agreement on general direction

Ralf Handl (SAP): Doubts about usefulness of an additional capabilities annotation

Ralf Handl (SAP): Postpone until next meeting

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

a.Thursday August 11, 2016 during 6-10am PT  four hours

b.Thursday August 18, 2016 during 8-10am PT

c.Thursday September 08, 2016 during 8-10am PT

Ralf Handl (SAP): 7.AOB and wrap up [9:55am PT]

Stefan Hagen: bye

Ralf Handl (SAP): Meeting is adjourned

From: odata@lists.oasis-open.org [mailto:odata@lists.oasis-open.org] On Behalf Of Handl, Ralf
Sent: Mittwoch, 3. August 2016 14:26
To: odata@lists.oasis-open.org
Subject: [odata] Agenda for OData TC meeting on 2016-08-04

Here [1] is a draft agenda for the OData TC (Technical Committee) meeting scheduled on Thursday August 04, 2016 during 8-10am 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:00am PT]

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

2. Approve agenda [8:05am PT]

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

a. Minutes from July 28, 2016 TC meeting: https://www.oasis-open.org/apps/org/workgroup/odata/download.php/58620/latest/odata-meeting-139_on-20160728-minutes.html

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

a. Action items due

i. 0036 Register the OData headers and preferences with IANA (Ram)

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

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

i. Ripe for resolution

1. ODATA-923 $expand (or $include) for $metadata to include referenced schemas

ii. OData Protocol

1. ODATA-873 Define a default order for deep inserted entities in responses

2. ODATA-942 How should headers applied to a batch affect statements within a batch

3. ODATA-950 Clarify what requests can be delta enabled

iii. Annotations

1. ODATA-760 Add to depth restrictions to Capabilities Vocabulary

2. ODATA-958 Capabilities: FilterRestrictions and SortRestrictions for navigation properties

3. ODATA-960 Absolute paths in annotations, e.g. capabilities depending on properties of a singleton

iv. 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

4. ODATA-954 Key-As-Segment for multi-part keys

v. Set Operations

1. ODATA-836 Allow applying actions to a filtered collection of entities

vi. Enumerations

1. ODATA-874 Allow Edm.String as underlying type for enumeration types

2. ODATA-849 Add possibility for enumeration types to "extend" another enumeration type

3. ODATA-494 Define inheritance for enumeration types

vii. OData CSDL

1. ODATA-618 Allow using term names in positions that allow type names

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

3. ODATA-929 Nullable facet should default to false for collection types, rather than being unspecified

4. ODATA-935 Allow singletons to be members of an entity set

5. 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.

viii. OData JSON Format

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

2. ODATA-868 Describe HTTP encoding for streamed requests and responses

ix. Interfaces

1. ODATA-619 Attach action and function signatures to terms, i.e. make a term definition an interface definition

x. Waiting for refined proposal

1. ODATA-735 Enhance the CSDL for instance annotations

2. ODATA-811 Define propagation and (partial) overriding of annotations

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

4. ODATA-919 Specify the result type for each operation based on operator types

6. Next meetings [9:50am PT]

a. Thursday August 11, 2016 during 6-10am PT – four hours

b. Thursday August 18, 2016 during 8-10am PT

c. Thursday September 08, 2016 during 8-10am PT

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

[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

· https://www.oasis-open.org/committees/document.php?document_id=56024&wg_abbrev=odata

odata message