OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] Updated: (ODATA-334) Integrate conformance concept with careful consideration of versioning semantics (into protocol work product)


     [ http://tools.oasis-open.org/issues/browse/ODATA-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Drees updated ODATA-334:
-------------------------------

        Summary: Integrate conformance concept with careful consideration of versioning semantics (into protocol work product)  (was: Integrate conformance concept with careful consideration of versioing semantics (into protocol work product))
       Proposal: Integrate conformance concept with careful consideration of versioning semantics (into protocol work product)  (was: Integrate conformance concept with careful consideration of versioing semantics (into protocol work product))
    Description: 
There is a need for finding and documenting a well-weighted and working interplay of versioning and conformance levels (client and server). These dimensions are neither aligned nor orthogonal. The Service Conformance Level concept [Conformance Levels](https://www.oasis-open.org/committees/download.php/48595/OData%20Service%20Conformance%20Levels.docx)  and the latest [OData Core Part 1: Protocol, Version 4.0](https://www.oasis-open.org/committees/download.php/48604/odata-core-v4.0-wd01-part1-protocol-2013-03-20.doc)  are to be combined into a subsequent protocol work products conformance section in a way, that where applicable allows conformance levels represent fine-grained control abput each party in the communication MAY safely assume from the partner and where to further investigate.

Versions and conformance may appear as major and minor aspects of versioning from some viewpoints. Where this is so, we should clearly state and explain the interworking. Where it is not but unrelated (layered on top) we should equally explain and document this.

I undestand, that currently we plan to define one client related conformance level, namely 'the minimal requirements for an OData Client to be interoperable across OData services.' (everything 'more versatile' is ok, below is well not enough. Right?)

Further we segragate the server capabilities w.r.t conformance into three levels: 'Publishing', 'Service' and 'Full' (ordered by ascending versatility).

When it comes to versioning, the version should be negotiated on a connection (series of request-response-pairs) basis but should not depend upon attributes of the response (as I understood from discussion on the opendata.org mailing list???)

The server we describe as somehow "being version 4.0" and conforming to level "some-level" should send the min version his response needs to be interpreted, as all clients are assumed to be equal or better than minimal conformance :-)

If the client requested a version below the one needed for the response (may that happen?) the server will indicate this as an error somehow.

So client sends max version she understands, server answers with error xor min version <= max version(of clients request) response.

Does this crude collection help in seeding ammending the protocol with the content of the conformnace concept document and subsequent clean-up / rewrite of the relevant text?? I hope so.

Also maybe matrices depicting aspects currently described as per conformance level separate itemized listings in the concept document might be helfull formats (like eg. one line in such a table would be Support for /$count with empty cell in 'Publishing' column, 'S' (for SHOULD) in 'Service' and 'M' (for MUST) in 'Full' column.


  was:
There is a need for finding and documenting a well-weighted and working interplay of versioning and conformance levels (client and server). These dimensions are neither aligned nor orthogonal. The Service Conformance Level concept [Conformance Levels](https://www.oasis-open.org/committees/download.php/48595/OData%20Service%20Conformance%20Levels.docx)  and the latest [OData Core Part 1: Protocol, Version 4.0](https://www.oasis-open.org/committees/download.php/48604/odata-core-v4.0-wd01-part1-protocol-2013-03-20.doc)  are to be combined into a subsequent protocol work products conformance section in a way, that where applicable allows conformance levels represent fine-grained control abput each party in the communication MAY safely assume from the partner and where to further investigate.

I undestand, that currently we plan to define one client related conformance level, namely 'the minimal requirements for an OData Client to be interoperable across OData services.' (everything 'more versatile' is ok, below is well not enough. Right?)

Further we segragate the server capabilities w.r.t conformance into three levels: 'Publishing', 'Service' and 'Full' (ordered by ascending versatility).

When it comes to versioning, the version should be negotiated on a connection (series of request-response-pairs) basis but should not depend upon attributes of the response (as I understood from discussion on the opendata.org mailing list???)

The server we describe as somehow "being version 4.0" and conforming to level "some-level" should send the min version his response needs to be interpreted, as all clients are assumed to be equal or better than minimal conformance :-)

If the client requested a version below the one needed for the response (may that happen?) the server will indicate this as an error somehow.

So client sends max version she understands, server answers with error xor min version <= max version(of clients request) response.

Does this crude collection help in seeding ammending the protocol with the content of the conformnace concept document and subsequent clean-up / rewrite of the relevant text?? I hope so.

Also maybe matrices depicting aspects currently described as per conformance level separate itemized listings in the concept document might be helfull formats (like eg. one line in such a table would be Support for /$count with empty cell in 'Publishing' column, 'S' (for SHOULD) in 'Service' and 'M' (for MUST) in 'Full' column.



typos and an ammendment to description

> Integrate conformance concept with careful consideration of versioning semantics (into protocol work product)
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: ODATA-334
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-334
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData Protocol 
>    Affects Versions: V4.0_WD01
>            Reporter: Stefan Drees
>             Fix For: V4.0_WD01
>
>
> There is a need for finding and documenting a well-weighted and working interplay of versioning and conformance levels (client and server). These dimensions are neither aligned nor orthogonal. The Service Conformance Level concept [Conformance Levels](https://www.oasis-open.org/committees/download.php/48595/OData%20Service%20Conformance%20Levels.docx)  and the latest [OData Core Part 1: Protocol, Version 4.0](https://www.oasis-open.org/committees/download.php/48604/odata-core-v4.0-wd01-part1-protocol-2013-03-20.doc)  are to be combined into a subsequent protocol work products conformance section in a way, that where applicable allows conformance levels represent fine-grained control abput each party in the communication MAY safely assume from the partner and where to further investigate.
> Versions and conformance may appear as major and minor aspects of versioning from some viewpoints. Where this is so, we should clearly state and explain the interworking. Where it is not but unrelated (layered on top) we should equally explain and document this.
> I undestand, that currently we plan to define one client related conformance level, namely 'the minimal requirements for an OData Client to be interoperable across OData services.' (everything 'more versatile' is ok, below is well not enough. Right?)
> Further we segragate the server capabilities w.r.t conformance into three levels: 'Publishing', 'Service' and 'Full' (ordered by ascending versatility).
> When it comes to versioning, the version should be negotiated on a connection (series of request-response-pairs) basis but should not depend upon attributes of the response (as I understood from discussion on the opendata.org mailing list???)
> The server we describe as somehow "being version 4.0" and conforming to level "some-level" should send the min version his response needs to be interpreted, as all clients are assumed to be equal or better than minimal conformance :-)
> If the client requested a version below the one needed for the response (may that happen?) the server will indicate this as an error somehow.
> So client sends max version she understands, server answers with error xor min version <= max version(of clients request) response.
> Does this crude collection help in seeding ammending the protocol with the content of the conformnace concept document and subsequent clean-up / rewrite of the relevant text?? I hope so.
> Also maybe matrices depicting aspects currently described as per conformance level separate itemized listings in the concept document might be helfull formats (like eg. one line in such a table would be Support for /$count with empty cell in 'Publishing' column, 'S' (for SHOULD) in 'Service' and 'M' (for MUST) in 'Full' column.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]