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

Clarify create/replace for server-defined dynamic properties

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: V4.01_OS
    • Fix Version/s: V4.02
    • Component/s: Protocol
    • Labels:
      None
    • Proposal:
      Hide

      Document that when a dynamic property is missing in entity-level POST/PUT, the server is free to generate a non-null default.

      Show
      Document that when a dynamic property is missing in entity-level POST/PUT, the server is free to generate a non-null default.

      Description

      I wrote:

      I think we need to understand why this text:

       A missing dynamic property is defined to be the same as a dynamic property with value null.

      is only present in the section “Set a Value to null”.

      Is it also intended that that same text would apply to the request payload of entity-level (not property-level) POST and PUT requests?

      Would a server be considered spec-compliant if it responds to a missing value by generating a non-null default, and responds to a null value by having no value at all?

      then Ralf wrote:

      I think there’s no corresponding text in the sections for Create (POST) and Replace (PUT) because the text would have to differentiate between client-defined (“open”) dynamic properties and server-defined (“hidden”) dynamic properties.

      For client-defined dynamic properties the same statement is obviously valid for Create: the server does not know that property, the client does not state its value, so it is completely unknown to the server.

      For client-defined dynamic properties and Replace there’s the edge case that the property had been sent in a previous request and has a known value for the server. Here the server can decide to
      1. Completely forget that this dynamic property ever existed
      2. Keep a trace that this property once existed and now doesn’t have a value
      3. Something else I wouldn’t think of

      For server-defined dynamic properties the behavior can be server-specific and even vary between different “hidden” properties: no value, implicit default value, explicitly stored default value – that’s completely up to the server.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              evan.ireland.2 Evan Ireland
            • Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: