[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (ODATA-846) Add version 4.01
[ https://issues.oasis-open.org/browse/ODATA-846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Pizzo updated ODATA-846: -------------------------------- Proposal: 1) Define an OData-Versions annotation that specifies the OData version(s) supported by the service: <Term Name="ODataVersions" Type="Edm.String" AppliesTo="EntityContainer"> <Annotation Term="Core.Description" String="A space-separated list of supported versions of the OData Protocol." /> </Term> 2) For new 4.01 features, we should: a) define behavior/compatibility for 4.0 clients, and b) define vocabularies to test the presence of the new feature 3) The features required for a service to be 4.01 compliant should be minimal beyond 4.0 in order to allow services to incrementally opt into 4.01 Conformance Rules: Compliant 4.01 Services: -MUST return 4.0-compliant JSON payloads with OData-Version=4.0 header for clients specifying OData-MaxVersion=4.0 request header -MUST not omit the odata. prefix (ODATA-630) -MUST not omit the # prefix for @odata.type values (ODATA-561) -MUST support 4.0-compliant JSON request payloads with OData-Version=4.0 request header -MUST support property@odata.bind in PATCH, PUT, POST for 4.0 payloads (ODATA-666) -MUST support payloads that have the odata. prefix (ODATA-630) -MUST support odata.type values with the # prefix (ODATA-561) -MUST support 4.01-compliant request payloads with the OData-Version=4.01 request header -MUST support payloads that have or omit the odata. prefix (ODATA-630) -MUST support odata.type values with or without the # prefix (ODATA-561) -MUST support linking using "property":{"@odata.id":"url..."} instead of @odata.bind in PATCH, PUT, POST (ODATA-666) -MUST pay attention to @odata.etag annotations within payloads, if specified (ODATA-666) -MAY support 4.01 syntax regardless of version; does not necessitate a change in OData-Version of response -MUST not return new CSDL elements/attributes/values for existing elements/attributes if the client specifies OData-MaxVersion=4.0 -MUST NOT include referential constraints to complex types and navigation properties (ODATA-560) -MAY return new CSDL annotations regardless of the version; does not necessitate a change in OData-Version of response -MAY support 4.01 behavior, including returning 4.01 content and payloads, if the client does not specify the OData-MaxVersion=4.0 request header -MUST follow OData semantics or fail request for any 4.01 syntax or request payloads -MUST return 4.0 for the Edmx:Version attribute (we are not defining a new version of Edmx) -MUST return the numericValueException annotation instead of "INF", "-INF", and "NaN" property values in 4.01 responses -MUST reject a requests with an incompatible SchemaVersion header (if SchemaVersion is returned from $metadata) -SHOULD return the new ODataVersions annotation. MUST include 4.0 if 4.01 is included. -MUST support non-prefixed variants for supported headers, preference values, and format parameters (See OData-937) -MUST support omitting body when invoking action with no non-binding parameters (See OData-938) -MUST support omitting type prefix for enumeration and duration literals in URLs (See OData-834) -MUST support omitting namespaces for unambiguous functions/action (OData-812) -MUST support implicit aliasing of parameters (See ODATA-763) -MUST support invoking parameterless function imports with no parens (ODATA-664) -MUST return the AsyncResult header in the final response to an async request (ODATA-809) -MUST support eq/ne comparison to null for 0..1 nav props (ODATA-617) -MUST support casting strings to primitive types (ODATA 563) -MUST support the "in" operator (ODATA-556) -SHOULD support "divby" (ODATA-918) -SHOULD support negative indexes for substring function (ODATA-901) -SHOULD support a non-message format for final response of an async request (ODATA-809) -MAY support PUT against single entity with nested content (ODATA-9024) -MAY support DELETE/PUT to $ref of a collection-valued nav prop (ODATA-922) -MAY support the count of a filtered/searched collection in a common expression (ODATA-897) -MAY support deep update and deep insert operations (ODATA-666) -MAY allow $search for all collections (ODATA-888) -MAY support eq/ne structural comparison (ODATA-617) -MAY support POST to collections of complex/primitive types (ODATA-616) -MAY support PATH and DELETE with $filter (ODATA-615) -MAY allow PATCH to entity sets using the delta-response format (ODATA-613) Compliant 4.01 Clients: -MUST only send OData 4.0-compliant payloads to a services that don't advertise support for 4.01 or greater -MUST include the odata. prefix, as appropriate (ODATA-630) -MUST include the # prefix for @odata.type annotation values (ODATA-561) -MUST use appropriate syntax when sending a request body that specifies ODATA-VERSION=4.01 -MUST use "property":{"@odata.id":"url..."} instead of @odata.bind in PATCH, PUT, POST (ODATA-666) -MUST be prepared to receive any valid 4.01 CSDL -MUST support properties in derived types that overwrite property of base type (ODATA-894) -MUST support EDM.Untyped (ODATA-881) -MUST support extended edm:Path expression (ODATA-786) -MUST support Edm.AnyPath and Edm.AnyPropertyPath (ODATA-516) -MUST support referential constraints to complex types and navigation properties (ODATA-560) -MUST be prepared to receive any 4.0-compliant payloads (according to OData-Version request header) -MUST support payloads that include the odata. prefix (ODATA-630) -MUST support odata.type values with the # prefix (ODATA-561) -MUST support 4.01-compliant payloads (according to OData-Version request header) -MUST support payloads that omit (4.1) the odata. prefix (ODATA-630) -MUST support odata.type without (4.1) the # prefix (ODATA-561) -MUST support services that return contained entities inline for delta response (ODATA-876) -MUST support delta responses with no TargetId for a deleted link in a 0..1 relationship (ODATA-814) -SHOULD use capabilities to determine if a 4.01 feature is supported but MAY attempt syntax (and receive either 501 not implemented or 400 bad request) Areas of the spec that talk about versioning: Part 1: Protocol - Section 5.1 Protocol Versioning - Chapter 12 Security Considerations Part 3: CSDL - Section 3.1.1 Attribute Version - Sections 2.1 and 2.2 XML Namespaces JSON Format - Chapter 21 Security Considerations was: 1) Define an OData-Versions annotation that specifies the OData version(s) supported by the service: <Term Name="ODataVersions" Type="Edm.String" AppliesTo="EntityContainer"> <Annotation Term="Core.Description" String="A space-separated list of supported versions of the OData Protocol." /> </Term> 2) For new 4.01 features, we should: a) define behavior/compatibility for 4.0 clients, and b) define vocabularies to test the presence of the new feature 3) The features required for a service to be 4.01 compliant should be minimal beyond 4.0 in order to allow services to incrementally opt into 4.01 Conformance Rules: Compliant 4.01 Services: -MUST return 4.0-compliant JSON payloads with OData-Version=4.0 header for clients specifying OData-MaxVersion=4.0 request header -MUST support 4.0-compliant JSON request payloads with OData-Version=4.0 request header -MAY support 4.01 syntax regardless of version; does not necessitate a change in OData-Version of response -MUST not return new CSDL elements/attributes/values for existing elements/attributes if the client specifies OData-MaxVersion=4.0 -MAY return new CSDL annotations regardless of the version; does not necessitate a change in OData-Version of response -MAY support 4.01 behavior, including returning 4.01 content and payloads, if the client does not specify the OData-MaxVersion=4.0 request header -MUST follow OData semantics for any 4.01 syntax -MUST return 4.0 for the Edmx:Version attribute (we are not defining a new version of Edmx) -SHOULD return the new ODataVersions annotation. MUST include 4.0 if 4.01 is included. Compliant 4.01 Clients: -MUST only send payloads containing 4.01 structure to a service that advertises support for 4.01 or greater -SHOULD use capabilities to determine if a 4.01 feature is supported but MAY attempt syntax (and receive either 501 not implemented or 400 bad request) Areas of the spec that talk about versioning: Part 1: Protocol - Section 5.1 Protocol Versioning - Chapter 12 Security Considerations Part 3: CSDL - Section 3.1.1 Attribute Version - Sections 2.1 and 2.2 XML Namespaces JSON Format - Chapter 21 Security Considerations > Add version 4.01 > ---------------- > > Key: ODATA-846 > URL: https://issues.oasis-open.org/browse/ODATA-846 > Project: OASIS Open Data Protocol (OData) TC > Issue Type: Bug > Components: OData Protocol > Affects Versions: V4.0_ERRATA02 > Reporter: Ralf Handl > Assignee: Michael Pizzo > Fix For: V4.01_WD01 > > > This issue tracks all places that need to reflect the new version number in the prose text. > We will also use this issue to track how we do version negotiation between a 4.0 and a 4.01 client and service. -- This message was sent by Atlassian JIRA (v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]