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-538) Clarify treatment of odata.type with derived types and odata.context for delta responses for odata.metadata=none


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

Michael Pizzo updated ODATA-538:
--------------------------------

    Proposal: 
Change the description of JSON format section 3.1.3 "odata.metadata=none" to state explicitly:

odata.metadata=none cannot be used in delta requests.

Change section on odata.type to clarify that type MUST be included in minimal or full metadata for the listed conditions.


  was:
Change the description of JSON format section 3.1.3 "odata.metadata=none" to state explicitly:

odata.type MUST be present for instances of types derived from the declared type even for odata.metadata=none

odata.context MUST be present for deleted entities, deleted links, and added links even for odata.metadata=none

Rationale: if clients know the concrete type per instance and the complete change history out-of-band, why would they use OData at all?


Updated proposal.

We initially said, for odata.metadata=none:
"Within a delta response, the odata.context URL MUST also be included for any deleted entries, added or deleted links, or entities whose set cannot be determined from the root context URL."

We then decided to simplify the rule to say that odata.metadata was not supported for delta responses.

odata.type is not returned in metadata=none. metadata=none is really for the case where the client just wants to paint the data on the screen as a generic json payload. they don't want/need type information and would complain if it was there. The only annotations added are those explicitly requested (odata.count) and those whose omission would lead to an incomplete response (odata.nextlink).


> Clarify treatment of odata.type with derived types and odata.context for delta responses for odata.metadata=none
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: ODATA-538
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-538
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData JSON Format
>    Affects Versions: V4.0_CS01
>         Environment: [Proposed]
>            Reporter: Evan Ireland
>             Fix For: V4.0_CSD03
>
>
> Suppose a service supports the addressing conventions (so a client would be able to formulate read/edit links from entity set names and key properties), and the client, being meta-data aware, wants to receive a large set of results (of declared type A, with possible subtype B) that is fairly compactly encoded. By metadata-aware, that means the client has already fetched the meta-data document.
> Now the client will still need to receive odata.type for any entities of subtype B, as in the general case this cannot be determined from the returned properties (unless or more of the returned properties can be used as proxy type marker).
> The difficulty here is that such a client does not generally need to receive the context URL. And in the general case, odata.context URLs are going to be quite a bit larger than the odata.type, similar to the metadata uri in pre-V4 OData. For example, with this service:
>     https://sapes1.sapdevcenter.com/sap/opu/odata/IWFND/RMTSAMPLEFLIGHT/BookingCollection
> the metadata uri can chew up nearly one third of the total JSON encoding. The client then must receive and parse a lot of information it does not need (GZIP can help with the network size of bloated context URLs, but they still need to be parsed which can chew up valuable CPU, especially on mobile devices).
> There may be cases where a V4 context URI are somewhat more concise than a pre-V4 metadata uri, but odata.context is still generally "bloated" in comparison to odata.type.
> And none of the odata.metadata options are suitable to express the client requirements.
> (a) odata.metadata=minimal: the odata.type is not required to be present, and the odata.context URLmust be included in the response, even though the client does not need it
> (b) odata.metadata=full: the odata.type is present (when needed, e.g. for entities of subtype B) but odata.context URL must be included in the response, along with various links which the client does not need.
> (c) odata.metadata=none: the odata.type is not present

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