RE: Timed tracks

>>On the open web, though, you can't target a single runtime, and you have no control over what your users will use to receive your data.
>>So you have to make sure that everyone supports everything in the same way, which is a ton more work.

Well, the web hasn’t exactly a stellar record in that department, but we will gloss over that since clearly HTML5 is going to be completely interoperable right out of the gate. But interoperability is also important for TTML, which is why there is a fairly comprehensive test suite.  When you have decided what WebSRT semantics are, written them down precisely enough for interoperability, and created a test suite that tests for it, let's pick up this discussion again.

>>So, that's why the fact that some plugins support TTML without XSL:FO isn't necessarily relevant to the discussion at hand.  ^_^
Correct, XSL:FO isn’t relevant at all.


-----Original Message-----
From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Tab Atkins Jr.
Sent: Thursday, May 06, 2010 11:35 PM
To: Frank Olivier
Cc: Geoff Freed; Maciej Stachowiak; Philippe Le Hegaret; Edward O'Connor; Ian Hickson; public-html@w3.org
Subject: Re: Timed tracks

On Thu, May 6, 2010 at 3:02 PM, Frank Olivier <franko@microsoft.com> wrote:
> " Flash and Silverlight aren't concerned with being interoperable.  They can rely on hacking something together that works well enough.  The open web works somewhat differently."
>
> I'll rewrite my point...
>
> Some existing web runtimes* use TTML. XSL:FO is not in those web runtimes. People who author web experiences using those web runtimes seem to be able to create something that meets their needs with that level of TTML support. We should learn from that.
>
>
> *Those-plugins-who-must-not-be-named ;)

I'm not actually meaning to disparage the plugins here.  ^_^  What I mean is exactly what I said, though - people aren't going to care that Flash and Silverlight don't treat the same files precisely the same.
They just use whichever one they happen to care about, tweak the file until it works sufficiently, and then deploy on the plugin across all platforms that support it.  It's nearly the same problem that people have changing their mental outlook from desktop applications to webapps.  In desktop apps, you're in a place where strict parsing is okay and versioning works ok because you only care about the version of the tools that you personally are using, and you just compile to a fairly agnostic machine code.  Whereas in webapps, the user is the one who's tools matter, and so you need to design the ecosystem in such a way that is tolerant to "errors" (because future changes are errors to yesterday's tools) and limits versioning (because data never really disappears, so every version has to be supported forever).

The analogy is very similar here.  When you're targetting a single runtime like Flash, you can depend on everyone working similarly.
Thus, the Flash creators don't actually have to support XSL:FO or similar; they can just create some ad hoc "good enough" mapping.
Silverlight can do the same thing for itself.  If anyone were to migrate from Flash to Silverlight, they might have problems, but that is rare enough that it's not an important deal for either plugin.

On the open web, though, you can't target a single runtime, and you have no control over what your users will use to receive your data.
So you have to make sure that everyone supports everything in the same way, which is a ton more work.

So, that's why the fact that some plugins support TTML without XSL:FO isn't necessarily relevant to the discussion at hand.  ^_^

~TJ

Received on Thursday, 6 May 2010 22:59:30 UTC