Re: Processing requirements

On Tue, 05 Jan 2010 03:18:28 +0100, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> On Tue, Jan 5, 2010 at 4:20 AM, Philip Jägenstedt <philipj@opera.com>  
> wrote:
>> On Wed, 30 Dec 2009 04:05:41 +0100, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com> wrote:
>>
>>> On Wed, Dec 30, 2009 at 10:51 AM, Jack Jansen <Jack.Jansen@cwi.nl>  
>>> wrote:
>>>>
>>>> My 2 cents:
>>>> after thinking about it for a bit I think there's definitely a point  
>>>> to
>>>> be made about separating our definition of the name/value pairs and  
>>>> what
>>>> there semantics are from what their external representation is.
>>>> URL-fragments would then become one such representation, url-queries
>>>> another, and we leave a clear path for third parties defining yet  
>>>> another
>>>> external representation while keeping our semantics. We could state  
>>>> in the
>>>> name/value semantics section that, irrespective of external  
>>>> representation,
>>>> each name may be used at most once, order is unimportant, etc. (That  
>>>> is:
>>>> this last sentence is my preference, if we as a group decide  
>>>> otherwise we
>>>> could also state that).
>>>>
>>>> But that doesn't solve the rather nasty issue of there being no
>>>> definitive reference for how to parse url queries and fragments,  
>>>> which is
>>>> demonstrated by the fact that Philip and me seem to have different  
>>>> personal
>>>> views about what "the right way" is.
>>>>
>>>> Even though I'm reluctant to standardise something that has much wider
>>>> scope than just media fragments I guess there simply isn't a way  
>>>> around it:
>>>> if it hasn't been done before we'll have to do it. In a separate  
>>>> chapter,
>>>> with a preamble that we're doing this because it hasn't been done  
>>>> before,
>>>> with the caveat that if it turns out we've done this wrong it means  
>>>> that
>>>> Media Fragments 1.1 (which would adhere to a better standard for  
>>>> name/value
>>>> encoding) would possibly be backward-incompatible with Media  
>>>> Fragments 1.0,
>>>> etc etc etc etc.
>>>
>>> I think we need to add a section that states what we build upon: the
>>> preconditions for parsing media fragments. I think that might solve
>>> Philip's problem of "processing of fragment component is still
>>> undefined". We don't have to say that we are standardising this, but
>>> we can say that it's beyond us to standardise it, that a de-facto
>>> standard has emerged with query parameters, and that we need to build
>>> on something, so we are specifying here what the basis is upon which
>>> we rely. If that basis should change (i.e. "&" be replaced by
>>> something else), the specification of name-value pairs still holds up
>>> and ppl should just adapt their parsing to that.
>>>
>>> Maybe that can help solve it. Philip, what do you think?
>>>
>>> Cheers,
>>> Silvia.
>>>
>>
>> Yes, this is exactly what is needed. To summarize, I would like the
>> following:
>>
>> We define the syntax and processing of the the de-facto  
>> name=val&name2=val2
>> syntax we have been assuming. This amounts to one ABNF syntax section
>> (without any media fragment syntax in it) and one algorithm for parsing  
>> it,
>> which may or may not handle some syntax-invalid input depending on what  
>> the
>> data we collect shows is necessary. The output of this algorithm is a  
>> list
>> of name-value pairs.
>>
>> We encourage other specifications to reference this definition if they  
>> need
>> something similar.
>>
>> We define "media fragments" (sans "URI") in terms of a list of  
>> name-value
>> pairs.
>
> I guess that can work. I just regard "media fragments" as the abstract
> concept of using parts of a media resource - which can be concretely
> specified through those name-value pairs. If you can formulate it like
> this, that would be good.

Hmmm... I'm thinking that "media fragment" is defined by the set of  
dimensions that you get after applying the error handling to the  
name/value list. This is just terminology though and can always be changed  
if "media fragment" already means something (as I've noted I don't really  
know what it means right now).

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Tuesday, 5 January 2010 02:35:23 UTC