Re: ABNF for fragment syntax

On Thu, 26 Feb 2009, Silvia Pfeiffer wrote:

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

That's the purpose of 'mediafragment'
I incorporated most comments in the Wiki:
http://www.w3.org/2008/WebVideo/Fragments/wiki/Syntax#Formal_Grammar
Please let me know if I missed something. (I will add the query part if 
the solution for fragment seems ok to you).
Cheers,


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

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Wednesday, 25 February 2009 21:45:33 UTC