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

Selection of individual properties in [ATOM] should not include property name

    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

      Currently, the example in Section 10 of [ATOM] implies that when selecting a single property (i.e., ~Customers('ALFKI')/FirstName), the payload would contain the name of the property in the d: namespace:

      <Title xmlns="http://schemas.microsoft.com/ado/2007/08/dataservices">CEO<Title>

      This implies that what is represented is a property with a given name, which is not the case; what should be represented is the value of the property, which is independent of the property itself (and can thus be used, for example, in passing as a parameter to an action). This is also inconsistent with how a function that returns a single property is represented, and is inconsistent with the JSON format (which represents this as a name/value pair with the name "value").

      We should specify that an individual property is serialized in ATOM as an element named "value" in the odata metadata namespace.

        Attachments

          Activity

          mikep Michael Pizzo (Inactive) created issue -
          ralfhandl Ralf Handl made changes -
          Field Original Value New Value
          Proposal Specify in Section 10 of [ATOM] that an individual property is serialized as an element named "value" in the odata metadata namespace (that may contain metadata:type and metadata:null attributes, following the same rules as the d:<propertyname> element (which should be updated in 5.1.11.1 to include the metadata:null attribute) and correct examples in Section 10 and 11 accordingly. Specify in Section 10 of [ATOM] that an individual property is serialized as an element named "value" in the odata metadata namespace (that may contain metadata:type and metadata:null attributes, following the same rules as the d:<propertyname> element (which should be updated in 5.1.11.1 to include the metadata:null attribute) and correct examples in Section 10 and 11 accordingly.

          Accepted: https://www.oasis-open.org/committees/download.php/48346/odata-meeting-26_on-20130221-minutes.html#odata-254
          Status New [ 10000 ] Open [ 1 ]
          ralfhandl Ralf Handl made changes -
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Resolved [ 5 ]
          Hide
          ralfhandl Ralf Handl added a comment -

          Using metadata:type and metadata:null attributes within an metadata:value element feels odd, and we already use a local attribute "type" for the metadata:annotation element, so I defined the metadata:value element with local attributes "type" and "null":

          <!-- payload format for property value responses -->
          <xs:element name="value">
          <xs:complexType mixed="true">
          <xs:sequence>
          <xs:any namespace="http://docs.oasis-open.org/odata/ns/data" processContents="lax" minOccurs="0"
          maxOccurs="unbounded" />
          </xs:sequence>
          <xs:attribute name="type" type="edm:TPropertyType" />
          <xs:attribute name="null" type="xs:boolean" />
          </xs:complexType>
          </xs:element>

          Looking at how collections of primitive or complex scalar values are now represented, it feels extremely odd that the "element" element is "defined" in the (probably forever) schema-less "data" namespace instead of also being defined in the metadata namespace like its siblings metadata:annotation and metadata:value.

          Show
          ralfhandl Ralf Handl added a comment - Using metadata:type and metadata:null attributes within an metadata:value element feels odd, and we already use a local attribute "type" for the metadata:annotation element, so I defined the metadata:value element with local attributes "type" and "null": <!-- payload format for property value responses --> <xs:element name="value"> <xs:complexType mixed="true"> <xs:sequence> <xs:any namespace="http://docs.oasis-open.org/odata/ns/data" processContents="lax" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> <xs:attribute name="type" type="edm:TPropertyType" /> <xs:attribute name="null" type="xs:boolean" /> </xs:complexType> </xs:element> Looking at how collections of primitive or complex scalar values are now represented, it feels extremely odd that the "element" element is "defined" in the (probably forever) schema-less "data" namespace instead of also being defined in the metadata namespace like its siblings metadata:annotation and metadata:value.
          ralfhandl Ralf Handl made changes -
          Assignee Ralf Handl [ ralfhandl ]
          ralfhandl Ralf Handl made changes -
          Hide
          mikep Michael Pizzo (Inactive) added a comment -

          I'm concerned about the application of this issue also changing the attributes to the default namespace.

          I think it's useful to have a common way to read the nullability and type of a property, regardless of the name of the property.

          Show
          mikep Michael Pizzo (Inactive) added a comment - I'm concerned about the application of this issue also changing the attributes to the default namespace. I think it's useful to have a common way to read the nullability and type of a property, regardless of the name of the property.
          mikep Michael Pizzo (Inactive) made changes -
          Status Applied [ 10002 ] Resolved [ 5 ]
          Hide
          mikep Michael Pizzo (Inactive) added a comment -

          btw; putting "element" in the data namespace was a mistake that we should fix. as ralph says, it should be in the metadata namespace, only user data should be in the data namespace.

          I propose
          1) We keep null and type in the metadata namespace
          2) We fix a historical error by putting element (always) in the metadata namespace.

          Show
          mikep Michael Pizzo (Inactive) added a comment - btw; putting "element" in the data namespace was a mistake that we should fix. as ralph says, it should be in the metadata namespace, only user data should be in the data namespace. I propose 1) We keep null and type in the metadata namespace 2) We fix a historical error by putting element (always) in the metadata namespace.
          Hide
          ralfhandl Ralf Handl added a comment -

          Should we also remove the type attribute from the annotation element? Currently it's a local attribute there.

          What about data:links and data:uri used for representing LinkUrls (section 12)?
          ODATA-276 already suggests replacing data:uri with metadata:entity-ref, so it would seem logical to replace data:links with metadata:entity-refs or metadata:entity-references.

          Show
          ralfhandl Ralf Handl added a comment - Should we also remove the type attribute from the annotation element? Currently it's a local attribute there. What about data:links and data:uri used for representing LinkUrls (section 12)? ODATA-276 already suggests replacing data:uri with metadata:entity-ref, so it would seem logical to replace data:links with metadata:entity-refs or metadata:entity-references.
          Hide
          mikep Michael Pizzo (Inactive) added a comment -

          I could go either way for the annotation element; the code knows it's reading an annotation, rather than a property, so it likely has different code anyway, but it is convenient to have one way to get the type so is probably easier to make it metadata:type.

          Yes, if we reject ODATA-276 we should put uri and links in the metadata namespace as well, and if we do approve ODATA-276 we should put links (or whatever we call it; I kinda like "entity-references") in the metadata namespace.

          Show
          mikep Michael Pizzo (Inactive) added a comment - I could go either way for the annotation element; the code knows it's reading an annotation, rather than a property, so it likely has different code anyway, but it is convenient to have one way to get the type so is probably easier to make it metadata:type. Yes, if we reject ODATA-276 we should put uri and links in the metadata namespace as well, and if we do approve ODATA-276 we should put links (or whatever we call it; I kinda like "entity-references") in the metadata namespace.
          Hide
          ralfhandl Ralf Handl added a comment -

          How do we express that an annotation has anull value?

          <m:annotation term="some.term" />

          or

          <m:annotation term="some.term" m:null="true" />

          Omitting the annotation isn't sufficient if the metadata document defines a "default" value for that term.

          Show
          ralfhandl Ralf Handl added a comment - How do we express that an annotation has anull value? <m:annotation term="some.term" /> or <m:annotation term="some.term" m:null="true" /> Omitting the annotation isn't sufficient if the metadata document defines a "default" value for that term.
          Hide
          mikep Michael Pizzo (Inactive) added a comment -

          Right; we would want to do <m:annotation term="some.term" m:null="true" />.

          Show
          mikep Michael Pizzo (Inactive) added a comment - Right; we would want to do <m:annotation term="some.term" m:null="true" />.
          Hide
          mikep Michael Pizzo (Inactive) added a comment -

          Note that:
          -new example in 5.1.11.1 uses m: rather than metadata: in example
          -also, previous example uses m:type rather than metadata:type
          -also, two instances in 5.4, Delta Response example (mea culpa)

          Show
          mikep Michael Pizzo (Inactive) added a comment - Note that: -new example in 5.1.11.1 uses m: rather than metadata: in example -also, previous example uses m:type rather than metadata:type -also, two instances in 5.4, Delta Response example (mea culpa)
          ralfhandl Ralf Handl made changes -
          Assignee Ralf Handl [ ralfhandl ]
          ralfhandl Ralf Handl made changes -
          Assignee Ralf Handl [ ralfhandl ]
          handl Ralf Handl made changes -
          Assignee Ralf Handl [ ralfhandl ] Ralf Handl [ handl ]

            People

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

              Dates

              • Created:
                Updated:
                Resolved: