OASIS Open Data Protocol (OData) TCIcon indicating the project type

OASIS Open Data Protocol (OData) TC

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

For instance annotations in Atom, "Annotation" element, "Type", "Term" and "Target" attributes should be lower case

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: V4.0_WD01
    • Fix Version/s: V4.0_WD01
    • Component/s: ATOM Format
    • Labels:
      None
    • Environment:

      [Proposed]

      Description

      In the current [ATOM] spec, the "Annotation" element, as well as the child "Type", "Term" and "Target" attributes are defined in upper case. This is inconsistent with other element that we define in the ATOM payload (for example, the metadata:function element with attributes "metadata" "target" and "title", the metadata:error element and its attributes, etc.).

        Attachments

          Activity

          Ascending order - Click to sort in descending order
          Hide
          Permalink
          ralfhandl Ralf Handl added a comment - - edited

          When applying this issue I noticed two inconsistencies.

          (1) The metadata:annotation element allows values to be specified in "attribute form" as String="Some Value" or Int="42". With everything else lowercase these attributes look odd,th so we COULD lowercase them. But in addition they are incomplete compared to CSDL (e.g. no Duration or DateTimeOffset), and in CSDL their CSDL counterparts are (and hopefully will remain) CamelCased, so however we adapt them, they stay inconsistent.

          Also they add little value over element notation in Atom, which is famous for its verbosity. A handful of shortcuts won't change that.

          So I completely removed the Attribute Value Notation from Atom, and I like the new brevity

          (2) The target attribute of the metadata:annotation attribute is optional, and if omitted it means "the surrounding parent". In addition it allowed the special value "." to also mean "the surrounding parent". I don't like two ways to specify the same meaning, so I removed the special value ".".

          Please comment if you disagree.

          Show
          ralfhandl Ralf Handl added a comment - - edited When applying this issue I noticed two inconsistencies. (1) The metadata:annotation element allows values to be specified in "attribute form" as String="Some Value" or Int="42". With everything else lowercase these attributes look odd,th so we COULD lowercase them. But in addition they are incomplete compared to CSDL (e.g. no Duration or DateTimeOffset), and in CSDL their CSDL counterparts are (and hopefully will remain) CamelCased, so however we adapt them, they stay inconsistent. Also they add little value over element notation in Atom, which is famous for its verbosity. A handful of shortcuts won't change that. So I completely removed the Attribute Value Notation from Atom, and I like the new brevity (2) The target attribute of the metadata:annotation attribute is optional, and if omitted it means "the surrounding parent". In addition it allowed the special value "." to also mean "the surrounding parent". I don't like two ways to specify the same meaning, so I removed the special value ".". Please comment if you disagree.
          Hide
          Permalink
          mikep Michael Pizzo (Inactive) added a comment -

          (1) is only for instance annotations in ATOM, not for CSDL, correct?
          (2) as a general principle, I like having explicit ways of specifying a default value (i.e., an object model can have a property for "target" that the user can always set/get a well defined value and a dumb serializer can always write a value for that property. Same reason we have defaults for things like IsNullable so you CAN omit them, but you can also explicitly specify the default.

          Show
          mikep Michael Pizzo (Inactive) added a comment - (1) is only for instance annotations in ATOM, not for CSDL, correct? (2) as a general principle, I like having explicit ways of specifying a default value (i.e., an object model can have a property for "target" that the user can always set/get a well defined value and a dumb serializer can always write a value for that property. Same reason we have defaults for things like IsNullable so you CAN omit them, but you can also explicitly specify the default.
          Hide
          Permalink
          ralfhandl Ralf Handl added a comment -

          Ad 1: sure, for CSDL the short-hand attribute notation DOES provide value.

          Ad 2: In that case I'd go for the empty string as an alternative notation. We do the same for Path expressions in CSDL, where we intentionally did not use the dot as a pat segment to denote "here".

          Show
          ralfhandl Ralf Handl added a comment - Ad 1: sure, for CSDL the short-hand attribute notation DOES provide value. Ad 2: In that case I'd go for the empty string as an alternative notation. We do the same for Path expressions in CSDL, where we intentionally did not use the dot as a pat segment to denote "here".

            People

            • Assignee:
              handl Ralf Handl
              Reporter:
              mikep Michael Pizzo (Inactive)
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: