Arguments against <prefetch>

In my opinion, <prefetch> element should not be included in SMIL Timesheets spec. The main reason is based on the principle that a technology should try to *predict* what to do, instead of humans having to manually specify every detail on what to do. Thus, the Timesheets engine should automatically predict when an element should be prefetched, based on the time schedule.

This approach has two benefits compared with manually defining prefetching:

• developers are freed from a task that can be considered unnecessary to do manually
• the timesheet markup is cleaner, so it's easier to understand and maintain.

This is possible when an item's 'begin' depends on other items begin/end or it's a scheduled value. (Even for event-values it'd be possible to define probability of activation based on some clues). For instance, in a 'seq' container, the engine knows that when a time node is activated, it's very likely that the next time node scheduled is going to be activated. So the engine should ask the User-Agent (browser) to prefetch the resource.

That is, the User-Agent should provide a function for prefetching resources, available to be called by external code. Something like:
prefetch(resource, options)
And it'd be the browser who decides about parameters such as mediaTime, mediaSize, or bandwidth-- those parameters should not be the responsability of the application developer. The browser can make better decisions about their values based on the device and context.

In HTML5 draft, there is a proposal for prefetch, using <link> elements. This feature has been available in Firefox already. Therefore, it's my opinion that we should try to embrace that functionality. Additionally, for the HTML5 Prefetch draft, I'd propose that browsers provide a Javascript function to prefetch resources, in addition to the <link> element; this would avoid the need to create a <link> node from Javascript code for the purpose of prefetching.

To understand the point made by my proposed approach, see the example of <prefetch> included in the SMIL Timesheets draft [ Link ]. In that example, one can see that the timesheet markup becomes more difficult to read, because timing/sync definitions are mixed with the <prefetch> elements.

In conclusion, a SMIL Timesheet implementation could "predict" activation of items, and would ask the browser to prefetch the resource. The browser can decide the optimal values of parameters for prefetching, instead of giving that responsibility to developers.

References:
[1] Prefetch element in SMIL Timesheets draft:
http://www.w3.org/TR/timesheets/#smilTimesheetsNS-Prefetch
[2] Link Prefetch in Firefox, and proposed for HTML5:
https://developer.mozilla.org/en-US/docs/Link_prefetching_FAQ