On 7/4/06, Elias Torres <[EMAIL PROTECTED]> wrote:
Hi AtomPub folks, I am working with James Snell on the Abdera project and have almost completed an Atom PP implementation that will soon be available for interop testing. After reading the latest draft, a few questions/comments came up and wanted to make you aware of them. I will appreciate any discussion on it. 5.1 Do we need to specify the Accept header value for an instropection document? i.e. application/atomserv+xml
I don't think so, that's pretty basic HTTP stuff.
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?
Same answer as above.
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.
Bah, you're right, @title should be an element not an attribute and we should allow mulitple child elements as long as none of them have the same xml:lang value. Good catch.
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?
The definition of the service document allows 'foreign markup', which in this case could be elements from the Atom namespace.
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.
How could GData require a [EMAIL PROTECTED]"self" on a POST when the POST is a request to create the resource? I'm pretty sure I'm missing something here...
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?
Yes, probably need better wording if the spec isn't clear on that.
9. I'm not sure why we are forcing order by atom:updated. This gives no room to server-side or client requested ordering.
That kind of extensibility comes in with allowing foreign markup in the service document. That is, a collection is always ordered by atom:updated, but it is certainly possible ( and probable ) that someone will define an extension for the service document that lists other URIs that order the collection in different ways.
From reading the spec, I do not think there is a requirement on collection page size. I think that it is a good idea, maybe it would be better to explicitly state so.
The page size is determined by the server. I would prefer not to hamstring an implementation because we thought we knew better.
Collections are a bit underspecified. I would like to know if you are planning to specify collection management protocol. 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.
That's not in scope for the core protocol, but certainly worth pursuing either as an I-D or maybe get the WG rechartered to work on it after the core protocol is done. Thanks, -joe -- Joe Gregorio http://bitworking.org
