Uploaded image for project: 'OASIS Open Data Protocol (OData) TC'
  1. OASIS Open Data Protocol (OData) TC
  2. ODATA-561 odata.type shouldn't require "#" for primitive types
  3. ODATA-687

Prepare clients to deal with type annotations without the leading "#"

    XMLWordPrintable

    Details

    • Type: Sub-task
    • Status: Closed
    • Priority: Major
    • Resolution: Duplicate
    • Affects Version/s: V4.0_OS
    • Fix Version/s: V4.0_ERRATA01
    • Component/s: ATOM Format, JSON Format
    • Labels:
      None
    • Environment:

      [Proposed]

    • Proposal:
      Hide

      In 4.5.3, Annotation odata.type, of the OData JSON format document, change the existing line:
      "For built-in primitive types the value is the unqualified name of the primitive type, specified as a URI fragment."
      to:
      "For built-in primitive types the value is the unqualified name of the primitive type. In OData 4.0 this is specified as a URI fragment, but clients should be aware that future versions of OData are expected to make the leading "#" optional."

      Show
      In 4.5.3, Annotation odata.type, of the OData JSON format document, change the existing line: "For built-in primitive types the value is the unqualified name of the primitive type, specified as a URI fragment." to: "For built-in primitive types the value is the unqualified name of the primitive type. In OData 4.0 this is specified as a URI fragment, but clients should be aware that future versions of OData are expected to make the leading "#" optional."

      Description

      ODATA-561 calls out the fact that the leading "#" is not really required (and doesn't really make sense) for primitive types (because they are not really a fragment located within the metadata document) and suggests (for backward compatibility) allowing, but not requiring, services to omit the "#" for primitive types.

      We should make clients aware that this change is expected, so that they can write their code appropriately.

      Ideally we would say: "Services should not include a leading # for primitive types but clients should be prepared to handle primitive types with or without a leading"

        Attachments

          Activity

            People

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

              Dates

              • Created:
                Updated:
                Resolved: