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] (ODATA-787) Clarify how odata.Include-annotations preference affects odata.* markup


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

Michael Pizzo updated ODATA-787:
--------------------------------

    Environment: [Proposed]
       Proposal: 
Put in the JSON document:
-It's okay to use include-annotations to add additional odata annotations beyond those prescribed by the odata.metadata type parameter
-Services MUST not subtract from odata.metadata level.
-Services MUST always not exclude nextlink, delta link and count as appropriate

> 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
>         Environment: [Proposed]
>            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)


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