On Jun 3, 2009, at 9:32 PM, Mark Nottingham wrote:
This also gives an opportunity to put in fixes that would otherwise
be backwards-incompatible, and in general tighten things up. IMO,
there are a number of things that needs to be cleaned up in Atom,
especially for the non-blog use case.
Just food for thought,
What do you think needs to be cleaned up? We could use this as an
informal list of items that coud at some point form the basis for a
new media type effort.
I have used Atom in 2 1/2 non blogging projects and felt at times that
some things are 'not right' but not to a point that I could nail them
down. Here is a very rough sketch of issues I had (these are AtomPub
issues actually):
- underspecification of the <workspace> element. It is grouping
collections but what is the significance of such groups?
- missing built-in indexing/querying forms in <collection> element
- missing support for 'typing' collections so clients can discover
them based on capability (a start was James' features draft)
- missing native support for hierarchies
- missing native support for POE functionality (though having this
orthogonal to AtomPub is propably preferable)
- missing native support for processing status/proression information
when returning a 202 Accepted
Also, just food for thought.
Jan
On 04/06/2009, at 2:43 AM, Nikunj R. Mehta wrote:
On Jun 2, 2009, at 6:28 PM, Mark Nottingham wrote:
On 27/05/2009, at 10:12 PM, Julian Reschke wrote:
I do not agree with that conclusion, but nevertheless, just
because something is syntactically legal doesn't make it a good
choice.
+1 - the clearest way to communicate what's going on here is to
use a new child element.
Assuming that the contents of the link element are inlined content
are adding an extension without explicitly identifying it; this
may conflict with future uses. There isn't a way for an Atom
processor to inspect a link element and know that the content is
inlined; they have to guess that this specification is in effect,
therefore the link content is the inlined content. This isn't
good practice.
Just FYI, Joe Gregorio and by implication Google supports directly
embedding atom:content inside atom:link. See the last comment on
[1]. I don't know what we mean by practice here, but that is
exactly what is going on in lots of places.
Nikunj
http://o-micron.blogspot.com
[1]
http://blogs.msdn.com/astoriateam/archive/2008/02/18/related-entries-and-feeds-links-and-link-expansion.aspx#8573352
--
Mark Nottingham http://www.mnot.net/