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

Entities that may be queryable can be omitted from service document, but then their "url" cannot be specified.

    XMLWordPrintable

    Details

    • Proposal:
      Hide

      Specify clearly in the URL conventions specification how a client with the information in the metadata document, but without accessing any information from the service document, can correctly formulate a URL to designate any entity set (or entity, function, or action) with a suitable qualified name (SchemaNamespace.EntityContainer.SomeThing, whether or not it lies in the default entity container) or unqualified name (SomeThing, for items within the service's default entity container).

      Also clarify the purpose of "url" in the JSON format service document (or eliminate it entirely), and specify the conditions under which an unqualified "name" can appear in the service document (i.e. only for "things" in the service's default entity container).

      Proposal from meeting:
      1. JSON: add "title" name-value pair, optional, may contain "atom:title" if different from entity set name
      2. ATOM: add optional metadata:name attribute for correlation with $metadata to app:collection, metadata:function-import, metadata:entity. may be omitted if same as href, which it typically is if href is a relative url and the service uses the default naming conventions.

      Accepted: https://www.oasis-open.org/committees/download.php/48752/odata-meeting-31_on-20130404-minutes.html#odata-315

      Show
      Specify clearly in the URL conventions specification how a client with the information in the metadata document, but without accessing any information from the service document, can correctly formulate a URL to designate any entity set (or entity, function, or action) with a suitable qualified name (SchemaNamespace.EntityContainer.SomeThing, whether or not it lies in the default entity container) or unqualified name (SomeThing, for items within the service's default entity container). Also clarify the purpose of "url" in the JSON format service document (or eliminate it entirely), and specify the conditions under which an unqualified "name" can appear in the service document (i.e. only for "things" in the service's default entity container). Proposal from meeting: 1. JSON: add "title" name-value pair, optional, may contain "atom:title" if different from entity set name 2. ATOM: add optional metadata:name attribute for correlation with $metadata to app:collection, metadata:function-import, metadata:entity. may be omitted if same as href, which it typically is if href is a relative url and the service uses the default naming conventions. Accepted: https://www.oasis-open.org/committees/download.php/48752/odata-meeting-31_on-20130404-minutes.html#odata-315
    • Resolution:
      Show
      https://www.oasis-open.org/apps/org/workgroup/odata/download.php/48904/odata-json-format-v4.0-wd01-2013-4-23.docx https://www.oasis-open.org/apps/org/workgroup/odata/download.php/48905/odata-atom-format-v4.0-wd01-2013-4-23.docx Accepted: https://www.oasis-open.org/committees/download.php/49026/odata-meeting-34_on-20130425_26-F2F-minutes.html#odata-315

      Description

      CSDL spec (2013-03-19) states in section 12.2.3 "The IncludeInServiceDocument Attribute":

      Entity sets that cannot be queried without specifying e.g. a $filter query option SHOULD specify the value false for this attribute.

      So that implies that some entity sets could be client-queryable (e.g. using a $filter) even though they are not mentioned in the service document.

      Also note that the protocol spec (2013-03-19) section 4 "Service Model" describeds a typical OData interaction with text that does not mention the client fetching the service document.

      Now herein lies the problem: A service document specifies a "url" for each exposed resource, in addition to a "name", with the implied assumption that the client must use the "url", not the "name", when formulating requests (otherwise the "url" would appear to be meaningless"). JSON format examples for service documents show "url" values that look just like unqualified entity set names.

      We therefore need to clarify:

      (1) Is the "url" in the elements of a JSON service document meaningless, i.e. can the client ignore this and just use the qualified (SchemaNamespace.EntityContainer.EntitySet) entity set name or unqualified name (for an entity set in the servic'es default entity container) when formulating a base URL for CRUD operations?

      (2) Does a client with access to the metadata document have ANY reason to need to fetch the content of the service document?

        Attachments

          Activity

            People

            • Assignee:
              handl Ralf Handl
              Reporter:
              evan.ireland.2 Evan Ireland
            • Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: