Updated Summary of recent paces... Appologies if I've missed or
mischaracterized any.
=============================================================================
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)
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.
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)
Collection Model
* Robert suggests simplifying the spec by dropping the Collection
model. Everything is just "Feeds". GET on Collection URI returns a
feed. Also affects introspection.
* http://www.intertwingly.net/wiki/pie/PaceSimpleIntroduction
* http://www.intertwingly.net/wiki/pie/PaceFeedsNotCollections
(sayre)
* 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)
Introspection
* Robert believes that the current workspace introspection model is
inadequate
* http://www.intertwingly.net/wiki/pie/PaceRemoveListTemplate
(sayre)
* http://www.intertwingly.net/wiki/pie/PaceSimpleIntroduction
(sayre)
* http://www.intertwingly.net/wiki/pie/PaceUseAppOutlines (sayre)
* http://www.intertwingly.net/wiki/pie/PaceRemoveMemberTypeMust
(sayre)
* http://www.intertwingly.net/wiki/pie/PaceXoXoIntrospection
(sayre)
* Luke Arno wants to use XHTML for Introspection. Last we heard,
a new version of the pace was in development.
* http://www.intertwingly.net/wiki/pie/PaceXHTMLIntrospection2
(arno)
* I want to drop workspace introspection from the core spec
* http://www.intertwingly.net/wiki/pie/PaceReworkProtocolModel
(snell)
* http://www.intertwingly.net/wiki/pie/PaceReworkCollectionMembership
(snell)
* http://www.intertwingly.net/wiki/pie/PaceReworkCollectionListing
(snell)
Member-type extensibility
* Robert does not see a need for an IANA registry of collection member
types. There appears to be consensus for this.
* http://www.intertwingly.net/wiki/pie/PaceRemoveRegistry (sayre)
* I propose that the collection model can be simplified, dropping the
need to explicitly specify media collections.
*http://www.intertwingly.net/wiki/pie/PaceReworkCollectionMembership
(snell)
Listing members
* Robert and Luke do not think link[rel="edit"] should be required.
* http://www.intertwingly.net/wiki/pie/PaceEditLinkMustToMay
(arno/sayre)
* Offering an alternative approach to list-templates. I fully
expect these to be -1'd but wanted to put it on the table for
general consideration. Consensus appears to be against this.
* http://www.intertwingly.net/wiki/pie/PaceListTemplates (snell)
* Thomas suggests ordering members by app:modified rather than
atom:updated and argues for dropping list-template
*
http://www.intertwingly.net/wiki/pie/PaceOrderCollectionsByAppModified
(broyer)
* http://www.intertwingly.net/wiki/pie/PaceRemoveListTemplate2
(broyer)
* I propose adding list paging ('next','previous','first','last') to
the core
* http://www.intertwingly.net/wiki/pie/PaceListPaging (snell)
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 suggest that clients be allowed to post whatever they want to a
collection; the server can choose to accept/reject whatever it
wants.
* http://www.intertwingly.net/wiki/pie/PaceReworkCollectionMembership
(snell)
* Luke suggests that the server can generate atom:id values on a GET
request
* http://www.intertwingly.net/wiki/pie/PaceServerIdGeneration (arno)
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.
Roundtripping (related to Invalid Atom / atom:id handling)
* Luke believes that the element roundtripping discussion is useless.
* http://www.intertwingly.net/wiki/pie/PaceRemoveWhoWritesWhat
(arno)
Given the course of the valid atom discussion, consensus *seems* be
starting to lean in this direction..
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)
Deleting resources
* Robert argues that nothing should be said about removing members
from multiple collections following a DELETE operation on a member
resource.
*
http://www.intertwingly.net/wiki/pie/PaceClarifyCollectionAndDeleteMethodByWritingLessInsteadOfMore
(sayre)
Consensus *seems* to be leaning in favor of this.
Security
* Robert believes that the existing security consideration text is
inadequate.
*
http://www.intertwingly.net/wiki/pie/PaceRemoveSecurityUnspecification
(sayre)
