Martin Atkins:
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.
I have similar concerns, but different conclusions. From what I've seen of
feeds in the wild, I get the impression that sites tend to take whatever
data they have available, and shove it into whatever fields look more or
less appropriate.
In the best case, you'll get an identical copy of the summary element. Worst
case you'll get a copy of the content element which may be a huge HTML blob,
complete with embedded image thumbnails and all sorts of unwanted metadata.
Either way you've created an element that's just a duplicate of existing
data. Have a look at all the RSS feeds out there using itunes and yahoo
media rss extensions. You tend to see the same content repeated a half dozen
times in different fields. I'd prefer this spec didn't encourage more of
that sort of thing.
IMHO you'd be better off encouraging sites to produce a good summary element
rather than trying to invent a new element that does essentially the same
thing. But that really is just MHO. I do see where you're coming from.
It's worth pointing out that some feed parsers might be confused by the
use of existing atom:elements.
If this is true then that would certainly be a problem.
I wouldn't lose too much sleep over it. I ran some tests overnight on a
couple of feed readers and most seem ok (I wasn't specifically testing your
usage - just general forms of nested element reuse).
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;
As a general rule that doesn't necessarily apply, but for the specific
failure cases I've seen at the feed level, having the atom:title first would
have avoided the problem.
I could add in a requirement that service:provider must appear after
atom:title if that would avoid this bug.
I don't think it would harm, but IMO that sort of thing belongs in an
interoperability appendix - not in the main body of the spec.
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.
If I had to choose, I'd say atom:name was more appropriate. Your usage seems
pretty close to the RFC4287 definition.
However, I could rewrite it to use custom elements if folks think
extending the reach of these Atom elements is wrong.
I honestly don't know. I was kind of hoping that some IETF expert on the
list would express an opinion once I'd raised the issue.
Regards
James
