Re: HTML 5, SMIL, Video

Hi Dick,


On Sat, Feb 20, 2010 at 7:27 PM, Dick Bulterman <Dick.Bulterman@cwi.nl> wrote:
> Hi Silvia,
>
> Responding to your recent comments:
>
>> Is there
>> anything that smilText does that is above what DFXP does?
>
> Sure:
> a) it can be used as an in-line and external formal out of the box
> b) it is steamable
> c) it uses a significantly simpler syntax
> d) it allows a mix of absolute and relative timing
> e) it provide primitives for text motion (crawling, rolling, etc)
> f) it has supports conventional HTML structuring and styling
>   primitives

I'll leave it to the DFXP experts to comment on this.


>> I don't see any advantage of this markup:
>> <smilText dur="6s">
>>        Hello<br/>world!
>>        <tev next="2s"/>
>>        How are you today?
>>        <clear begin="4s"/>
>>        I gotta go now!
>> </smilText>
>>
>> over this markup:
>> 1
>> 00:00:00,000 --> 00:00:04,000
>> Hello world!
>>
>> 2
>> 00:00:02,000 --> 00:00:04,000
>> How are you today?
>>
>> 3
>> 00:00:4,000 --> 00:00:06,000
>> I gotta go now!
>>
>> If anything, the SRT markup is more readable.
>
> Here is my summary of the advantages in this example for smilText
> a) it is an XML format
> b) it can be plugged directly into HTML with no new syntax
> c) it has an architecture that allows structuring, styling, motion and other
> forms of manipulation (roles, etc) to be added easily
> d) it is less dense than SRT (in this example, more than 10%)
> e) it is less prone to error in hand-editing
> f) because the ordering of content can be realive, the contents can
> be generated on-the-fly, with inserts possible
> g) the 'begin' attribute can also be used for event-based scheduling
> of text objects; since these also can have ID's, it can also hurl events to
> an outside context -- this has the nice ability for users to control the
> flow and tempo of content delivery. (A longer term benefit.)
>
> It has also already gone thru W3C standardization (there is a test suites,
> there have been multiple implementation tests, it has passed the entire
> process), but I don't think that you consider this important.
>
> In short: everything that you need to add to SRT to make it useful is
> already in smilText. And everything that SRT can do (and much more) can be
> done by smilText.

I think there is a fundamental misunderstanding: there will be nothing
added to SRT - it will be used as is, basically as specified here:
http://en.wikipedia.org/wiki/SubRip. And you are right, I can turn all
of the advantages that you have mentioned of smilText over SRT into a
disadvantage, except for b) where directly plugging into HTML requires
cue ranges or something similar. But as I have said earlier, there
will likely not be a merging of a different xml format with HTML to
provide this functionality, since it creates too many issues.


> Of course, these are only advantages if you want them to be. You can always
> come up with a stream of arguments why extensibility is not important
> because nobody uses it now, why XML is not important, why whatever is not
> important. If I look at the a11y needs, coupled with the needs to support
> generalized incidential timed text within a document, then the choice is not
> very difficult: I'd go for a mix of smilText and DFXP.

Let's have the discussion be about the virtues of smilText then. And
let's stop beating SRT, which has more than one thing going for it.


> (Since joining the a11y list is not a trivial process, I'd one again
> appreciate it if someone would foward this message -- thanks!)

 You just need to contact Michael Cooper or Mike Smith to become a
participant of HTML Accessibility Task Force. I think that Philip
replied shows it actually did go through.

Cheers,
Silvia.

Received on Saturday, 20 February 2010 08:44:34 UTC