OData AtomPub formatting: application/xml vs. application/zip

While looking at responses from some OData feeds I saw that their structures are slightly different depending on wether they have content type set to application/xml or application/zip. Here are two examples:

1. applica开发者_开发百科tion/zip

<content type="application/zip" /> 
<m:properties>
  <d:Id>Simple.Data.Core</d:Id> 
</m:properties

1. application/xml

<content type="application/xml">
<m:properties>
  <d:ProductID m:type="Edm.Int32">1</d:ProductID>
</m:properties>
</content>

Both of them are sent as AtomPub (stanard RSS schema used by OData), but in case content has a type "application/zip", m:properties element comes at the same level as content, and if it's "application/xml", it comes as a subelement of "content". According to OData specification at odata.org, the second format is correct. Does anyone know why the first one format is also used (and even understood by OData clients)?

Thanks in advance

---

Actually both are correct. The first one (with the m:properties outside of content) represents a Media Link Entry (MLE) as per the ATOMPUB spec. The OData format for MLE is described here: http://www.odata.org/developers/protocols/atom-format#RepresentingMediaLinkEntries. The second one is a normal non-MLE entity.

---

I have received the following answer in OData Google group:

If an entity type is marked as a Media Link Entry, i.e. it is backed by media, it's properties are not present in the element of the atom:entry element. And the content element points to the location to download the backing media from. Another example of such an entity is the 'Titles' collection in Netflix's feed. http://odata.netflix.com/v2/Catalog/Titles?$top=1 You mention below that you are having trouble parsing such entity types in Atom, how are you parsing the ATOM feed ? Are you using one of our client libraries or are you parsing the response by hand ?

Reference : https://www.rfc-editor.org/rfc/rfc5023#page-25

Phani Raj Yayavaram Narasimha