W3C home > Mailing lists > Public > public-media-fragment@w3.org > January 2010

Re: Procesing requirements

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Mon, 18 Jan 2010 20:51:38 +1300
Message-ID: <2c0e02831001172351w4b39a27cyab7170e2db8b34a8@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: public-media-fragment@w3.org
On Mon, Jan 18, 2010 at 2:30 AM, Philip Jägenstedt <philipj@opera.com> wrote:
> Hi working group members,
> I have hacked a bit at the spec and would like feedback. I have "been bold",
> to use a Wikipedia phrase, so I expect that not everyone will agree with
> everything. I would have preferred to put this on a branch and not commit it
> directly, but it seems there's no cvs web interface through which you could
> have seen that. I will revert any changes that meet objections if we can't
> agree on an alternative solution quickly.
> This is what I've done:
> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-name-value-components
> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-name-value-lists
> Note the new reference to ECMAScript, which is the best definition of how to
> decode percent-encoding I could find. I think this *should* be defined in
> the URI spec, but it isn't, so this is the next best thing. The upside is
> that it is by definition compatible with decodeURIComponent, which means
> that implementing the name-value parser in Javacript is trivial.

I'm happy with this. I also like that you turned the document more
into a implementor-readable format rather than a traditional

> I've tried to make the name-value component parsing as close as possible to
> existing server-side languages, having set up and run tests on PHP, CGI.pm,
> JSP (Apache Tomcat implementation), ASP (VBScript) and ASP.NET (C#). One
> particular side-effect of this is that the names are also percent-encoded,
> even though MF strictly speaking has no need for this. This is just a
> processing requirement though, we can still make it invalid to use
> percent-encoding where it isn't needed (in fact I think the URI spec may
> already say this).

I agree.

> We might still have to discuss if we want to tolerate some invalid
> percent-encoding and if non-UTF-8 encodings should be possible. (I think
> both are a bad idea.)

How is non-UTF8 encoding for other URI schemes dealt with?

> In order to write these sections, I needed to break apart the ABNF section
> to make each production linkable. Since other W3C specs seem to use EBNF I
> did this too, which amounted to replacing / with |. If you would rather use
> ABNF I can change that back. Pay special attention to the note at
> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#fragment-structure

I care about it being consistent - I don't mind the EBNF specification
over ABNF.

> Effectively I have broken the connection that existed before between the
> name-value syntax and the syntax of each dimension. We need to go over the
> validity constraints and make sure that they still make sense.
> Plenty of cleanup to the ABNF is possible (e.g. the *prefix productions are
> quite useless now), but I've left everything for now.

I don't think they are useless. The naming of the dimensions has to be
done somewhere.

> Also, utf8string isn't
> needed, as percent-encoding takes care of whitespace and mandatory single
> quotes aren't really useful as far as I can see.

OK, fair enough.

> I hope this reorganization will help when we define how to process some HTTP
> headers, i.e. that we can reuse the #processing-name-value-lists algorithm.
> I marked some sections that only contained discussion non-normative.
> P.S. Should I add my name to the contributor list, or does that have some
> special meaning?

Not sure, that's up to Raphael. :-)

Received on Monday, 18 January 2010 07:52:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:44 UTC