I think it's fair to say there's a tension here; on the one hand, there's no need to wrap yourdata in Atom or protocols in APP if you don't need to - that's just more stuff you have to deal with.On the other hand, if Atom and APP support becomes ubiquitous, why not take advantageof some of that infrastructure; otherwise, you may find yourself reinventing wheels.
I can certainly feel Yaron's point of "I'm running into numerous people who think that if you just sprinkle some magic ATOM pixie dust on something then it suddenly becomes a standard and is interoperable."I'm seeing this a lot now too. Worrisome. Even more so now that more and more peopleare familiar with the concept of feeds, but don't understand the actual technology. I'veseen people describe things as if feeds were being pushed to the client, for instance,instead of being pulled from the server.
One thing that bugs me is the potentially extraneous bits in feeds / entries that are actually required: atom:name, atom:title, and atom:summary. JamesSnell is right; it's simple enough to boilerplate these when needed. But to me, there's enough beauty in Atom and APP, to really make it reusable acrossa wide variety of problem domains, that these seem like warts.
Another thorn in my side is the notion of two ways of providing thecontent of an item. atom:content with embedded content, or linked to with the src attribute. The linked-to style is needed, clearly, forbinary resources, like image files. But it's a complication; it would clearlybe easier to have just one way to do it, and that would of course have to bethe linked-to style.
The picture in my mind is that Atom becomes something like ls;just get me the list of the 'things' in the collection, and some of theirmetadata. I'll get the 'things' separately, if I even ever need them. Works for operating systems.
Of course, the tradeoff there is that there are big performance gains to behad by including your content IN the feed itself, with the embedded style;primarily in reducing the number of round-trips between client and serverfrom 1 + # of resources, to 1. It doesn't help that our current web clientof choice, the web browser, doesn't provide programmatic control over it's own cache of HTTP requests. Maybe if it did, the linked-to style would be less of a performance issue.
I suspect I'm splitting hairs to some extent; one of my many vices. I'm keeping an open mind; I'm glad people are actually playing with usingAtom / APP as an application-level envelope / protocol. It's certainlyworth the effort to try. There's plenty to learn here, and we're starting to have some nice infrastructurehere to help us along, and the more people play, the more infrastructurewe'll get, and ...