Re: Spec layering: name-value pairs and beyond

On Wed, Mar 10, 2010 at 1:57 AM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Tue, 09 Mar 2010 18:27:27 +0800, Philip Jägenstedt <philipj@opera.com>
> wrote:
>
>> On Tue, 09 Mar 2010 16:18:03 +0800, Philip Jägenstedt <philipj@opera.com>
>> wrote:
>>
>>> I will commit this to CVS for further editing unless
>>> there are objections during the day.
>>
>> I have already committed this. Note that I did *not* update the section
>> "Collected ABNF Syntax", that should really be automatically generated
>> anyway.
>
> I changed the name of the production from mediafragment to namevalues for
> clarity. My intention is to use the ABNF production rules to rewrite the
> name-value list processing algorithm to something like this.
>
> 1. for each non-overlapping substring in input that is a valid production of
> the namevalue syntax:
> 1.1. let pct-name be the substring matching the name production.
> 1.2. let pct-value be the substring matching the value production.
>
> The rest (percent-decoding and UTF-8 decoding) would still be the same, but
> I'm happy to rely on ABNF to avoid having to define what string splitting
> means, etc. If there is a declarative language (ABNF or otherwise) that can
> express that percent-decoding and and UTF-8 decoding be performed, I'd be
> happy to use that instead.
>
> Note: By definition the input is a valid production of namevalues, if the
> input is from the fragment or query component of a URI.

I believe Yves looks at the production rules as generic rules how to
create such a URI rather than how to parse such a URI.

I think we may need to make two different sections for these two
approaches, since when you are creating a URI, you have to UTF-8
encode and percent-encode etc, while when you are parsing, you do the
opposite (you decode and you would probably not decode UTF-8, and
possibly not decode percent-encoding before doing something with it,
such as sticking the values in a HTTP header.

Cheers,
Silvia.

Received on Tuesday, 9 March 2010 20:21:02 UTC