[OpenLayers-Dev] features from Atom

[Sean Gillies]

Tim Schaub wrote:
> Hey-
> 
> So, at some point, I'll update the Atom ticket with a patch that 
> includes the parser I've been using.  I've also extended this parser in 
> an application in a number of ways that might be of general use.  I'm 
> interested to hear some feedback before making changes to the version 
> bound for the trunk.
> 
> Basically, this is about a feature model that allows for round-tripping 
> (more of) Atom entries.
> 
> So, I'm suggesting extending a feature parsed from an Atom entry the 
> following properties:
> 
> feature: {
>      links: array,
>      author: {
>          name: string,
>          uri: string,
>          email: string
>      },
>      published: date,
>      updated: date,
>      attributes: {
>          title: string,
>          description: string,
>          content: string,
>      }
> }
> 
> Where each item in the links array would look something like this
> 
> link: {
>      rel: string,
>      href: string
> }
> 
> (plus more if you care).
> 
> The idea is that things in feature.attributes are more likely things 
> that users are editing.  Things like dates, author, and links are set 
> behind the scenes.
> 
> With this, most of the mappings should be obvious (except maybe that 
> feature.attributes.description maps to atom:summary).  All other 
> (unknown) attributes could get written as atom:category elements with a 
> scheme like http://xmlns.openlayers.org/atom#key where the term is value 
> of attributes[key].
> 
> So, a feature with attributes like
> 
> {
>      "foo": "bar"
> }
> 
> would get written out as
> 
> <atom:category scheme="http://xmlns.openlayers.org/atom#foo"
>                 term="bar"/>
> 
> This means we loose any optional label.  If we want to save labels, then 
> we give features a categories array with objects that have scheme, term, 
> and label properties.  Just depends how far we want to go matching Atom 
> entries.
> 
> I also would suggest we parse the first element representing a geometry 
> and ignore the rest.  The new parser structure I'm using is easy enough 
> to extent id you want different behavior.
> 
> Thanks for any feedback,
> Tim

Atom entry id would be a good thing to keep track of. But yeah, this
otherwise looks a lot like the feedparser.py data structure, which is
what I'm using on the server side of my apps, and that's good.

Sean