[OpenLayers-Dev] features from Atom

[Eric Lemoine]

On Thu, May 1, 2008 at 10:34 PM, Tim Schaub <tschaub at openplans.org> 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, I'm far from being an Atom expert, but what you're describing
here makes sense to me. One single question: do you think it'd make
sense to do:

feature: {
    atom: {
        links: array,
        author: {
            name: string,
            uri: string,
            email: string
        },
        published: date,
        updated: date,
        attributes: {
            title: string,
            description: string,
            content: string,
        }
    }
}

and leave the other attributes in feature.attributes. The
Atom-specific title, description and content attributes would be
duplicated in feature.attributes.

What you think?

Thanks,

--
Eric
}