OASIS Open Data Protocol (OData) TCIcon indicating the project type

OASIS Open Data Protocol (OData) TC

Uploaded image for project: 'OASIS Open Data Protocol (OData) TC'
  1. OASIS Open Data Protocol (OData) TC
  2. ODATA-255

Consider adding support for requesting flattened results

    Details

    • Type: New Feature
    • Status: Deferred
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: V4.0_WD01
    • Fix Version/s: None
    • Component/s: ATOM Format, JSON Format, Protocol
    • Labels:
      None
    • Proposal:
      Hide

      Having added reference entities and solved the relationship problem for deltas, I would propose we postpone this issue to consider in a future release, based on requirements.

      Accepted: https://www.oasis-open.org/committees/download.php/48346/odata-meeting-26_on-20130221-minutes.html#odata-255

      Show
      Having added reference entities and solved the relationship problem for deltas, I would propose we postpone this issue to consider in a future release, based on requirements. Accepted: https://www.oasis-open.org/committees/download.php/48346/odata-meeting-26_on-20130221-minutes.html#odata-255

      Description

      We have added the ability to reference entities within a result using entity references.
      https://www.oasis-open.org/apps/org/workgroup/odata/download.php/48152/latest proposes adding the ability to request that a result be flattened; i.e., that all entries are returned at the top level, and that relationships are represented using entity references.

        Attachments

          Activity

          Ascending order - Click to sort in descending order
          Hide
          Permalink
          hubert.heijkers Hubert Heijkers (Inactive) added a comment - - edited

          Two quick remarks/question:

          The document states that "OData version 4.0 clients MUST be prepared to deal with whose specified set is different then the root set". Obviously implied is that when the client specifies that it accepts the content in a flattened form but clients that don't specify they do in the content type would not need to be able to deal with this.

          Why do we need /@Flat to be appended in the metadata url in the JSON format? We know already the response is flattened and for every object that is not of the type referenced by the metadata url we have an odata.set annotation that the client will need to check for anyway.

          Show
          hubert.heijkers Hubert Heijkers (Inactive) added a comment - - edited Two quick remarks/question: The document states that "OData version 4.0 clients MUST be prepared to deal with whose specified set is different then the root set". Obviously implied is that when the client specifies that it accepts the content in a flattened form but clients that don't specify they do in the content type would not need to be able to deal with this. Why do we need /@Flat to be appended in the metadata url in the JSON format? We know already the response is flattened and for every object that is not of the type referenced by the metadata url we have an odata.set annotation that the client will need to check for anyway.
          Hide
          Permalink
          sdrees Stefan Drees (Inactive) added a comment -

          As agreed in meeting#26 on 2013-02-21set fixVersion field to v5.0_WD01. Please move status to Deferred

          Show
          sdrees Stefan Drees (Inactive) added a comment - As agreed in meeting#26 on 2013-02-21set fixVersion field to v5.0_WD01. Please move status to Deferred

            People

            • Assignee:
              Unassigned
              Reporter:
              mikep Michael Pizzo (Inactive)
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated: