W3C home > Mailing lists > Public > public-media-fragment@w3.org > April 2012

Re: [PR Media Fragment] specify how further keywords would be added

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sun, 22 Apr 2012 11:53:30 +1000
Message-ID: <CAHp8n2mv_O_o205iiWzw2WVq1vw-=6mqQtVx+qYyyN=6N-sB1Q@mail.gmail.com>
To: liam@w3.org
Cc: public-media-fragment@w3.org
Hi Liam,

On Thu, Apr 19, 2012 at 8:47 AM, Liam R E Quin <liam@w3.org> wrote:
> I'm sorry for a late comment - I only became aware of this spec today,
> or rather that it applied to images.
> For images, Media Fragments URI 1.0 appears to say how to interpret a
> fragment identifier to take a copped portion of an image.
> This raises two questions, for me at least.
> First, what if a media fragment syntax is registered for a media type
> such as JPEG or TIFF, e.g. through IETF? Which takes precedence and why?
> I believe it necessary for this specification to make that clear.

This is actually a problem for all media types. We have addressed this
is the following section:

Essentially, the spec is a proposal for how to do media fragments, but
the owners of the mime type specifications still have to agree to use

Wide-spread implementation support would obviously help make the
owners of the JPEG, TIFF etc specifications aware of the usefulness of
this specification and would encourage inclusion of a fragment clause
that supports this specificiation.

> Second, current practice for HTML user agents includes scaling of images
> to fit a specified rectangle. One can easily envision other
> transformations, such as those included in SVG. How would one extend the
> notation defined in Media Fragments URI 1.0 to support a sequence of
> transformations, and not only offset and crop? e.g. to scale
> horizontally by 50% would it be xySwh=160,120,0.5,320,240 or should
> implementers wishing to add such functionality use a syntax like
> xywh=160,120,320,240,hscale=0.5 ?

The specification provides a means to include more parameters to the
media fragment URIs as specified in the following section:

Essentially, you would create more namevalue parameters and add them with "&" .

Both your proposals are possible approaches. However, your second
approach with introducing another parameter is likely better than the
first one, because otherwise a new parameter would nullify an existing
one (i.e. xySwh would nullify xywh) which is not as easy to parse and

> There doesn't seem to be a way to say which version of Media Fragments
> one is using, so a clear statemnt about extensibility is very important.

As long as any changes that are made are backwards compatible, there
is no need for a version specification. Extensibility is given through
introduction of more parameters. Is that not sufficient?

Received on Sunday, 22 April 2012 01:54:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:47 UTC