Re: Processing requirements

On Mon, 11 Jan 2010 11:31:17 +0100, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

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

[snip]

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

I am also not particularly worried about conflicts in practice, I just  
want to know how to handle this in the spec. It is particularly important  
when writing tests to know if random name/value pairs are allowed and if  
they are conforming (either all or just those with a vendor prefix) or  
merely tolerated by the parsing rules.

Here's how I view the layering:

1. an arbitrary string, the URI query component in this case
2. the ordered list of name/value pairs that results from applying  
processing rules to the above string (mainly involving splitting on  
certain characters and decoding percent encoding)
3. the set of dimensions that results from applying processing rules to  
the above list (mainly involving removing duplicates and ignoring unknown  
names)

In this particular thread I'm talking about level 2; that we seem to  
expect/encourage non-MF name/values and that conflicting name/values quite  
inevitably are already in use.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Monday, 11 January 2010 18:44:44 UTC