Re: Media Fragments URI parsing: pseudo algorithm code

On Fri, 02 Jul 2010 16:49:02 +0200, Raphaël Troncy  
<raphael.troncy@eurecom.fr> wrote:

> Hi Silvia,
>
>> If that is the case, our spec is inconsistent. We have a section that  
>> states:
>>
>> "Note that a general URI fragment or query string specified on a media
>> resource may contain several field-value pairs. They are not
>> restricted to the ones specified here, since applications may want to
>> use additional other parameters to communicate further requests to
>> custom servers."
>
> And I remember that this is clearly what the group wants.
>
>> I was always under the impression that we had agreed that additional
>> name-value pairs are allowed and don't make the ones that we define
>> invalid. I was also under the impression that our ABNF allowed for
>> this.
>
> Indeed, and I step back since I overlook the ABNF syntax.
>    - a mediasegment can ONLY be namesegment OR a axissegment (time,  
> space, track)
>    - BUT a segment can be a mediasegment OR a set of pchar
> I used to only look at the production rule of the mediasegment, thus my  
> wrong interpretation. Therefore, our syntax clearly allows to have new  
> name-value pairs.
> The fact that this bit of syntax is only specified in a non-normative  
> appendix is still a problem. It should also be in the section 4.3.5.
>
> I don't see anymore what are the remaining problems posed by Philip and  
> Yves. Please, could you please both clarify?
>
>    Raphaël
>

The definition is:

; Mediafragment definitions
segment       = mediasegment / *( pchar / "/" / "?" )     ; augmented  
fragment
                                                           ; definition  
taken from
                                                           ; RFC 3986

mediasegment is where the joining of name-value pairs by "&" happens.

*( pchar / "/" / "?" ) is the definition of fragment (and query) from RFC  
3986.

I'm not an ABNF expert, but this definition doesn't seem very useful, as  
it allows segment to either be confined to the name-value pairs defined by  
mediasegment, or any random string that can go into a fragment or query  
component. This doesn't allow unknown name-value pairs to be ignored, does  
it?

What we had is this:

mediasegment     = namesegment / axissegment
axissegment      = ( timesegment / spacesegment / tracksegment )
                *( "&" ( timesegment / spacesegment / tracksegment )

I think this should be changed to something like this:

fragment = *( pchar / "/" / "?" ) # from RFC 3986, because it's easier to  
write

mediasegment     = namesegment / axissegment
anysegment       = timesegment / spacesegment / tracksegment / *( fragment  
- "&" )
axissegment      = anysegment *( "&" anysegment )

As I understand it, the "first-match-wins" algorithm should make this  
always match the things that are MF, and anything else between the "&"s  
are ignored. This should brings things closer to how my processing  
sections work, although I dare not promise they are equivalent without  
checking in more detail.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Monday, 5 July 2010 10:04:09 UTC