Re: Resolving ISSUE-19

On Thu, 17 Feb 2011 01:00:19 +0100, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:

> On Thu, Feb 17, 2011 at 12:20 AM, Philip Jägenstedt <philipj@opera.com>  
> wrote:
>> I've now committed the first 3 patches from
>> <http://lists.w3.org/Archives/Public/public-media-fragment/2010Dec/0035.html>,
>> live at
>> <http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/>.
>>
>> With this, I'm happy to close ISSUE-19
>> <http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/19> and won't
>> object going to LC.
>>
>> ACTION-212  
>> <http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/212>
>> can now be closed.
>>
>> Note that I would also have liked to clean up unused productions as per  
>> my
>> 4th patch, at least these productions are not referenced in the spec and
>> could be removed:
>>
>> * trackparams
>
> That is indeed useless as it is. I thought trackparams would be standing  
> for
>    trackparam *( ";" trackparam )
> in which case it would be useful. But seeing as it's not particularly
> necessary, I'm happy to remove it.

OK, I've removed it.

>> * segment
>
> This is necessary, because it is basically a change to RFC3986. It
> states that instead of what is specified there, namely:
>    segment = *pchar
> we want to give it a more specific meaning, namely this:
>    segment       = mediasegment / *( pchar / "/" / "?" )
> which is more restrictive than that of RFC3986. So, I think this has to  
> stay.

As far as I can tell it's more permissive and thus contradictory with  
segment as defined in RFC3986, in that this production also allows "/",  
"?", ":" (from timesegment) and possibly more.

>> * mediasegment
>> * axissegment
>> * timesegment
>> * spacesegment
>> * tracksegment
>> * namesegment
>
> These build the bridge between RFC3986 and our specification, so these
> need to stay, too. In this way you can follow all the way from RFC3986
> through segment through mediasegment down to each of the fragment
> definitions we have.

My main problem at this point is that these productions aren't actually  
used anywhere in the normative part of the spec, they just appear in the  
non-normative Appendix B Collected ABNF Syntax for URI. This is clearly  
wrong. Either the productions should be used normatively somewhere, or  
they should not appear in the appendix.

Also, I think the terminology of these productions is confused. AFAICT,  
the productions should be a subset of fragment (identical to query)  
production from RFC3986, not segment.

It's my opinion that we don't need these productions normatively, they  
would only be used for defining validity, which we could do better with  
prose in relation to the namevalues production. The ABNF doesn't express  
all the constraints that we actually want ("note that this does not  
capture the restriction of only one timesegment or spacesegment in the  
axisfragment definition, unless we list explicitely all the cases") so we  
need normative prose anyway unless we want validators to guess at what we  
really mean.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Thursday, 17 February 2011 10:19:32 UTC