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

Case Sensitivity of Property Names, EntitySets, Singletons and Operations

    XMLWordPrintable

    Details

    • Proposal:
      Hide

      Interoperable clients MUST specify identifiers (in payloads and URLs) in the case they are specified in $metadata.

      Services MUST return identifiers (payloads, contextUrl, etc.) in the case defined in $metadata.

      Services SHOULD NOT have identifiers within a uniqueness scope that differ only by case.

      Services MAY support case-insensitive comparisons of identifiers in URLs and request payloads if no exact match is found, following the existing precedence rules.

      Show
      Interoperable clients MUST specify identifiers (in payloads and URLs) in the case they are specified in $metadata. Services MUST return identifiers (payloads, contextUrl, etc.) in the case defined in $metadata. Services SHOULD NOT have identifiers within a uniqueness scope that differ only by case. Services MAY support case-insensitive comparisons of identifiers in URLs and request payloads if no exact match is found, following the existing precedence rules.
    • Resolution:
      Show
      https://www.oasis-open.org/committees/download.php/64120/odata-json-format-v4.01-wd06-2018-10-19.docx https://www.oasis-open.org/committees/download.php/64129/odata-csdl-json-v4.01-wd05-2018-10-22.docx   https://www.oasis-open.org/committees/download.php/64130/odata-csdl-xml-v4.01-wd06-2018-10-22.docx  

      Description

      In 4.01 we add support for case-insensitive system query options, operators, built-in functions and keywords.

      We don't explicitly say whether property, entity set, singleton, or operation names are case-sensitive or case-insensitive
      1) In URLs
      2) In payloads

      For response payloads, we should mandate that properties are written out in the case they are advertised.

      In request payloads, should services support matching property names that differ by case (first looking for a case-sensitive match and, failing that, case insensitive?) or treat as dynamic?

      What about in URLs? if resolution fails to find an exact match, should it look for a(n unambiguous) case-insensitive match, or treat as a dynamic property?

      What about instance annotations and thus namespaces and aliases?

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              mikep Michael Pizzo
            • Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: