Room information was updated by: Stefan Hagen
Please register your attendance at: https://www.oasis-open.org/apps/org/workgroup/odata/event.php?event_id=41475
Agenda draft URL of email: https://www.oasis-open.org/apps/org/workgroup/odata/email/archives/201608/msg00036.html
Stefan Hagen: RegInfo: Voting Members: 1 of 12 (8%) (used for quorum calculation)
Ralf Handl (SAP): Sorry, have dial-in problems
Stefan Hagen: RegInfo: Voting Members: 7 of 12 (58%) (used for quorum calculation)
Stefan Hagen: @Ralf: I will have to commute now, so I will have to try to call in later, will try to follow the chat..
Room Information:
Please register your attendance at: https://www.oasis-open.org/apps/org/workgroup/odata/event.php?event_id=41475
Agenda draft URL of email: https://www.oasis-open.org/apps/org/workgroup/odata/email/archives/201608/msg00036.html
Ralf Handl (SAP): Agenda is approved
Ralf Handl (SAP): 3.Approve minutes from previous meeting(s) [8:10am PT]
a.Minutes from August 04, 2016 TC meeting: https://www.oasis-open.org/committees/download.php/58662/odata-meeting-140_on-20160804-minutes.html
Ralf Handl (SAP): Minutes are approved
Ralf Handl (SAP): 6.V4.01 [7: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
anonymous morphed into Matt Borges (SAP)
Mike Pizzo: Mark brought up use case of getting data and metadata in single request.
Mike Pizzo: If we have an easy way to get the metadata for a particular response, the client could batch that request with the request for the data using standard batch mechanisms.
Mike Pizzo: Ramesh asked about the format of the response. It would be a single response containing multiple <schema> elements, each representing an included namespace necessary to understand the response. The service would be allowed to return, in each namespace, only those types necessary to understand the response.
Mike Pizzo: An alternative would be to return the full namespaces in line and require the service to factor the metadata into separate namespaces. This would not work for V2/V3, but would work for V4. Still relies on a factoring of the metadata that may be grouped in different sizes for other reasons.
Ralf Handl (SAP): ii.OData Protocol
1.ODATA-757 Add an OData specific header If-Metadata-Match
Matt Borges (SAP): I move we close ODATA-757 without action
Mark Biamonte (Progress): I second
Ralf Handl (SAP): ODATA-757 is CLOSED without action
Ralf Handl (SAP): 1.ODATA-942 How should headers applied to a batch affect statements within a batch
Mark Biamonte (Progress): The only header fields that have defined meaning for body parts are
those the names of which begin with "Content-". All other header
fields may be ignored in body parts. Although they should generally
be retained if at all possible, they may be discarded by gateways if
necessary. Such other fields are permitted to appear in body parts
but must not be depended on. "X-" fields may be created for
experimental or private purposes, with the recognition that the
information they contain may be lost at some gateways.
Mark Biamonte (Progress): The following is a proposal for the use of headers in batch requests and responses.
Common Headers
===============
Content-Type - Each request in the batch must have a content type header as per section 11.7
Content-Encoding - Value on requests in batch overrides the batch value
Content-Language - Value on requests in batch overrides the batch value
Content-Length - Value on requests in batch specify the length of that request
OData-Version - Applies to the overall batch only. Ignored on requests in batch
Request Headers
===============
Accept - In theory we could have Accept headers on requests in the batch override the Accept header of the batch. In practice, is that a reasonable use case? It seems unusual that one request in the batch would request Atom format and another request in the batch would request JSON format.
Accept-Charset - Similar to Accept header is it a resonable use case for the charset and language to differ from request to request? I could see that this might be more probable than wanting to mix Atom and JSON formats.
Accept-Language - Same comment as Accept-Charset
If-Match- Value on requests in batch overrides apply to that request. If-Match on the overall batch does not make sense. If the If-Match header is specified on the overall batch is that an error or is it ignored?
If-None-Match - Value on requests in batch overrides apply to that request. If-None-Match on the overall batch does not make sense. If the If-Match header is specified on the overall batch is that an error or is it ignored?
OData-Isolation - Applies to the overal batch only. Ignored on requests in the batch (per section 8.2.6)
OData-MaxVersion - Applies to the overal batch only. Ignored on requests in the batch
Prefer:odata.allow-entityreferences - Value on requests in batch overrides the batch value
Prefer:odata.callback - In theory we could allow a callback per request in the batch, but I think it makes more sense if it applies to the batch as a whole.
Prefer:odata.continue-on-error - Applies to the overall batch only. Ignored on requests in the batch
Prefer:odata.include-annotations - Value on requests in batch overrides the batch value
Prefer:odata.maxpagesize- Assuming responses in a batch can return Next Links, the value on requests in batch overrides the batch value
Prefer:odata.track-changes - Assuming responses in a batch can return Delta Links, the value on requests in batch overrides the batch value
Prefer:return - Value on requests in batch overrides the batch value
Prefer:respond-async - Applies to the overall batch only. Ignored on requests in the batch (per section 8.2.8.
Prefer:wait - In general I think this would apply to the overall batch. However I could see where you might what to specify a timeout on an individual request in the batch. If a request timed out the odata.continue-on-error preference would dictate whether the batch fails or processing continues. The batch to either fail or return an async-repsonse depending on whether the responde-async preference is specified after the wait time specified for the overall batch as expired.
Schema-Version (OData 4.01) - Applies to the overall batch only. Ignored on requests in the batch.
Response Headers
=================
ETag - Can be applied to responses in a batch response. I don't think it makes sense to apply this to the overall batch response.
Location - Can be applied to responses in a batch response. I don't think it makes sense to apply this to the overall batch response
OData-EntityId - Can be applied to responses in a batch response. I don't think it makes sense to apply this to the overall batch response
Preference-Applied - Can be applied to responses in a batch response and also the overal batch
Retry-After- Applies to the overal batch response only.
Mike Pizzo: Question: is it really possible to change the content-encoding within a batch? Would processors of the overall payload need to know how subsections are encoded?
Mike Pizzo: Mark will investigate further, but the text for multi-part mime it seems to imply that the content- headers can vary on individual sections.
Mike Pizzo: Propose to move ahead with allowing as proposed, and revisit if Mark's research suggests an issue.
Mike Pizzo: Long discussion on include-annotations. We could define merge semantics, but it could be confusing. Much simpler just to override. Doesn't seem particularly burdensome for client to (re)specify entire set.
Stefan Hagen1 morphed into Stefan Hagen
Mike Pizzo: Revised proposal after walking through:
Common Headers
===============
Content-Type - Each request in the batch must have a content type header as per section 11.7
Content-Encoding - Value on requests in batch overrides the batch value
Content-Language - Value on requests in batch overrides the batch value
Content-Length - Value on requests in batch specify the length of that request
OData-Version - Value on requests in batch overrides the batch value. Typically wouldn't vary from request to request.
Request Headers
===============
Accept - Value on requests in batch overrides the batch value
Accept-Charset - Value on requests in batch overrides the batch value
Accept-Language - Value on requests in batch overrides the batch value
If-Match - Value on requests in batch overrides apply to that request. If-Match on the overall batch does not make sense. MUST NOT specify on the overall batch
If-None-Match - Value on requests in batch overrides apply to that request. If-None-Match on the overall batch does not make sense. MUST NOT specify on the overall batch.
OData-Isolation - Applies to the overal batch only. Ignored on requests in the batch (per section 8.2.6)
OData-MaxVersion - Value on requests in batch overrides the batch value.
Prefer:odata.allow-entityreferences - Value on requests in batch overrides the batch value
Prefer:odata.callback - Async on batch level; track-changes at request level.
Prefer:odata.continue-on-error - Applies to the overall batch only. MUST NOT be specified on requests in the batch
Prefer:odata.include-annotations - Value on requests in batch overrides the batch value
Prefer:odata.maxpagesize - SHOULD NOT be specified on batch
Prefer:odata.track-changes - SHOULD NOT be specified on batch
Prefer:return - SHOULD NOT be specified on batch
Prefer:respond-async - Applies to the overall batch only. SHOULD NOT be specified (and is ignored) on requests in the batch (per section 8.2.8.
Prefer:wait - On batch, applies to overall batch. On statement applies to individual
Mike Pizzo: Updated:
The following is a proposal for the use of headers in batch requests and responses.
Common Headers
===============
Content-Type - Each request in the batch must have a content type header as per section 11.7
Content-Encoding - Value on requests in batch overrides the batch value
Content-Language - Value on requests in batch overrides the batch value
Content-Length - Value on requests in batch specify the length of that request
OData-Version - Value on requests in batch overrides the batch value. Typically wouldn't vary from request to request.
Request Headers
===============
Accept - Value on requests in batch overrides the batch value
Accept-Charset - Value on requests in batch overrides the batch value
Accept-Language - Value on requests in batch overrides the batch value
If-Match - MUST NOT specify on the overall batch
If-None-Match - MUST NOT specify on the overall batch.
OData-Isolation - Applies to the overal batch only. Ignored on requests in the batch (per section 8.2.6)
OData-MaxVersion - Value on requests in batch overrides the batch value.
Prefer:odata.allow-entityreferences - Value on requests in batch overrides the batch value
Prefer:odata.callback - Async on batch level; track-changes at request level.
Prefer:odata.continue-on-error - MUST NOT be specified on requests in the batch
Prefer:odata.include-annotations - Value on requests in batch overrides the batch value
Prefer:odata.maxpagesize - SHOULD NOT be specified on batch
Prefer:odata.track-changes - SHOULD NOT be specified on batch
Prefer:return - SHOULD NOT be specified on batch
Prefer:respond-async - SHOULD NOT be specified (and is ignored) on requests in the batch (per section 8.2.8.
Prefer:wait - On batch, applies to overall batch. On statement applies to individual statement. This is the only header that should be used on a changeset.
Schema-Version (OData 4.01) - Value on requests in batch overrides the batch value
Response Headers
=================
ETag - Can be applied to responses in a batch response. SHOULD NOT be returned for batch.
Location - Can be applied to responses in a batch response. SHOLD NOT be returned for batch.
OData-EntityId - Can be applied to responses in a batch response. SHOULD NOT be returned for batch.
Preference-Applied - Can be applied to responses in a batch response and also the overal batch
Retry-After- Applies to the overal batch response only.
Hubert Heijkers: I move to resolve ODATA-942 as per the amended proposal above.
Mark Biamonte (Progress): I second
Ralf Handl (SAP): ODATA-942 is RESOLVED
Ralf Handl (SAP): 3.ODATA-950 Clarify what requests can be delta enabled
Ralf Handl (SAP): 4.ODATA-956 Do we need to add SchemaVersion to ContextURL?
Ralf Handl (SAP): A service MAY return the schemaVersion annotation as an instance annotation to specify the version of the schema the response was generated from. For streamed JSON this annotation, if present, MUST immediately follow the context property.
If a service returns a payload whose schema is not compatible with the "unversioned" schema, it MUST include the schemaVersion instance annotation in the payload.
Mike Pizzo: How does schemaversion work, in general, with federated systems? Do we need to specify different schemaversions for different context urls within a payload? Do we need to be able to annotate include statements in metadata with schemaversion? Do we need a way to specify a schema version as part of an expand?
Mike Pizzo: If we specify as part of the include, then we shouldn't need to specify as part of expand and only need one per response.
Mike Pizzo: Added to proposal: ALSO, support the schemaVersion annotation as a child of the <References> element.
Mike Pizzo: Added to proposal: schemaVersion MAY be included in embedded contextURLs or in odata.type annotations with full URLs.
Mike Pizzo: Updated proposal:
A service MAY return the schemaVersion annotation as an instance annotation to specify the version of the schema the response was generated from. For streamed JSON this annotation, if present, MUST immediately follow the context property.
schemaVersion MAY be included in embedded contextURLs or in odata.type annotations with full URLs.
If a service returns a payload whose schema is not compatible with the "unversioned" schema, it MUST include the schemaVersion instance annotations, as appropriate, in the payload.
ALSO, support the schemaVersion annotation as a child of the <References> element
Ralf Handl (SAP): ODATA-956 is OPEN
Mike Pizzo: I move we resolve ODATA-956 as proposed.
Hubert Heijkers: I second
Ralf Handl (SAP): ODATA-956 is RESOLVED as proposed
Ralf Handl (SAP): 1.ODATA-957 Do we impose a format for SchemaVersion?
Ralf Handl (SAP): ODATA-957 is OPEN
Mike Pizzo: I move we resolve ODATA-957 as proposed, clarifying that it is up to the service to define the format for the schemaversion.
Hubert Heijkers: I second
Ralf Handl (SAP): ODATA-957 is RESOLVED as proposed
Ralf Handl (SAP): 1.ODATA-961 10.10 Projected Expanded Entity - be more explicit in combined $select/$expand cases
Ralf Handl (SAP): 10.9 Collection of Projected Expanded Entities
Context URL template:
{context-url}#{entity-set}{/type-name}{select-list}
{context-url}#Collection({type-name}){select-list}
If a navigation property is explicitly selected, the parenthesized comma-separated list of properties includes the name of the selected navigation property with no parenthesis. If a $expand contains a nested $select, the navigation property appears suffixed with the parenthesized comma-separated list of properties selected (or expanded, containing a $select) from the related entities. Additionally, if the expansion is recursive for nested children, a plus sign (+) is infixed between the navigation property name and the list of properties.
Example 20: resource URL and corresponding context URL
http://host/service/Customers$select=Name&$expand=Address/Country
http://host/service/$metadata#Customers(Name,Address/Country)
Example 21: resource URL and corresponding context URL
http://host/service/Employees/Sales.Manager?$select=DirectReports
&$expand=DirectReports($select=FirstName,LastName;$levels=4)
http://host/service/$metadata
#Employees/Sales.Manager(DirectReports,
DirectReports+(FirstName,LastName))
10.10 Projected Expanded Entity
Context URL template:
{context-url}#{entity-set}{/type-name}{select-list}/$entity
{context-url}#{singleton}{select-list}
{context-url}#{type-name}{select-list}
If a single entity is expanded and projected (or contains a $expand with a $select expand option), the parenthesized comma-separated list of selected properties includes the name of the expanded navigation properties containing a nested $select, each suffixed with the parenthesized comma-separated list of properties selected (or expanded with a nested $select) from the related entities.
Example 22: resource URL and corresponding context URL
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
Mike Pizzo: Current rules:
if nav prop is in select, appears without parens.
if nav prop is in expand with no select, expand, or recursion, doesn't appear in the context url.
If nav prop is in expand with recursion, it's followed by a +
If nav prop is in expand with select list (or expand with select) then it's followed by parens (following the +, if present)
If both, both appear
Mike Pizzo: Consider: for 4.01, should we include expanded properties in the context url to better describe the payload? This would be useful, for instance, in using the context url to request the subset of required metadata.
Mike Pizzo: If you are able to omit nulls for expanded navigation properties, then we need to include the expanded nav prop in the context url.
Mike Pizzo: (to differentiate null from non expanded)
Ralf Handl (SAP): Refers to ODATA-818 - Omit properties whose value is null or the $metadata-defined default value
Ralf Handl (SAP): navpropertyname()
Ralf Handl (SAP): ODATA-961 is OPEN
Mike Pizzo: updated proposal:
Clarify text of 10.9 --
if nav prop is in select, appears without parens.
if nav prop is in expand with no select, expand, or recursion MAY NOT appear in the context url for 4.0, MUST appear for 4.01 (with empty parens if no nested select).
If nav prop is in expand with recursion, it's followed by a +
If nav prop is in expand with select list (or expand with select) then it's followed by parens (following the +, if present)
If both, both appear
Make sure 10.10 is consistent with clarified wording from 10.9.
Ralf Handl (SAP): navprop - in $select
Ralf Handl (SAP): navprop() - in $expand
Ralf Handl (SAP): navprop+() - in $expand with $levels
Ralf Handl (SAP): navprop(prop,prop2,...) - in $expand with nested $select
Ralf Handl (SAP): navprop+(prop,prop2,...) - in $expand with nested $select and $levels
Hubert Heijkers: I move to resolve ODATA-961 as per the updated proposal
Stefan Hagen: I second
Ralf Handl (SAP): ODATA-961 is resolved as proposed
Ralf Handl (SAP): iii.Annotations
1.ODATA-760 Add to depth restrictions to Capabilities Vocabulary
Ralf Handl (SAP): Postponed
Ralf Handl (SAP): 2.ODATA-811 Define propagation and (partial) overriding of annotations
Ralf Handl (SAP): - Annotations are applied wherever the annotated model element (e.g. type) is used.
- Annotations are propagated along inheritance hierarchies.
- Annotations defined at a derived type take precedence over the same annotation defined at the base type.
- Annotations defined directly at a model element that uses/references another model element take precedence over the same annotation defined at the used/referenced model element.
- "Take precedence" means replace (PUT) semantics, not merge (PATCH) semantics as this is easier for the client. This applies to all types of annotations: primitive, structured, collection-valued.
Terms that apply to a model construct implicitly apply to model constructs using the "applicable" construct, e.g. AppliesTo="EntityType" implies AppliesTo="Singleton EntitySet NavigationProperty Parameter".
Annotations on model constructs propagate to all places where the model construct can be used, and can be overridden at the using construct, with replace (PUT) semantics for all types annotations.
Annotations on structured types and their properties also propagate down from the base type to the derived types, and can be overridden at the derived type or its properties with replace (PUT) semantics for all types of annotations.
Consumers (client libraries) interested in annotations for a model element have to inspect referenced model constructs, and for structured types the base type(s) to determine the effective annotation value for this model element.
If annotations reference other annotations via the AnnotationPath construct, the search for the effective annotation value restarts at the model element the consumer is interested in. Example: base type has annotation that references other annotation. This other annotation is overridden on a derived type. The annotation consumer interested in the derived type has to use the referenced annotation value on the derived type.
Ralf Handl (SAP): Mike is concerned about blanketly propagating annotations along "uses"
Mike Pizzo: For applying annotations to different model elements; leave it up to the definition of the annotation to specify how the annotation on one element (i.e., a property) relates to the same annotation on a related element (i.e., the type containing the property)
Ralf Handl (SAP): 7.Next meetings [9:50am PT]
a.Thursday August 18, 2016 during 8-10am PT
b.Thursday September 08, 2016 during 8-10am PT
Ralf Handl (SAP): 8.AOB and wrap up [9:55am PT]
Mike Pizzo: {
"@odata.type":"#Northwind.Manager",
"FirstName" : "Patricia",
"DirectReports@odata.contextUrl" : "#Employees(1)/DirectReports/$delta",
"DirectReports": [
{
"@odata.context":"#Employees/$deletedEntity",
"id":"Employees(3)",
"reason":"deleted"
},
{
"@odata.context":"#Employees/$deletedLink",
"source":"Employees(1)",
"relationship":"DirectReports",
"target":"Employees(4)"
},
{
"@odata.context":"#Employees(1)/$link",
"source":"Employees(1)",
"relationship":"DirectReports",
"target":"Employees(5)"
},
{
"@odata.context":"#Employees/DirectReports/$entity",
"FirstName": "Suzanne",
"LastName": "Brown"
}
]
}
Stefan Hagen: Note the tombstone:
Stefan Hagen: {
"@odata.context":"#Employees/$deletedEntity",
"id":"Employees(3)",
"reason":"deleted"
},
Stefan Hagen: (focus by Mike)
Stefan Hagen: This is documented in PS-964
Ralf Handl (SAP): Meeting is adjourned
From: odata@lists.oasis-open.org [mailto:odata@lists.oasis-open.org]
On Behalf Of Handl, Ralf
Sent: Dienstag, 9. August 2016 13:55
To: odata@lists.oasis-open.org
Subject: [odata] Agenda for OData TC meeting on 2016-08-11
Here [1] is a draft agenda for the OData TC (Technical Committee) meeting
scheduled on
Thursday August 11, 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 [6:00am PT]
a.
Self-registration link:
https://www.oasis-open.org/apps/org/workgroup/odata/event.php?event_id=41475
2.
Approve agenda [6:05am PT]
3.
Approve minutes from previous meeting(s) [8:10am PT]
a.
Minutes from August 04, 2016 TC meeting:
https://www.oasis-open.org/committees/download.php/58662/odata-meeting-140_on-20160804-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 Jeyaraman)
5.
JSON Format for CSDL [6:20am PT]
a.
Document Walkthrough
b.
Way forward
i. Publish “as is” as CSD02?
6.
V4.01 [7: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-757
Add an OData specific header If-Metadata-Match
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
4.
ODATA-956
Do we need to add SchemaVersion to ContextURL?
5.
ODATA-957
Do we impose a format for SchemaVersion?
6.
ODATA-961
10.10 Projected Expanded Entity - be more explicit in combined $select/$expand cases
iii. Annotations
1.
ODATA-760
Add to depth restrictions to Capabilities Vocabulary
2.
ODATA-811
Define propagation and (partial) overriding of annotations
3.
ODATA-817 Add client-side
function odata.matchesRegularExpression
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-953
Consider deprecating structural casting
5.
ODATA-954
Key-As-Segment for multi-part keys
6.
ODATA-963
Make query options case insensitivite
v. Set Operations
1.
ODATA-836 Allow applying
actions to a filtered collection of entities
vi. Enumerations
1.
ODATA-494
Define inheritance for enumeration types
2.
ODATA-849
Add possibility for enumeration types to "extend" another enumeration type
3.
ODATA-874
Allow Edm.String as underlying type 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-884
Add term ErrorCodes to describe possible codes in error messages (public comment c201510e00019)
3.
ODATA-919
Specify the result type for each operation based on operator types
7.
Next meetings [9:50am PT]
a.
Thursday August 18, 2016 during 8-10am PT
b.
Thursday September 08, 2016 during 8-10am PT
8.
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