2006/4/27, James M Snell <[EMAIL PROTECTED]>: > > Ok, so this time it's actually done. Per an offlist suggestion (plea? > ;-) ..) from Thomas, rather than cut-and-paste the full text of the pace > here, I'll just provide a link to the pace which includes a summary of > changes relative to PaceMediaEntries ;-)
Doh! That's not what I meant… but, well, no matter… Actually, I was suggesting adding a summary of changes in the Pace but exclude it from the cut/paste to the list, especially to try to prevent what I'm going to do below ;-) > http://www.intertwingly.net/wiki/pie/PaceMediaEntries2 > 1. Section 8.1 "If the server generates a response with a status code > of 201 ("Created"), the response SHOULD include an Atom Entry > Document representing the newly-created resource." I'm still not OK with this: lacks the Content-Location == Location thingy. But, well, no problem, this'll be another Pace on the table. > 2. Section 8.1 "Clients MUST NOT assume that the URI provided by > the Location: header can be used to edit the created entry." +1 > 3. Section 8.3 has been changed from a notion of "Media Entries", > to "Entries with associated resources". Such resources can be linked > to the entry via content/@src or an enclosure link. The common thread > is that a link with @rel="edit-resource" is used to edit the associated > media resource. This means that folks can still use content/@src to > reference the public endpoint of the media resource if they want, but > that the edit URI is always specified by the edit-resource link. The "associated resource" can be referenced either using content/@src or [EMAIL PROTECTED]"enclosure"], isn't this a bit confusing? Namely, content/@src does not "link [an associated resource] to the entry", it defines the *content* of the entry. And there's still a problem with multiple enclosures… I'd have also rather kept the "Media Entry" name if we were to distinguish entries using "token" (text, html, xhtml) values for atom:content/@type from those using a media-type. > 4. Section 8.3 Deleting an entry with associated a media resource(s) > should delete the resource(s) +1 > 5. Section 7.x <accept> replaces <member-type> to indicate the types > of media resources that can be associated with a collection's entries. +1 However, instead of "absence of @accept means @accept='application/atom+xml'", I'd prefer "absence of @accept means @accept='*/*'", which is more consistent with other similar specs (namely, the Accept request header of HTTP, the [EMAIL PROTECTED]"file"]/@accept attribute of (X)HTML or the xf:upload/@mediatype attribute of XForms) > 6. Section 7.2.3 <app:collection> MAY appear as a child of > atom:feed or atom:source +0.5 -- Thomas Broyer
