W3C home > Mailing lists > Public > public-media-fragment@w3.org > September 2010

Re: Expressing complex regions with media fragments - use cases + possible solution

From: Jack Jansen <Jack.Jansen@cwi.nl>
Date: Thu, 9 Sep 2010 00:12:12 +0200
Cc: Bernhard Haslhofer <bernhard.haslhofer@univie.ac.at>, public-media-fragment@w3.org, Robert Sanderson <azaroth42@gmail.com>, Simon Rainer <Rainer.Simon@ait.ac.at>
Message-Id: <68BB8333-7855-4B47-911A-9A404BD7E5F7@cwi.nl>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>

On 8 sep 2010, at 14:31, Silvia Pfeiffer wrote:

> On Wed, Sep 8, 2010 at 7:00 PM, Jack Jansen <Jack.Jansen@cwi.nl> wrote:
> 
> On 8 sep 2010, at 02:51, Silvia Pfeiffer wrote:
> > I have, however, a pretty big caveat with standardising this approach: right now we are discussing with the browser vendors on how to present spatial media fragment URIs. There is a preference to use them for splicing pictures, i.e. for rendering only the referenced image or video region.
> >
> > I do not believe that matches your intentions here. IIUC your intentions here are to only have a means to provide annotations to regions. I think this is more of a "image map" type approach than an "image splicing" approach - correct me if I'm wrong.
> 
> We've got to be careful here: browser vendors tend to think that the whole world revolves around the browser:-) A media fragment is basically nothing more than a specification of a portion of a video (audio, image) resource, and even though we give guidelines on how to present such a fragment in the browser that doesn't mean it's the only application of media fragments. I would assume that the Media Annotation folks couldn't care less about presentation: they just want to be able to point at something inside the video.
> 
> 
> Except: everyone wants to see their results in the browser. So, if the browser vendors agree to present a spatial media fragment URI as an image slice, then you can do as many annotations as you want with such a URI, it will never be presented as an image with highlights by the Web browser. So, as long as we are talking about a presentation in a Web browser, we are actually talking about the same application doing the same thing with the same URI.

I'm 100% in agreement with Bernhard here: our main task is in defining how to address subparts of media items, very similar to how #xmlid addresses subparts of an XML document. For practical reasons, we also define guidelines on how we think some classes of applications should render some of our MF-based addresses, but that is much less important. Moreover, we can provide no more than guidelines.

There's also a problem with your (Silvia) reasoning that reasoning about "the browser" is similar to reasoning about "the operating system": the browser is simply a platform on which an application runs. Clearly, if someone types an MF-url into the location bar, something consistent should happen. But more often than not the MF-url will be used in the context of an application (either client-side or server-side), and this application will know best what to do. An annotation-viewing app will most probably want to show the whole original resource with some form of highlighting on the portion selected by the MF.

As an aside: this means I also disagree with Ian's WHATWG mail <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028163.html>: we define addressing, but the semantics of using those addresses should be formally explained in the specification referencing our work. In case of HTML it would be best if it provided a default rendering semantic (such as "crop to the specified area") with a CSS-based or attribute-based method to override this ("draw the whole resource, and make the area selected by the MF available to scripts through the DOM").

--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman
Received on Wednesday, 8 September 2010 22:12:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:39 GMT