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

On Wed, Sep 8, 2010 at 7:28 AM, Jack Jansen <Jack.Jansen@cwi.nl> wrote:

> Personal opinion ahead.
>
> I like the idea of using an indirection mechanism to allow media fragments
> to use more complex addressing than it's native syntax enables. Actually, I
> think it is probably the only sane solution: encoding complex shapes (or
> timing constraints, or whatever else) in a URL is bound to lead to ugly
> constructions.
>
> That said, there are a number of problems with your suggestion of
> standardising the ref= scheme.
> First and foremost, it is an elephant-sized hole for cross-site scripting.
> Imaging an agent checking the hostname of the base url, finding everything
> safe, handing it off to its url-library, which then happily proceeds to
> contact the completely unchecked URL in the ref= parameter. Bad idea...
> There are also implementation issues with the agent not knowing whether it
> supports the format pointed at by the ref= parameter without retrieving the
> resource. This could be solved through mimetypes (either retrieved from the
> server, or explicitly coded as ref=image/svg+xml,url). Actually, this is not
> only an implementation issue but also a standardisation issue: unless we
> specify the certain mimetypes for ref= must be accepted it is unclear what
> adding ref= would add in the first place.
>
> Note that MF is an open-ended standard: there is nothing that disallows
> more, extra, parameters. So there is an easy way in which you could
> experiment with this: you just define a "europeana-extended media fragment",
> where you state that the ref= parameter must also be supported, etc etc etc
> (addressing the various issues sketched above). This would allow experience
> to be gained with the format, so that it could be used as input for a future
> Media Fragments 2.0.
>
>

More personal opinion here. :-)

I agree with Jack that you should experiment with this using your own
approach, since without use cases and experience the browsers will not
implement any of this.

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.

In this context, I have a very direct question: what do you expect the user
will see differently for your Web page when they browse to content which has
such annotations? Will they see hyperlinks on different areas? Will they see
overlays? What would be the consequence of this? The problem is: as long as
there is no visual consequence of having such annotations available, there
isn't really anything that the browser vendors can implement and they will
just leave it all to javascript technologies.

Cheers,
Silvia.