James Holderness wrote:
Martin Atkins wrote:
It was suggested that a more Atom-shaped media specification might be
useful, so we drafted up this:
http://martin.atkins.me.uk/specs/atommedia
At first glance that all seems fairly reasonable to me. The only thing
that concerned me was the media:description element. Is there any reason
why the atom:summary element wouldn't work just as well?
I'm trying to imagine how I would construct a feed if I were a photo
service like say flickr. The title is obvious, the content I'd probably
put an html img thumbnail along with a more detailed description if the
author had provided one, and the summary would just be the
aforementioned description. I can't see what I'd do with the
media:description element other than duplicate the atom:summary.
Is there a specific use-case that I'm missing?
One of the principles I've been following with this stuff is to avoid
repurposing existing Atom elements that might be used by generic feed
readers, because sites will not want to alter what they're sending to
generic feed readers in order to support the new media bits.
However, if it turns out that most publishers aren't using atom:summary,
that most aggregators don't do anything with it, or that publishers were
using it to contain the media description anyway then I'd be happy to
remove it. It wasn't really a feature I felt strongly about other than
avoiding clashes with existing implementations.
We also have a small specification for describing the "service
provider" that hosts a feed (for example, YouTube or Twitter). This is
intended to be similar in design to atom:author.
http://martin.atkins.me.uk/specs/activitystreams/provider
It's worth pointing out that some feed parsers might be confused by the
use of existing atom:elements. For example they'll interpret your
service:provider title as the title of the feed. I know Planet Venus
used to have problems with that sort of thing, although it's possible it
has since been fixed.
If this is true then that would certainly be a problem. I can see how
this sort of thing happens, having inadvertently introduced a similar
bug by using getElementsByTagNameNS instead of getting only child nodes.
Wouldn't suprise me if other implementations do it too, though hopefully
they'd be okay as long as the feed-level atom:title appears before
atom:provider; otherwise I'd expect such implementations to also
interpret the entry-level atom:title as the feed title.
I could add in a requirement that service:provider must appear after
atom:title if that would avoid this bug.
Also, it could be argued that you're redefining the meaning of the atom
elements. In RFC4287, atom:title is defined as "a human-readable title
for an entry or feed". That's not how you're using it at all. I'm not
sure if that sort of thing matters.
I'm also not sure if this sort of thing matters. For what it's worth, I
did also consider using atom:name, the child of atom:author for this
purpose, since we're really talking about the name of the provider
rather than its title. The choice between title and name was arbitrary,
to be honest.
However, I could rewrite it to use custom elements if folks think
extending the reach of these Atom elements is wrong. I was motivated by
trying to make service:provider similar to atom:author, but I guess
really atom:name would have been more consistent than atom:title in that
case.
