Subject: Media Attributes For Links

From: "Lindsley Brett-ABL001" <[email-masked]>
Date: Tue, 8 Dec 2009 10:51:50 -0500

This is an old topic - was there any closure on adding additional media
attributes to links? For example, a link to an image may want to specify
its length/height. An MD5 would also be useful. Are there any
recommended practices? I know there have been a few proposals, but I
don't know if there was any additional progress in this topic.

Brett Lindsley

Motorola Applied Research Center

---

From: "Lindsley Brett-ABL001" <[email-masked]>
Date: Thu, 10 Dec 2009 08:25:42 -0500

Thanks for the comments. There is also another option at
http://martin.atkins.me.uk/specs/atommedia

It is a simple problem - an Atom entry could be routed between several
different device types. It would be a problem if a handset attempted to
play an HD video, but there is no way to know the media format. If the
media format was part of the link, the end device would immediately know
if it could decode the media.

Brett

-----Original Message-----
From: Dmitri Popov [mailto:[email-masked]] 
Sent: Thursday, December 10, 2009 7:05 AM
To: Lindsley Brett-ABL001
Cc: atom-syntax Syntax
Subject: Re: Media Attributes For Links

On Tue, 2009-12-08 at 10:51 -0500, Lindsley Brett-ABL001 wrote:
> This is an old topic - was there any closure on adding additional
> media attributes to links?
> For example, a link to an image may want to specify its length/height.
> An MD5 would also be useful. Are there any recommended practices? 
I've adopted Media RSS (http://video.search.yahoo.com/mrss) - using
XML::Atom::Ext::Media perl module. It works for me, but I don't serve
Atom to users yet and using it for internal communication only, so any
sane approach would work for me - I don't worry too much if it standard
or not yet.

Media information is included into Entry element, but yes, I embed this
info in links. Using In-lining extension for Atom which is RFC draft.

http://tools.ietf.org/html/draft-mehta-atom-inline-01

so I've got something like

<link>
  <ae:inline xmlns:ae="http://purl.org/atom/ext/">
    <entry>
      <media:thumbnail xmlns:media="http://search.yahoo.com/mrss/"
height="640" width="400"/>
    </entry>
  </ae:inline>
</link>

Here is XML::Atom extension I've made for In-lining support:

http://github.com/pin/xml-atom-ext-inline/blob/master/lib/XML/Atom/Ext/I
nline.pm

Sorry for so perlish point of view. And I'm not sure if it relevant for
you, but hope this helps...

-- 
Dmitri Popov

---

From: Dmitri Popov <[email-masked]>
Date: Thu, 10 Dec 2009 16:05:09 +0300

On Tue, 2009-12-08 at 10:51 -0500, Lindsley Brett-ABL001 wrote:
> This is an old topic – was there any closure on adding additional

<link>
  <ae:inline xmlns:ae="http://purl.org/atom/ext/">
    <entry>
      <media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" height="640" width="400"/>
    </entry>
  </ae:inline>
</link>

http://github.com/pin/xml-atom-ext-inline/blob/master/lib/XML/Atom/Ext/Inline.pm

-- 
Dmitri Popov

---

From: Mo McRoberts <[email-masked]>
Date: Thu, 10 Dec 2009 13:20:32 +0000

> sane approach would work for me - I don't worry too much if it standard

FWIW (and I don’t know how relevant this is, necessarily), the BBC took a similar approach with the iPlayer feeds. e.g.:

http://feeds.bbc.co.uk/iplayer/highlights/tv

M.

---

From: Mo McRoberts <[email-masked]>
Date: Thu, 10 Dec 2009 13:44:27 +0000

> if it could decode the media.

Arguably that should be part of the type attribute, and it’s worth noting that HTML5 incorporates a certain degree of support for this by supporting adding a codecs parameter to video/ MIME types. e.g.:

video/mp4; codecs="avc1.42E01E, mp4a.40.2"
video/ogg; codecs="theora, vorbis"

This certainly goes part of the way, though it obviously doesn’t include lots of information which can only be gleaned by reading the metadata contained within the resource itself (frame rate, bitrate, progressive vs. interlacing, inband subtitling presence, etc., etc.), and some which can only be determined by a human (genre, content advisories, and so forth).

The scope of metadata for multimedia content is huge (see http://www.bbc.co.uk/ontologies/programmes/2009-09-07.shtml for example). I’d love to see a situation where it could all be easily expressed within the context of an Atom document in an agreed interoperable way, but it’s a bit of a can of worms, to say the least.

M.