>From most people we talked to, they expect atom:category to be used as a
human readable label kind of thing. Our extension mechanism though uses URIs
for the categories, kind of loosing the human readable part with this.
atom:content is mostly used to present a human readable abstract of whatever
the atom:entry is representing. This is most useful, of course, for blogs
and feedreaders.
If we would place abstract or meta data into it, that would make this use
case kind of hard. The way we have choosen allows properties to put a human
consumable representation into atom:content and atom:summary, thereby being
still feed reader friendly, and still comply to the atom spec in general.
Does that make sense?
Frank Mantek
Google
On 6/27/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>
> In a presentation on gData given at xtech [1], there is the following
> statement:
>
> Declaring extension profiles ("kind")
> - Overloaded <atom:category>, not the best choice
>
> I was hoping that someone on this list ( in this group? ) might be
> able to expand on the subject. I was not able to attend and I'm really
> curious what they learned.
>
> I've also been wondering why the the extension mechanism was used for
> the Google Data Model as opposed to just sticking everything in the
> <content> tag.
>
> [1] http://2007.xtech.org/public/schedule/presentations
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Data API" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/google-help-dataapi?hl=en
-~----------~----~----~----~------~----~------~--~---
