Re: HTML 5, SMIL, Video

On Sat, 20 Feb 2010 16:27:38 +0800, 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
>
> Other than that, it was designed to be largely compatible with the  
> semantis of DFXP so that the breadth of DXFP could be used when  
> appropriate. In many ways, our thoughts were the same as yours: the  
> issue in not DFXP or smilText, but DFXP AND smilText. I think that the  
> same is true for this group.
>
>> 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.
>
> 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.
>
> I'd be interested to hear what others think on this issue.
> (If everyone's mind is already made up -- which is sort of the  
> impression that I get -- then it is a shame to waste our collective time  
> on this.)

Not supporting SRT on the basis that format X can do more isn't  
reasonable. SRT is the simplest possible format and something that can be  
implemented in browsers with quite small effort spent on the format  
itself. There will be no extensions of the format -- it is what it is.  
Although only actual implementation is an actual commitment, I think it's  
the format that stands the best chance of being implemented in multiple  
browsers in the coming year(s).

Personally I haven't made up my mind on any other format. I don't  
particularly like DFXP because it something like an interchange format  
that tries to do everything. smilText I know very little about but I  
strongly doubt there is a point in supporting both DFXP and smilText -- if  
either.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Saturday, 20 February 2010 08:40:24 UTC