2006/7/4, Elias Torres:
5.1 Do we need to specify the Accept header value for an instropection document? i.e. application/atomserv+xml
There could be content negotiation at the introspection document IRI, so you –as a client– should send an appropriate Accept request-header field. On the other hand, if the server serves only application/atomserv+xml at the introspection document IRI, then it can safely ignore the Accept-* headers. It might also process them and return a 409 (Not Acceptable) if they don't match application/atomserv+xml. Both approaches are allowed by HTTP.
5.3.1 Maybe the same question as before? Are you going to make any mention of content-type negotiation on GET to Member URI?
I'm preparing a PaceContentNegotiationSection.
7.1 Should we have language-aware titles in app:collection? 7.2.2.1 says that @title is language sensitive. I guess you may use xml:lang, but what about multiple language versions of the title.
If you want to provide alternative titles depending on the client's preference, use content negotiation ;-)
7.2.1 Has anybody expressed a need of having app:link elements in service, maybe to point to self or an alternate humand-readable representation of the service?
As James said, someone could use atom:link, or create its own extension (which could be submitted to the IETF Standards Track)
8.3 I guess it makes sense for link/@rel=edit to be optional, but what about link/@rel=self? I didn't find the word 'self' in the specification. Google seems to require 'self' relationship in their posts and I like to have both a separation between GET/PUT for member URIs.
I *don't* like to have a _separation_ between GET and PUT IRIs: you should be able to GET the IRI where you'll PUT. But you could have something à la W3C with a "permalink" always giving you the latest "version" or the resource, and an IRI specific to that version, where you'll actually PUT the updated representation. From the distributed editing point of view, this also looks like GData's optimistic concurrency I think (I've only read the docs, not actually tried it). GET /entries/first-post HTTP/1.1 Server: www.example.net HTTP/1.1 200 OK Date: nnnnnn Content-Length: nnn Content-Type: application/atom+xml Content-Location: /entries/first-post/5 (Optional) <entry ...> ... <link rel="edit" href="/entries/first-post/5" /> </entry> A GET to /entries/first-post/5 would lead to the same entry. Clients A and B retrieve the entry, they know they will PUT to /entries/first-post/5. Client A edits the entry and PUTs it to /entries/first-post/5, the server will create a /entries/first-post/6 and /entries/first-post will reference that new IRI. Client B edits the entry and PUTs it to /entries/first-post/5, the server respond with a 4xx status code (maybe 409 (Conflict) but I'm not sure as it doesn't fit into "This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request.", I think 403 (Forbidden) would be more appropriate... or maybe a new status code?), eventually sending the latest version of the entry along with a "Content-Location: /entries/first-post" header, so that the client does not need to GET /entries/first-post. Now, client B has to merge its changes into the "/6" version, resolve conflicts if any and resubmit the updated entry to /entries/first-post/6. It looks like GET and PUT endpoints are distinct, but actually they're not: anywhere you can PUT, you can also GET. Eventually, if the server does not want or cannot keep every previous version of the entry, GET requests to "previous version IRIs" could result in a 303 (See Other) with a Location header directing to the latest version. Another way of implementing the same mechanism would be that /entries/first-post always returns 302 (Found) or 307 (Moved Temporarily) to the latest version, rather than sending it in the response body. This way, it's clearer that GET and PUT endpoints are the same.
8.4.2 Example of posting a PNG includes a Content-Location in the response header. In 8.1 you said that when the POST request contains an Atom Entry Document, the response from the server SHOULD include it, but nothing about when the request is not an Atom document. Are you suggesting we do the same for media post requests?
I suggest that APP just use HTTP and do not create new rules and/or constraints when they're not needed. Content-Location tells the client that the returned entity could also be found at the specified IRI. If this IRI is the same as the one given in the Location header of a 201 (Created) response –giving the IRI of the created entry–, then the client knows that the returned entity is a representation of the created entry. That's HTTP, you get it for free. The only needed rule/constraint is to require that Content-Location be an absolute IRI (because HTTP does not clearly define the base IRI for responses to POST requests), and that it should be equal character-by-character to the Location IRI when the server wants to tell the client they are equal. This way, clients don't have to canonicalize or otherwise use special algorithms to compare IRIs (but they can do it if they want to).
9. I'm not sure why we are forcing order by atom:updated. This gives no room to server-side or client requested ordering.
+1 atom:updated is not enough for a client to synchronize with a server without having to retrieve every "page" of the collection feed, because atom:updated might not be changed while the entry has ben modified. In case the client can do a GET to the entry IRI just before editing it, it's OK, but that's not the case during offline editing...
Collections are a bit underspecified. I would like to know if you are planning to specify collection management protocol.
This is planned, but not in the "core" protocol we're discussing right now. Many "legacy applications" have a fixed set of collections (that's the case of almost every blogging system), so they don't need collection management.
For example, right now on my implementation, collections are created on-demand and its accept type is based on the first entry it was posted to it. However, I would like to be able to modify the title and add/remove additional accept types. This would make room for extension developers to add more metadata to the collection such as ACLs, owners, summaries, etc.
I'd personally use a <link rel="edit" /> at the feed-level (and eventually in the introspection doc) to point to an editable Atom Entry. I'd also add a "special" collection of entries, where every entry represents a collection and contain a copy of app:collection children elements (e.g. app:accept) so that they can be edited. That's approximately what James is doing. -- Thomas Broyer
