As Tim has stated, "the time has come to focus the discussion by filing Paces for anything that's not a one-liner."
Detailed responses are in-line. On 10/31/05, James M Snell <[EMAIL PROTECTED]> wrote: > > Excellent. Here are some initial thoughts, I'll have more later. Some > are editorial in nature, others not. > > 5.3 Should we explictly specify that prior to updating an entry using > put, the client must perform a GET to retrieve the current > representation of the resource? Section 9: """Clients SHOULD be constructed with this in mind and SHOULD perform a GET on the member resource before editing.""" > Question: This is likely implementation guide material but should > anything be said about the potential for concurrency problems? e.g. > Person A gets the resource, Person B gets the resource, Person B submits > changes, Person A submits the changes.. since there is no resource > locking, there is the potential for conflicts. Perhaps a single line of > text warning folks that resource locking is out of scope?? > > Section 2, 3 & 6: Move to sections 1.1, 1.2 and 1.3 Section 1 is "Introduction". Sections 2, 3 & 6 are "Notational Conventions", "Terminology" and "XML-related Conventions" respectively. I don't see those sections as 'introductory'. > Section 7: Instead of "discover capabilities and locations" make it > "discover the locations of available collections along with associated > metadata". Collections do not have capabilities.. at least none that we > are defining. Collections may either be media or entry collections, that is, they have the 'capability' to handle different media types. > Section 7.2: Can we use application/atompub+xml for the media type instead? I'm not tied to a name, but I also don't want to change just for the sake of changing. Do you have a specific reason *not* to use atomserv? > Section 8.3: Can a media collection contain a member whose type is > application/atom+xml? Yes. > Section 11: Seeing the Title header in use makes me very afraid that > folks are going to start wanting the load up the HTTP headers with all > sorts of other types of metadata. e.g. description of the photo, whether > it is private or not, what tags to use to describe it, etc. I'm not > sure how else we can do this but do we really want to encourage a bunch > of implementation specific metadata being passed around in the HTTP headers? Adding a single header is not encouraging """a bunch of implementation specific metadata being passed around in the HTTP headers""" > Also, when I GET a member of a media collection using it's edit URI, do > the response headers have to contain the Title? No. > And it just seems wrong that the way I set the title initially, and the > way I change the title later are two completely different mechanisms > (e.g. the former uses an HTTP header, the latter uses an atom:entry) Using Title: is a MAY and is ignorable by the server while atom:title is 'client-editable'. So I think it's pretty clear that setting the title in an entry collection should be done via atom:title. You can not change the title of a media collection member once it has been created. -joe -- Joe Gregorio http://bitworking.org
