[OASIS Issue Tracker] (ODATA-787) Clarify how odata.Include-annotations preference affects odata.* markup

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

    [ https://issues.oasis-open.org/browse/ODATA-787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59147#comment-59147 ] 

Michael Pizzo commented on ODATA-787:
-------------------------------------

From discussion:
-We could define an alternate preference, odata.include-metadata as a general way to request certain metadata be omitted (regardless of format).
-In this case we would probably want to explicitly say that odata.* annotations would be ignored in include-annotations, but that might seem a little strange for the JSON format.
-The question is really whether we optimize for the JSON format, or try to anticipate potential future formats?

Consensus seems to be to optimize for existing format by allowing this inclusion of additional odata annotations beyond those prescribed by the odata.metadata media type parameter..

This would be ignored by formats that don't represent this control information as annotations


> Clarify how odata.Include-annotations preference affects odata.* markup
> -----------------------------------------------------------------------
>
>                 Key: ODATA-787
>                 URL: https://issues.oasis-open.org/browse/ODATA-787
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: OData JSON Format
>    Affects Versions: V4.0_ERRATA02
>            Reporter: Michael Pizzo
>             Fix For: V4.0_ERRATA03
>
>
> In the JSON format we use annotations in the OData namespace in order to convey certain control information necessary for the client to understand the response. In the ATOM format this information was conveyed through other means (for example, using the <id> element).
> So it's unclear if, or how, the odata.include-annotations preference affects the control information that happens to be conveyed through the same annotation mechanism in the JSON format, and it's relationship to the odata.metadata media type parameters.
> The odata.metadata media type parameter is not very granular, and there are certainly cases where it would be nice to say "I want minimal plus type information" or "I want minimal plus navigation links", so it's tempting to say that you can additively request additional odata annotations beyond the specified metadata level. but:
> 1) This would be specific to format(s) that encoded the odata control information as annotations.
> 2) Would we ever do subtractive? Could a service request not to get ids (even if they didn't follow convention), or type information (even for derived types), or next links (even for paging)? What would client libraries or apps do, that assume absence of annotations in these cases has meaning (like the missing information follows convention, or the result is not paged).



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)