[OASIS Issue Tracker] Updated: (ODATA-159) Handling inline attachments in requests/responses

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

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

Michael Pizzo updated ODATA-159:
--------------------------------

       Proposal: Add back /$value convention for MLEs in order to facilitate scenarios where it is advantageous for clients to generate through convention, rather than retrieve, the URL. Note that, like all path conventions, this would be a SHOULD rather than a MUST, and servers MAY support through a redirect (in which case you'd still have to make a separate request, but that's up to the server to optimize or not).  (was: 1. Media Entities can contain content INLINE
2. Or OData can support multipart message format with the first part having the original request/response payload in atom/json formats and rest of the parts having attachments as dealt in case of HTTP multipart attachments.)
    Environment: [Proposed]
    Description: 
The only way of dealing with attachments (streams) as per the current OData spec seems to be using Media Entities or Named Stream Properties, where a media link is provided to download the attachment. Is there a way to get properties and attachments in one call?

Original proposal:
1. Media Entities can contain content INLINE
2. Or OData can support multipart message format with the first part having the original request/response payload in atom/json formats and rest of the parts having attachments as dealt in case of HTTP multipart attachments.

  was:
The only way of dealing with attachments (streams) as per the current OData spec seems to be using Media Entities or Named Stream Properties, where a media link is provided to download the attachment. Is there a way to get properties and attachments in one call?



Yes, ODATA-131 just removed the convention; Services advertise the URL in the payload, and the service is still free to use /$value or any other convention.

That said, I'm okay adding back the convention to support this scenario.

> Handling inline attachments in requests/responses
> -------------------------------------------------
>
>                 Key: ODATA-159
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-159
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: New Feature
>          Components: OData Protocol 
>         Environment: [Proposed]
>            Reporter: Anila Kumar GVN
>
> The only way of dealing with attachments (streams) as per the current OData spec seems to be using Media Entities or Named Stream Properties, where a media link is provided to download the attachment. Is there a way to get properties and attachments in one call?
> Original proposal:
> 1. Media Entities can contain content INLINE
> 2. Or OData can support multipart message format with the first part having the original request/response payload in atom/json formats and rest of the parts having attachments as dealt in case of HTTP multipart attachments.

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