James M Snell wrote: > Thomas Broyer wrote: > >> Solution: atom:content/@src is the IRI to be used publicly for >> read-only access, and an atom:[EMAIL PROTECTED]"edit" and >> not(@type="application/atom+xml")]/@href gives the "editing" URI. >> >> > > -1. Use atom:link/@rel="alternate" to point to public read-only access, > atom:link/@rel="edit" for editing URIs (both media and metadata). > > >> All this leads me, one more time, to thinking that if metadata is >> editable whatever the type of content (type="text", type="html", >> type="xhtml", type="image/svg+xml", type="image/png", etc.), then >> "binary" content is just a special case of POSTing content in an >> "Entry" collection: >> [snip] >> > > Exactly what I've been saying all along. I'm not going to make this > argument any more. Let's just get media collections fixed so that > they're basically usable and not-confusing and leave it at that. > > why metadata for media collection entries should not be editable?
i see lot of value in ability to attach metadata to media entries and be able to edit it (for start tagging/categories for images). this capability would be consistent for both media and entry collections if atom:[EMAIL PROTECTED]"edit"] points to place where atom:entry can be edited and new relation is used to point where to PUT/DELETE binary data (like rel="mediaedit"). what was mentioned before rel="edit" with type <>"application/atom+xml" seems to be harder and implies that multiple representations are possible - which one would be main media representation ... thanks, alek -- --- Memorable Quote from Firefly (105. Out Of Gas) -Ship like this, be with you until you die -That's because it's a deathtrap
