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

Re: Processing requirements

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Mon, 11 Jan 2010 21:31:17 +1100
Message-ID: <2c0e02831001110231u4ae9bb62l7788d0ddad083bb0@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: Jack Jansen <Jack.Jansen@cwi.nl>, Media Fragment <public-media-fragment@w3.org>
On Mon, Jan 11, 2010 at 7:53 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Sun, 10 Jan 2010 00:37:33 +0100, Jack Jansen <Jack.Jansen@cwi.nl> wrote:
>> On 5 jan 2010, at 22:10, Philip Jägenstedt wrote:
>>>>> Say someone already has a resource http://example.com/getvideo?id=42
>>>>> (where
>>>>> 42 might be a database row id or something). id here doesn't refer to
>>>>> the id
>>>>> in MF. Is it possible to add MF syntax like 't=5' on top of this? It
>>>>> would
>>>>> be valid syntax but id would be ambiguous. Should it be valid to mix
>>>>> other
>>>>> pre-existing names that don't collide, like
>>>>> http://example.com/getvideo?foo=42&t=5 ? It seems we are making it very
>>>>> difficult to migrate any URLs that already use the query component to
>>>>> use
>>>>> MF. This isn't really an issue in the fragment case as there's not
>>>>> really a
>>>>> lot (any?) existing use of the URI fragment that we could trample on.
>>>> Yeah, I think that's the advantage. The main query strings ppl are
>>>> after are the ones we are defining here. Then there are less important
>>>> ones, such as format="jpg" asking for a time offset to be returned as
>>>> a thumbnail etc. YouTube has a gazillion of them and anyone wanting to
>>>> implement a good media server is highly adviced to check out YouTube's
>>>> query (or rather: fragment) parameters to see what is possible.
>>> If we not only allow but even expect server developers to mix and match
>>> freely in the query string, is it possible to have any meaningful
>>> conformance requirements for them? At least the following break:
>>> * We can't define how to extract a name/value list from the query string,
>>> because the server might already have other requirements e.g. with regards
>>> to how to treat '+', which character encoding to assume when decoding %
>>> encoding or already use the same names as MF for something else.
>>> * We can't define how to map a name/value list into a set of dimensions,
>>> because only the server knows which names were actually intended for MF and
>>> which just happen to collide.
>> I think it is a bad idea to allow servers to freely mix-and-match, for the
>> reasons you state. It is absolutely fine for a server to extend the set of
>> name/value pairs, and it is even fine for a server not to implement one of
>> the name/value pairs (as long as it returns the correct error or resource as
>> stated by the MF spec). But if a server allows, say, "id" but interprets it
>> wholly different then this server is not MF-compliant.
> Note that by mix-and-match I meant simply mixing MF with something else, not
> just when they collide. Certainly an extension that collides with MF is
> worse than one that doesn't, but I think the latter is a bit problematic too
> in that it will in practice limit what names we can use in MF2 depending on
> what server implementations have become popular and their extensions.

FAIK there aren't many media servers that use large amounts of
query/fragment schemes directly on the media files. Most do so on the
html pages (e.g. YouTube) and then relate that through to the video
that the page hosts. I don't think we will encounter many conflicts at
all, but rather ppl will start developing further schemes around our
MF schemes.

>> If we think there's a real danger of name collisions we could go the whole
>> way and prefix our names with mf- or something, but then you get ugly
>> http://example.com/video.ogg?mf-t=3 urls. My preference is that for the 1.0
>> spec we just cross our fingers, and it if turns out we are wrong we fix
>> things with non-colliding names in the next version of the spec.
> The prefix idea is a good one, but how about forcing the extensions to use
> it instead of MF, just like with CSS: -foo-name. This would be applicable to
> the fragment syntax too if UAs want to experiment, so you might see e.g.
> #t=20&-o-aspect=4:3 or something if Opera wants to be able to force the
> aspect ratio like this (we don't, it's just an example).

Interesting... we should discuss this idea of including a
"namespace"-style prefix. It makes it a bit lengthy and talkative, but
indeed easier to segment out from other name-value pairs.

>> I think the "partially compliant" idea doesn't fly, or at least it has
>> serious drawbacks. For example, if the MF url is created by a program it
>> must know that it is interpreted correctly. Take a SMIL player that has to
>> fetch the media for <smil:video src="http://www.example.com/video.ogg"
>> clipBegin="10s" clipEnd="20s"/>. If the server advertises that it supports
>> MF the SMIL player must have the freedom to simply send the URL
>> http://www.example.com/video.ogg?t=10-20 to the server and get the expected
>> data back.
> I agree, I'd rather we not meddle with this, but if want to specify how to
> express MF in the query component (as opposed to just passively accepting
> that some implementations might support it) then we have to take into
> account the fact that the query component already has different parsing
> rules on different servers and that resources already exist that use the
> query component with names that may or may not collide with MF. Given a way
> to resolve such conflicts with prefixes is a fair enough solution in my
> opinion.

I think we may be too much afraid of conflict with something that
doesn't exist yet.
Do you have examples of such conflicts?

Received on Monday, 11 January 2010 10:32:10 UTC

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