Thomas Broyer wrote:
>
> 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.
Thanks. I believe this is the answer I was looking for, just wondering
whether any of this should mentioned in the spec or not. Maybe it is
enough to say that because Atom < REST < HTTP there is no need to repeat
HTTP specification information.
>
>> 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.
Cool. I am looking forward to see what is in it.
>
>> 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 ;-)
Accept-Language? I don't think so, because I might have a mixed bag of
languages in my titles, i.e. an author writing to two audiences. On
another note, I have been labeled as a content-negotiation fanatic
amongst my peers in one or two occasions, but I think I found the true
content-negotiation groupie now. :)
>
>> 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)
Fair enough.
>
>> 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.
Agreed. I think we are all thinking along the same lines. I do not see
anything wrong with being able to GET on a PUT IRI. Mainly, I am
advocating that we use "self" for the latest read-only with pointer to
PUTable IRI. The spec makes no mention of "self" whatsoever, but now it
is being used by Google and others and so we should include it in the
spec. Of course, only if we are interested in having any input on its
use, if not, Google will become the de-facto standard on anything that
the APP spec in silent on.
>
>> 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).
I do not have a strong opinion on the matter, just seeking clarification
on the spec text and examples.
>
>> 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...
>
I definitely see your problem with it. I wasn't going as far as talking
about synchronization, but you are right. Is synchronization part of the
scope of the spec? I bet the WG/Gang/Crew is not too interested in
solving that problem.
>> 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.
>
Which James is doing that? I would like to see more of this. I think it
would give valuable feedback to the group to try many approaches and see
what could be reusable in the spec.
-Elias
