James M Snell wrote:
Modifing metadata on media resources
* I suggest using POST on member resource URI's to update metadata
(e.g. atom:title and atom:summary)
* http://www.intertwingly.net/wiki/pie/PaceReworkPostOnMemberResource
(snell)
-1
See http://www.imc.org/atom-protocol/mail-archive/msg02434.html
plus it introduces two ways to do the same thing depending on whether
the resource is in an Entry or Media collection (PUT vs. POST). That was
one of my problems with using Atom Feed Documents to list collection
membership [1] [2]: it introduces metadata (at least atom:author and
atom:title) where we don't need/want it; again: if you want an entry
whose content is an image, then POST an entry whose content is an image
(Atom-Format allows such things and further more allows you to embed the
image data into the Atom Entry; you can also POST the image into a
collection without metadata and then create an entry in an entry
collection referencing the image in atom:content/@src).
Pub control
* Luke Arno is arguing to get rid of pub:control and pub:draft
* http://www.intertwingly.net/wiki/pie/PaceDropControl (arno)
* http://www.intertwingly.net/wiki/pie/PaceWorkflows (arno)
Consensus *appears* to be leaning towards keeping pub:control
and pub:draft.
Really not sure about that…
I think Joe is going the other way (at least for app:draft and
PaceWorkflows) and I'm about to do the same.
Error response
* I am proposing refinements to the existing Success/Failure text
and hoping to stimulate more discussion about error response
requirements
* http://www.intertwingly.net/wiki/pie/PaceBetterHttpResponseCode
(snell)
I don't see a need to legislate more than HTTP does.
Even if you require some sort of error response entity-body, there will
be “broken” implementations so you'll have to deal with error responses
without entity-body and provide a “generic” error message based on the
HTTP status code.
Collection Model
[…]
* I suggest simplifying the spec by refining the Collection model.
GET on Collection URI returns a feed. Also affects Introspection.
*http://www.intertwingly.net/wiki/pie/PaceReworkProtocolModel
(snell)
*http://www.intertwingly.net/wiki/pie/PaceReworkCollectionMembership
(snell)
*http://www.intertwingly.net/wiki/pie/PaceReworkCollectionListing
(snell)
PaceRemoveListTemplate2 might have been listed here.
My model is the one described in [3]
Invalid Atom / atom:id handling
* To avoid posting syntactically invalid Atom, Luke is suggesting the
use of a dummy atom:id used to signal the server to create a new
atom:id
* http://www.intertwingly.net/wiki/pie/PaceMagicId (arno)
* Robert doesn't want invalid Atom posted to a collection
*
http://www.intertwingly.net/wiki/pie/PaceSimplifyClarifyBetterfyRemoveBogusValidityText
(sayre)
I don't want either.
See [4] where this is partly addressed.
There appears to be consensus that clients MUST only post valid Atom
entries to a collection. The remaining question is on how atom:id
values are generated and whether or not servers are allowed to change
the atom:id once posted. The consensus seems to be leaning towards
allowing the server to change whatever it wants but there are open
questions about this.
Example: changing the atom:id is a violation of Atom-Format.
Collection POST requirements
* Robert argues that collections may rightfully not implement POST and
may return other status codes besides 201 on success.
* http://www.intertwingly.net/wiki/pie/PaceRemoveAcceptPostText
(sayre)
-1
I can see POST-only collections [5], but not GET-only (in the sense that
it would return a 405 Method Not Allowed on a POST; 401 Unauthorized
would be OK though if it depends on user credentials –i.e. someone can
do it but not you)
[1] http://www.imc.org/atom-protocol/mail-archive/msg01618.html
[2] http://www.imc.org/atom-protocol/mail-archive/msg01621.html
[3] http://www.imc.org/atom-protocol/mail-archive/msg02466.html
[4] http://www.imc.org/atom-protocol/mail-archive/msg02873.html
[5] http://www.imc.org/atom-protocol/mail-archive/msg01384.html
--
Thomas Broyer
