[whatwg] Fwd: Discussing WebSRT and alternatives/improvements

[Anne van Kesteren]

On Wed, 11 Aug 2010 10:30:23 +0200, Silvia Pfeiffer  
<silviapfeiffer1 at gmail.com> wrote:
> On Wed, Aug 11, 2010 at 5:04 PM, Anne van Kesteren <annevk at opera.com>  
> wrote:
>> That is the approach we have for most formats (and APIs) on the web  
>> (CSS, HTML, XMLHttpRequest) and so far a version identifier need (or  
>> need for a replacement) has not yet arisen.
>
> There are Web formats with a version attribute, such as Atom, RSS and  
> even HTTP has a version number.

None of these have really executed a successful version strategy though.  
Syndication in particular is quite bad, we should learn from that.

See e.g. http://diveintomark.org/archives/2004/02/04/incompatible-rss


> Also, I can see that structured formats with a
> clear path for how extensions would be included may not need such a  
> version
> attribute. WebSRT is not such a structured format, which is what makes  
> all the difference. For example, you simply cannot put a new element  
> outside the root element in XML, but you can easily put a new element  
> anywhere in WebSRT - which might actually make a lot of sense if you  
> think e.g. about adding
> SVG and CSS inline in future.

There is all kinds of ways we could address this. For instance, we could  
add a feature that makes a line ignored and use that in the future for new  
features. While players are transitioning to WebSRT they will ensure that  
they do not break with future versions of the format. There might be  
enough extensibility in the current WebSRT parsing rules for this, I have  
not checked.


> It doesn't take into account good practice in software development,  
> though, where there is a minor version number and a major version  
> number. A change of the minor version number is ignored by apps that  
> need to display
> something - it just gives a hint that new features were introduced that
> shouldn't break anything. It's basically metadata to give a hint to
> applications where it really matters, e.g. if an application relies on  
> new features to be available. A change of major version number, however,
> essentially means it's a new format and thus breaks existing stuff to  
> allow the world to move forwards within the same "namespace" and  
> experience
> framework.

What works for software products does not work for formats with universal  
deployment on which we want to get interoperability between various  
vendors. They are very distinct.


>> But it is not complex at all and everyone else supports most of the
>> extensions the WebSRT format has.
>
> All of the WebSRT extensions that do not exist in {basic SRT , <b> , <i>}
> are not supported by anyone yet.
> Existing SRT authoring tools, media players, transcoding tools, etc. do  
> not
> support the cue settings (see
> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt-cue-settings),
> or parsing of random text in the cues, or the voice markers. So, I  
> disagree with "everyone else supports most of the extensions of the  
> WebSRT format".

Do they throw an error or do they just ignore the settings? If the latter  
it does not seem like a problem. If the former authors will probably not  
use these features for a while until they are better supported.


> Also, what I man with the word "complex" is actually a good thing: a  
> format that supports lots of requirements that go beyond the basic ones.  
> Thus, it's actually a good thing to have a simple format (i.e. SRT) and  
> a "complex"
> (maybe rather: rich? capable?) format (i.e. WebSRT).

I don't think so. It just makes things more complex for authors (learn two  
formats, have to convert formats (i.e. change mime) in order to use new  
features (which could be as simple as a <ruby> fragment for some Japanese  
track), more complex for implementors (need two separate implementations  
as to not encourage authors to use features of the more complex one in the  
less complex one), more complex for conformance checkers (need more code),  
etc. Seems highly suboptimal to me.


-- 
Anne van Kesteren
http://annevankesteren.nl/