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: Mon, 23 Apr 2012 08:05:15 +1000
Message-ID: <CAHp8n2=CZn2niqWF2gOAu3ZuwGRNbELeP=UE9111CeRw7MPdxw@mail.gmail.com>
To: Jack Jansen <Jack.Jansen@cwi.nl>
Cc: liam@w3.org, public-media-fragment@w3.org
On Mon, Apr 23, 2012 at 7:43 AM, Jack Jansen <Jack.Jansen@cwi.nl> wrote:
> On  22-Apr-2012, at 03:53 , Silvia Pfeiffer wrote:
>>> 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.
> I beg to differ. While I think the second option (add another parameter to adjust the semantics of an existing parameter) would have been superior and more future-proof, we have (after long discussions) come up with a scheme where user agents can safely ignore any parameters they don't understand. This means that the meaning of xywh is cast in concrete forever. Which means that new semantics require a new parameter.
> The alternative would have required a version parameter, so that old user agents would have been aware that they didn't understand the semantics of newer versions,

Both of Liam's proposals add a new parameter, so they do not change
the semantics of the existing xywh parameter (which it can't anyway).
In the second one there is just some extra functionality happening on
top of the defined functionality, changing a dimension that the xywh
specification has not specified. I believe that is acceptable.

If xywh was used together with xySwh to achieve some backwards
compatibility, it has the same effect as if xywh is used together with
hscale: in both situations "old" parsers would only do the xywh
effect, while new ones would also scale it. My opinion is just that
xwSwh was a repetition of xywh information (and thus "overruling it")
and thus not as elegant.

Received on Sunday, 22 April 2012 22:06:05 UTC

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