On 4/25/06, Joe Gregorio <[EMAIL PROTECTED]> wrote: > On 4/25/06, Kyle Marvin <[EMAIL PROTECTED]> wrote: > > - There are some unexplained life cycle issues. In particular, what > > happens if I issue a DELETE to the enclosure-edit resource and remove > > the media. Is the associated entry removed from the collection > > automatically, or is the client required to issue a DELETE on the > > "edit" link too? In the first use case above (media drop-box), then > > it seems like a single DELETE removing both has to be the way it > > works, as there would be no "edit" link if there is not editable > > metadata. > > I agree a single DELETE is the way it should work. To keep things > consistent I think that DELETE must be directed at the metadata > and not the enclosure-edit resource.
This won't work if the metadata isn't editable (i.e. no "edit" link on the returned entry). So if you think it should be a single DELETE, it seems like doing it on the "enclosure-edit" resource is the only approach that can work for both read-only and read-write media metadata cases. > > - Eric's suggestion that perhaps using "alternate" instead of > > "enclosure" for the public/read-only version of the media is > > reasonable to me. In the case of an Atom entry that refers to media, > > this seems to fit the definition of the "alternate" per RFC4287: "an > > alternate version of the resource described by the containing > > element.". Otherwise, we have validation issues in the media dropbox > > case or if the client doesn't set 'content' and/or the server has to > > synthesize a content element to make it valid. > > An empty content element, while not very helpful, is still valid. Using an 'atomOutOfLineContent' reference to the media public url as atom:content (unless/until explicitly set by the client) is another option.
