2006/2/8, rob yates <[EMAIL PROTECTED]>: > > All, > > I wanted to branch off the other thread as rather than discuss the > merits of PaceCompoundEntries I want to see if the group feels there > are implementation problems / limitations with the current treatment > of media collections as described in draft 7. I have two questions > > a) does the group feel that there is an implementation problem in > draft 7. The gory details are below, copied over from the other posts. > I have also attached a couple of suggestions from Joe on how to fix.
+1 > b) does the group feel that there is a need to have editable meta data > associated with entries in MEDIA collections, Depends what's behind Entry and Media collections… My first thoughts were that Entry collections were collections whose members have "Atom" metadata (title, category, etc.) –and so have an Atom Entry representation– and Generic/Media collections were collections whose members would just be "stored", without metadata. That made Generic/Media collections "a place where you'll put documents used by members of Entry collections". If you'd have liked to add metadata to a Generic/Media resource, you'd have had to POST an entry in an Entry collection using a content/@src. That said, I'm open to have editable metadata for Media resources. Actually, I think that having chosen an Atom Feed representation for collections opened the door and now we have to cross the door. Thoughts: - is this a MUST? - if so, is there any reason to keep a distinction between Entry and Media collections? cannot an entry be an image with metadata (title, summary, author)? - if so, this leads us to talk about "roles" instead of "types" of collections: when composing a compound entry (cat-blog scenario), your APP client should be able to automatically choose where to POST the different parts (Atom Entry, images, etc.) - but, in the cat-blog scenario (which *is* very common I guess), I don't want to have any metadata attached to my images, so can't we "re-introduce" a Media collection where members wouldn't have any metadata? just like an FTP folder where I don't have to deal with file names and where I can't create a subfolder; or just like "media" resources in the metaWeblog API. Conclusion: - keep Media collections without metadata (but an Atom Feed representation isn't really appropriate, see below) - open Entry collections to "everything with editable metadata" –which means "everything I can make an Atom Entry representation of"– (ex: I POST an image/jpeg, the server extracts EXIF metadata to build an Atom Entry and gives me 2 URLs where I can update the Atom Entry or the image; when I PUT an image/jpeg, the server updates the entry according to the new EXIF metadata; when I PUT an Atom Entry, the server updates the image/jpeg EXIF metadata with the entry metadata –alternatively when I POST or PUT an image/jpeg, the server remove the EXIF metadata after having processed it). This seems to be very similar to what James implemented, but I suggest using two APP-controled URLs, instead of PUTting the updated image at the Atom Entry URL… This makes it coherent and compatible with my multipart/related proposed extension. - add roles to Entry collections Alternatively: - every collection is an Entry collection (see above about "opening" it to non-Atom representations), drop Media collections - in the cat-blog scenario, the entry would be a Compound Entry, created using a multipart/related structure (except if someone can propose something better) - roles can be added as an extension My problem with using Atom Feed representations for collections: when we switched to using Atom Feed, we replaced the Name header (which in essence was our recently discussed "slug") with the Title header, so that the server could populate the atom:title in the Atom Feed representation of the collection. There's still a problem: where does the atom:author comes from? and an Atom Entry with atom:content/@src MUST have an atom:summary, where does its content come from? Someone proposed using a From or Author header. Don't you think we're going to have every "atom" metadata in HTTP headers? that is, rewriting Atom in HTTP-header syntax? And why did we start thinking about such a thing? because we (not me) wanted to use an Atom Feed representation for collections, which imposes a small set of metadata to be attached to any member of the collection. I'm working on a simple APP implementation and will try to provide an alternative to the Atom Feed (it will very likely be something similar to the Collection Document of protocol-04) -- Thomas Broyer
