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

Consider format that is tailored for programmatic access (public comment c201602e00002)

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: V4.0_CSD01
    • Fix Version/s: V4.0_CSD02
    • Component/s: CSDL JSON
    • Labels:
      None
    • Environment:

      Proposed

    • Proposal:
      Hide

      Inheritance: add "x-baseType" extension keyword in addition to "allOf" keyword.

      4.1.3 Enumeration Types: OpenAPI specification doesn't support "anyOf" keyword, so enumeration types are represented just as string enums without the ambiguous "pattern".

      4.3 Entity Container: use "resources" name/value pair whose value is an object with one name/value pair per entity container child. Add name/value pair "kind" to the object describing the container child

      EntitySet/@EntityType and Singleton/@Type: since we introduce keyless entity types for singletons we won't use complex types for singletons, so the JSON format can use the same keyword "type" for both resource kinds

      Show
      Inheritance: add "x-baseType" extension keyword in addition to "allOf" keyword. 4.1.3 Enumeration Types: OpenAPI specification doesn't support "anyOf" keyword, so enumeration types are represented just as string enums without the ambiguous "pattern". 4.3 Entity Container: use "resources" name/value pair whose value is an object with one name/value pair per entity container child. Add name/value pair "kind" to the object describing the container child EntitySet/@EntityType and Singleton/@Type: since we introduce keyless entity types for singletons we won't use complex types for singletons, so the JSON format can use the same keyword "type" for both resource kinds
    • Resolution:
      Show
      https://www.oasis-open.org/committees/download.php/58159/odata-json-csdl-v4.0-wd02-2016-05-18.docx Accepted: https://www.oasis-open.org/committees/download.php/61046/odata-meeting-178_on-20170622-minutes.html

      Description

      Public Review Comment https://lists.oasis-open.org/archives/odata-comment/201602/msg00002.html:

      Hello!

      My team is consuming OData v4 in the browser as part of OpenUI5 with the goal to support business applications. Here are some comments based on this background.

      “This JSON format for CSDL is based on JSON Schema.”

      I fully understand the idea to express CSDL as s.th. which can be validated by a tool, but I think this is only one aspect. There is for sure a need for code to inspect the CSDL and react on it programmatically, not with a focus on validation, but on generic UI support (derive type information, labels, structures of tables or forms, etc.). I believe this can benefit from a JSON format which is tailored for programmatic access and not constrained by some validation tool’s data structures. Such code would have some knowledge about OData and its semantics, in contrast to generic validators which are unaware of that.

      I appreciate that the chosen MIME type “application/schema+json” leaves room for coexistence of such formats.

      “If the structured type has a base type, the schema contains the keyword allOf whose value is an array with a single item: a JSON Reference to the definition of the base type.” This is fine for validators, but unwieldy for normal javascript access.

      “4.1.3 Enumeration Types”: The emphasis on member names is fine for human readability, documentation, debugging etc., but it does not help to build applications which are really fast. To do so, integers would be much better, both in data and meta data.
      I also wonder how valuable the “pattern” is: it allows for arbitrary number representations and quite useless string representations like “Red,Red,Red,Red,Red,…”? Again, a simple integer with a range or a list of allowed values should be easier, faster, safer.

      (4.3) “The entityContainer object may contain name/value pairs entitySets, singletons, actionImports, and functionImports.” This is a nice way to tell entity sets and singletons apart, but on the other hand, if you only got a name you need to look into different maps until you find it. At times, it is more convenient to look into a single map and then inspect a type information contained inside the resulting object.

      “An object describing an entity set must have an entityType”, “An object describing a singleton must have a type”: This inconsistency hurts sometimes.

      Ciao,
      Thomas

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              handl Ralf Handl
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: