This pace removes the restriction that clients POST ONLY Atom Entry documents to entry collections. The client may POST whatever it likes to the entry collection; it's up to the implementation to determine whether or not to accept what is posted.
Entry collections MUST only contain valid Atom Entry Documents as members. Entry collections are responsible for creating their member entries. Clients do nothing more than post a representation of the member they wish the collection to create. If a collection URI accepts any representation other than an Atom Entry Document, the implication is that it is the responsibility of the server implementation to create a member entry based on the POST'ed representation; otherwise, the server implementation is free to reject what the client posts.
While requiring that Entry Collections contain only valid Atom Entry Documents as members, there should be no requirement that clients MUST only POST valid Atom Entry Document representations to Entry Collection URI's. Collections can choose to create member resources however it pleases. If a client POSTs some other representation to the collection URI, the server MAY choose to either accept the POST or reject it. If the server accepts the POST, the implication is that the server is responsible for somehow creating a new valid Atom entry in the collection based on whatever it is that was posted.
This approach will allow for backwards compatibility with existing AtomAPI (e.g., gregorio-09) implementations and support for alternative methods of creating entries within a collection (e.g. creating an entry in response to a trackback posting to the collection URI).
While the proposal says that Entry collections SHOULD accept Atom Entry Documents for creation request, it is entirely up to the server to accept or reject what the client posts to the collection.
Section 7.3.4: Remove "An Entry POSTed to a collection MUST meet the constraints of the app:member-type element."
Section 8.1: Replace "Every collection accepts POST requests to create resources - the client POSTs a representation of the desired resource to the IRI of the collection. Collections MAY impose constraints on the media-types that are created in a collection and MAY generate a response with a status code of 415 ("Unsupported Media Type")."
with "Clients request that a Collection create a new member resource by POSTing a representation of the new resource to the IRI of the collection."
Section 8.1: Remove "Clients MAY POST invalid Atom for initial resource creation - specifically the id and link elements MAY be omitted."
Section 8.2: Insert: "Entry Collections that allow clients to request the creation of new member resources using POST, SHOULD accept syntactically valid Atom Entry Documents included in the POST request."