W3C home > Mailing lists > Public > public-media-fragment@w3.org > December 2009

Re: Processing requirements

From: Jack Jansen <Jack.Jansen@cwi.nl>
Date: Wed, 2 Dec 2009 21:51:47 +0100
Cc: "Media Fragment" <public-media-fragment@w3.org>
Message-Id: <B43B73A7-CFA8-4AFB-907D-C15B1FF1363E@cwi.nl>
To: Philip Jägenstedt <philipj@opera.com>

On 2 dec 2009, at 12:55, Philip Jägenstedt wrote:

> Following up on my previous email and todays IRC-conference (for me).
> I won't get involved in the editors stylistic choices between ABNF, equivalent parsing algorithms (only the side effects of which are normative) or any other spec technique, but would request that at least the following are defined:
> 1. Splitting of name-value pairs
> The current ABNF only allows joining timesegment / spacesegment / tracksegment by "&", which means that e.g. #t=5& is not allowed because it has a trailing &, which is very easy to get by accident if you write a script like this:
> urifrag = '#':
> for d in dimensions:
>    urifrag += d + '&'

I'm not thrilled by this idea. The web has a long history of features where an initial implementation was syntactically forgiving because it was deemed to be user-friendly at the time. Many of these have been causing endless headaches until today. Think of the ability to use filenames (especially Windows filenames) in the URL-bar, or in attributes in the HTML code. Think of global variables in JavaScript.

> This specific case *can* be fixed in the ABNF, but leads into the next issue:
> 2. Handling of unrecognized syntax
> This means that #u=12&t=5 can still proceed to getting the time offset 5. Not allowing this makes it impossible to extend MF in the future as any new syntax is invalid per the current spec.
> As a necessary (but unsightly) side-effect, anything between & that isn't recognized should be ignored, including the empty string. Thus a conforming UA should be able to handle this extreme:
> #&&=&=tom&jerry=&t=34&t=meow:0# (time offset 34 seconds)

This is a very difficult issue, we already touched on it in the last teleconf. The problem is that there are two types of future extensions, and they need opposite solutions. Some future attributes should preferably be ignored by older implementations, think of a hypothetical "preferred-languages=english-french-german" attribute. Other future attributes should lead to an error if the older implementation doesn't understand the attribute, think of "rating=pg" (which would return only tracks with a rating of G or PG, supposedly).

But: I have an idea that may be a solution to this, loosely based on the SMIL skip-content attribute (http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-content.html#adef-skip-content). If we add an attribute that tells older implementations what to do (ignore unknown attributes, or raise an error) we could have our cake and eat it. The first example would then usually be coded as "....&preferred-languages=english-french-german&unknown=ignore", the second as "....&rating=pg&unknown=error". The only remaining question is now: what is the default value for the unknown attribute.

What do y'all think? Would this fly?

> 3. Processing order
> As an example, what is the result of processing #t=5&t=10 ? I think the result should be 10, because it is what you would usually implement by mistake if not making a conscious choice.
> The other option is that duplicating any dimension should cause the entire fragment to be ignored, which I do not support.

This is somewhat similar to the first case, but much more serious. Personally, I am heavily opposed to letting over-specified do anything but return a hard error. If the URL was generated by a program this means the program is buggy, if it was done by a human, similarly, the person should be taught to mend their ways. Guessing that "the last one is probably what was meant" is a random choice. Actually, I would argue that if it was a human who created this specific URL the "right thing" to do is probably to start at second 15. (I send you a fragment starting at second 5. You don't like the first 10 seconds of that clip, so before you forward it to another friend you tack a "&t=10" to the end).

> I trust none of this should be controversial. By having well-defined processing we can avoid some of the reverse-engineering and defacto-but-not-not-speced behavior that inevitably happens otherwise. After these parts have been written, I will be happy to review the spec again.

Except for the non-controversial part (should be clear from the above:-) I fully agree.
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman
Received on Wednesday, 2 December 2009 20:52:46 UTC

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