Joe Gregorio wrote: > On 7/4/06, Elias Torres <[EMAIL PROTECTED]> wrote: >> [snip] >> 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. >
No problem. Anytime. >> 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... You are correct. It is not required on POST, but it is required on the return, meaning that if their client doesn't see on the response or any consequent GETs it barfs. I'm not sure how much you have played with GData, but I mentioned this to James and he agreed it was worth looking into it. Thomas Broyer also has been thinking about the same issue. Mainly it is about whether we recommend using rel=self for a read-only version of the Atom XML entry and rel=edit for a PUT URI that could be version specific to support something like Google's optimistic concurrency. > >> 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. > Looking forward to reading #10. > >> 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. > As we implement collection paging, we will have more experimental experience to give more feedback on this. I thinking about scaling and how can I pre-process as much of the pages as I can and also avoid the sliding-window problem that James mentioned when we met last week in Cambridge. For now your answer will do. >> >> 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. Sure. > >> 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. So is it definitely in stone that the WG cannot take up collection management until the core is done? I really really think that collection management should be part of the core, but I guess it is just me. > > Thanks, > -joe >
