[OASIS Issue Tracker] Updated: (ODATA-417) Define content negotiation and default format for paths ending in /$value, /$count, /$metadata and /$batch

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

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

Michael Pizzo updated ODATA-417:
--------------------------------

    Proposal: 
Content negotiation with Accept header and $format is allowed for paths ending in /$value.

Content negotiation for paths in ending in /$count is not allowed, the result is always text/plain

Content negotiation for /$batch is not allowed, the result is always multipart/mixed.

Content negotiation for /$metadata is allowed, but the media type application/json and application/atom and their sub-types and parameterized variants are reserved for future versions of this specification.



  was:
Content negotiation with Accept header and $format is allowed for paths ending in /$value.

Content negotiation for paths in ending in /$count is not allowed, the result is always text/plain

Content negotiation for /$batch is not allowed, the result is always multipart/mixed.

Content negotiation for /$metadata is allowed, but the media types application/atom+xml and application/json and its sub-types and parameterized variants are reserved for future versions of this specification.




> Define content negotiation and default format for paths ending in /$value, /$count, /$metadata and /$batch
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: ODATA-417
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-417
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: OData ATOM Format , OData JSON Format, OData URL Conventions 
>    Affects Versions: V4.0_CSD01
>         Environment: [Proposed]
>            Reporter: Ralf Handl
>             Fix For: V4.0_CSD02
>
>
> With ODATA-390 we introduced GML and GeoJSON representations for primitive properties of Geo types.
> This raises the question what format requests to the "raw" value of a Geo property return:
> GET ~/Customers(1)/Address/GeoLocation/$value
> This could be
> - the "unwrapped" GML or GeoJSON value
> - the WKT plain text value
> - ...
> Allowing content negotiation for /$value paths would solve this elegantly and works also well for canonical URLs to media resources.

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