Thomas Broyer wrote: > 2006/4/24, James M Snell <[EMAIL PROTECTED]>: >>> I don't think the problem is really with entry vs. media collections >>> but rather with their inconsistent behaviors. >>> Your proposed change to section 7.2.2 above enlightens this: the >>> notion of "prefered collection" was added to allow a client to know >>> where to POST an entries attached/enclosed/referenced resources >>> (cat-blog scenario) without asking the user or needing any >>> configuration. If you remove the notion of "where to POST entries, >>> where to POST attached resources", the cat-blog scenario fails (except >>> if CompoundEntries are finally part of the core, or if collections >>> have an "accept" attribute…) >> No, it doesn't fail. Consider, if a blog allows posting of media >> entries, then the client can POST the image to the entries collection, >> get back an Atom entry, fill in the details and PUT it back. > > There are many blog entries with more than one inline image and/or > where the image itself is not the subject of the entry but an > illustration. For example: > - Tim Bray's blog stats [1] > - Tim Bray's "Friday Slide Scan" [2] or "5✭♫" (5 star music) [3] series > - O'Reilly Radar's "State of the Computer Book Market" [4] > > I consider those kind of entries a core requirement. >
These kinds of entries are supported to the same extent that the current APP draft supports them. That is, in the current APP draft, media collection entries are only ever associated with one resource each. Same thing here. If you want to support a use case where you can upload multiple images then link to each from a single blog entry post, then you'll have two collections... one containing the media entries, the other containing the blog entry that points to those media entries. Or, draft up a compound entries extension. >> For the simplest case, there would be no need for the blog to expose >> two collections. Blogs that wish to separate the various collections >> could still do so, leveraging some as-yet-undefined extension to identify >> what types of resources the collection will accept. > > My problem is not really about separating collections, but there are > times when you really need it (except if you use CompoundEntries), for > example if you don't want to have illustrations (when you have more > than one per entry) appearing as "media entries" by themselves when > you just meant to POST your image so that it could be linked from an > entry. > Again, this pace doesn't make that use case any harder/easier to support than the current draft. A case could be made for keeping the member-type element in the introspection document, but that could just as easily be provided by a standardized extension. - James
