W3C home > Mailing lists > Public > public-html@w3.org > April 2011

Re: Systematic access to media/plugin metadata

From: Danny Ayers <danny.ayers@gmail.com>
Date: Wed, 13 Apr 2011 12:01:29 +0200
Message-ID: <BANLkTikhM29J6=qmPv=tLqNJCtvYV7fYbA@mail.gmail.com>
To: Henri Sivonen <hsivonen@iki.fi>
Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Leonard Rosenthol <lrosenth@adobe.com>, public-html@w3.org
On 13 April 2011 11:24, Henri Sivonen <hsivonen@iki.fi> wrote:
> On Wed, 2011-04-13 at 10:56 +0200, Danny Ayers wrote:
>> On 13 April 2011 09:11, Henri Sivonen <hsivonen@iki.fi> wrote:
>> > On Tue, 2011-04-12 at 10:50 +0200, Danny Ayers wrote:
>> >> - looking for a hotel, a browser on a mobile device could use the geo
>> >> coords stored in the Exif of a photo to direct the user to the actual
>> >> location of the photo
>> >> - looking at a set of conference photos, the browser could alert the
>> >> user: "hey, that's your friend in the photo!"
>> >
>> > These use cases would require the browser to be able to extract the
>> > location or person metadata and to have UI for directing the user to the
>> > location of the photo or to alert the users about the people in the
>> > photo.
>>
>> Right.
>>
>> > Neither use case (as stated) requires exposing this information to
>> > author-supplied JavaScript programs through an API.
>>
>> How else might you do such things?
>
> By the browser having built-in features that trigger on certain metadata
> without any page author-provided JS being involved.
>
>> Or are you suggesting I expand the
>> descriptions to show how the Javascript might operate? (If that's the
>> case I'll be happy to oblige once I've had some morning coffee...).
>
> As far as I can tell, the use cases you included called for browser UI
> features--not for an API.

I don't think so...the UI parts for directing someone to a hotel or
alerting them to something in a photo could be handled by regular
DOM/HTML, <canvas> or SVG. The only bit that can't easily be fulfilled
right now is access to the metadata.

> Frankly, I get a feeling that the API idea is looking for a problem to
> solve here.

Ok, I can see how it might seem that way, and I do need to come up
with some compelling use cases.

I anticipate two problems with doing this: firstly, because
historically object metadata is hard to access from the browser
context, there won't have been /that/ much work done in the area
already, it's fairly blue sky. On the other hand, the main thing I'm
proposing is a rationalization of what may already be possible (but
difficult), so many use cases could already be fulfilled by other
means. As an analogy, it is possible to dig a hole using your bare
hands or a stick, but to get any decent agriculture going you really
need a plough.

When the browser encounters an object like an image or a video, it
might well have the smarts to be able to display the image or play the
video, and the developer can have access to the controls. But as far
as the metadata is concerned, the object is an impenetrable black box
(unless you jump through custom handler hoops) *even though* the core
functionality needed to expose the metadata is probably available.
This seems an arbitrary and unnecessary limitation of HTML.

Cheers,
Danny.



-- 
http://danny.ayers.name
Received on Wednesday, 13 April 2011 10:02:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:28 GMT