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

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:
http://www.w3.org/TR/media-frags/#standardisation-URI-fragments

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
it.

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:
http://www.w3.org/TR/media-frags/#general-structure

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
execute.


> 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?

Regards,
Silvia.

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