W3C home > Mailing lists > Public > public-media-fragment@w3.org > February 2009

Re: ABNF for fragment syntax

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 26 Feb 2009 07:21:42 +1100
Message-ID: <2c0e02830902251221g1ba7ea41k46bbc99b38e81600@mail.gmail.com>
To: Yves Lafon <ylafon@w3.org>
Cc: Michael Hausenblas <michael.hausenblas@deri.org>, public-media-fragment@w3.org
On Thu, Feb 26, 2009 at 2:45 AM, Yves Lafon <ylafon@w3.org> wrote:
> On Sat, 21 Feb 2009, Michael Hausenblas wrote:
>
>>
>> Yves,
>>
>> Solid work! Just two minor comments:
>>
>> a) Usually, one finds the top-level production at the beginning and the
>> 'less important' ones (such as <DIGIT = %x30-39>, etc.) at the end. Any
>> concrete reason why you chose the bottom-up style?
>
> in fact, those ones should be imported from 3986, I prefer to show external
> dependencies upfront, but that's just a matter of style.
>
>> b) When reading our MF ABNF in relation to the generic URI ABNF rules as
>> of
>> RFC3985 [1], I was wondering if we need some more contextualisation? The
>> 'Collected ABNF for URI' basically says:
>>
>> URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
>> fragment      = *( pchar / "/" / "?" )
>>
>> and we start with
>>
>> mediafragment = ( timefragment / spacefragment / trackfragment /
>> namefragment ) * ( "&" ( timefragment / spacefragment / trackfragment /
>> namefragment ) )
>>
>> Where <mediafragment> per our ABNF == <fragment> per RFC3986, right?
>
> yes, I used mediafragment there as we might use this also for query URI, to
> construct first-class URIs for "fragments" (as fragment is heavily
> overloaded, we might find another word to describe parts of a document)

I would make this explicit and create e.g. an element called "segment"
that can explicitly be either a query or a fragment.

Cheers,
Silvia.

>> c) Any good reason why you didn't introduce an intermediate for
>> (timefragment / spacefragment / trackfragment / namefragment) in the
>> top-level production rule? I guess it would increase the rule's
>> readability
>> and increase reusability, no?
>
> something like fragmentaxis ? In a way it would make harder the definition
> of constraints between the different combinations of time/space/track
> fragments. But as is it messy anyway, and only prose will save us from
> outlining all the different ordered combinations...
>
>>
>> [1] http://tools.ietf.org/html/rfc3986#appendix-A
>>
>>
>
> --
> Baroula que barouleras, au tiéu toujou t'entourneras.
>
>        ~~Yves
>
>
>
Received on Wednesday, 25 February 2009 20:22:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:32 GMT