Re: Resolving ISSUE-19

On Thu, Feb 17, 2011 at 9:18 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> 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:
>>>
>>> * 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.

Hmmm, yeah.... (except that pchar actually covers ":").


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

segment seems to be a weird thing to choose from RFC3986.
We should add:
   query         = *( pchar / "/" / "?" )
and then maybe we should make
   mediafragment = fragment | query
which makes it more correct.


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

I don't have an issue if they are not provided normatively and are
incomplete in those dimensions that they cannot express. I'd rather
keep them in the document though because they can help people get a
quick grasp on what's going on, even if they don't answer all the
questions.

Cheers,
Silvia.

Received on Thursday, 17 February 2011 12:55:41 UTC