2006/4/24, James M Snell <[EMAIL PROTECTED]>:
> == Rationale ==
>
> The WG seems to be in agreement that the current definition of Media
> Collections is horribly broken. There is inconsistency in the behaviors
> of media and entry collections, there is ambiguity in what the Location
> header needs to point at,
+1
> there are problems when trying to match up what a client posted to
> what actually shows up in the collections Atom feed,
This would be solved using atom:id, but that's another problem…
> In the syndication space, there is a pre-existing notion of entries with
> enclosures. Podcasting, photocasting, etc all use the enclosure link to
> associate media resources with entries. Atom defines an enclosure link
> relation for that very purpose. There is no reason why we cannot
> leverage that same link here.
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)
Atom has multiple enclosures support, how would you edit such entries?
(one possibility to work with enclosures would be to POST the attached
resource to the entry URI, the server would then add that resource as
an enclosure ; to remove an enclosure, just remove the atom:link and
the server might free the space occupied by the no longer referenced
resource)
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)
> 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…
> Section 7.2.2: Change:
> {{{
> In an app:workspace element, the first app:collection element of each
> type MUST refer to the preferred or primary collection. In the following
> example, the "Entries" collection would be considered the preferred (or
> primary) entries collection of the workspace and the "Photos" collection
> would be considered the primary media collection:
> }}}
>
> To
> {{{
> In an app:workspace element, the first app:collection element MUST refer
> to the preferred or primary collecton. In the following example, the
> "Entries" collection would be considered the preferred collection"
> }}}
>
> Remove the member-type element from the example in Section 7.2.2
> Remove the member-type element from Section 7.2.3
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…)
Let me try an alternative using atom:content (for "read-only",
"public" access) and keeping entry vs. media collections (until
replaced with "accept" or CompoundEntries).
Anyway, thanks for your Pace, at the minimum it exists and will allow
discussing on a concrete proposal.
--
Thomas Broyer
