Thomas Broyer wrote:
>[snip]
> Isn't an enclosure an _attached_ resource? "media" resources would
> then still be managed with a behavior different from "entry"
> resources:
> 1. you POST an Atom Entry, you get an Atom Entry
> 2. you POST a "media" resource, you get an Atom Entry with your
> resource attached as an enclosure (you could then edit the Atom Entry
> and add an atom:content)
>
Yes, there are still differences, but the two types of entries are, at
least, handled consistently.
> Atom has multiple enclosures support, how would you edit such entries?
This pace has been designed to support the same general use case as the
current media collections case... that is, one media resource per entry.
Handling multiple enclosures would be considered out of scope for the
core spec. A Media entry is associated with *one* media resource.
>[snip]
> Why couldn't we *just* use atom:content? and maybe an
> atom:[EMAIL PROTECTED]"edit-content"] if the WG has problem with client-side
> negotiation using atom:[EMAIL PROTECTED]"edit" and
> @type="application/atom+xml"] and atom:[EMAIL PROTECTED]"edit" and
> @type="XXX"] (yes this would preclude having application/atom+xml as
> the content for an entry, but I really don't consider that a problem,
> rather a feature)
>
There are lots of things we could *just* do. In this case, there's a
clear advantage in favor of using enclosure links:
a. Consistent with existing practice
b. Frees up the use of content for other purposes (e.g. associating
markup, etc with the media resource.. as in show notes for a
podcast, or speaker notes for a presentation, etc)
>> The key advantage of this approach is that it works seamlessly with
>> existing *casting style applications.
>
> Are you saying that atom:content doesn't work with existing *casting
> style applications? That would be under-using Atom…
>
I'm saying that using enclosure is more consistent with existing
*casting apps.
>[snip]
> 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. 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.
- James
