-
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]
-
Proposal:
-
Resolution:
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.
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.
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.
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.
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.
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.
Right; we would want to do <m:annotation term="some.term" m:null="true" />.
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)
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.