Re: app:edited for content/@src

[Peter Keane <pkeane@xxxxxxxxxxxxxxx>]

On Thu, Apr 24, 2008 at 08:10:17PM -0700, Alex Milowski wrote:
> 
> On Thu, Apr 24, 2008 at 6:34 PM, Peter Keane <pkeane@xxxxxxxxxxxxxxx> wrote:
> > This seems to me to be related to the perceived need for richer metadata
> >  for media in an atom document. There have been a few threads recently
> >  on that topic on atom-syntax. Yahoo's Media RSS extension came up
> >  (media:content does *not*, in fact, have mtime as one of the attributes,
> >  but that would be an obvious addition for a later rev), as well as
> >  discussion of work on a new Atom media extension, but nothing has gotten
> >  off the ground as yet. Using an "app:edited" attribute strikes me as a
> >  reasonable solution, but I'd prefer to see the more general issue of
> >  media metadata addressed.
> 
> But the entry itself is the metadata about the media.  If your APP
> implementation
> supports full editing of the entry (e.g. arbitrary XML), then you can attach any
> kind of element with whatever semantics you want.
> 

I confess to being a bit fuzzy on when atom elements (author, title,
updated, etc.) describe the entry document, and when they describe the
content as identified by content/@src. By default I generally assume the
answer is the entry document, not necessarily (although possibly) the
content. Thus the need for metadata specifically & clearly about the
content/@src which is, as I interpret it, what the Media RSS extension
does.

I suspect that your idea is better, in that it is more tightly
focussed, but I sure would love to have those other attributes
(height,width,length,bitrate, etc.) available as well. 

Overloading app:edited seems a bit strange to me. James Snell's
Atom Syndication Format Link Extensions ID [1] (expired) included
'etag','last-modified','range', and 'md5' attributes for atom:link
and atom:content. I would really like to see such an extension gain
acceptance.

--peter keane

[1] http://tools.ietf.org/html/draft-snell-atompub-link-extensions-02

> What I'm looking for is a light-weight version for the actual media
> resource of what
> app:edited and atom:updated provide for the entry
> 
> Seems to me the general issue of media metadata is solved in terms of
> a framework
> (i.e. the entry) but we need some standard elements.  Unfortunately, the
> atom:content/@src didn't quite go far enough.
> 
> Eventually, clients will need to do a HEAD request on the media resource to
> get certain information like the ETag headers.  Having modification
> times associated
> with the media resource (and not the entry) would be greatly useful in knowing
> whether you even need to check that resource.
> 
> --Alex Milowski