[whatwg] Fwd: Discussing WebSRT and alternatives/improvements

[Silvia Pfeiffer]

On Wed, Aug 11, 2010 at 5:04 PM, Anne van Kesteren <annevk at opera.com> wrote:

> On Wed, 11 Aug 2010 01:43:01 +0200, Silvia Pfeiffer <
> silviapfeiffer1 at gmail.com> wrote:
>
>> That's a good approach and will reduce the need for breaking
>> backwards-compatibility. In an xml-based format that need is 0, while with
>> a text format where the structure is ad-hoc, that need can never be reduced
>> to 0. That's what I am concerned about and that's why I think we need a
>> version identifier. If we end up never using/changing the version
>> identifier, the
>> better so. But I'd much rather we have it now and can identify what
>> specification a file adheres to than not being able to do so later.
>>
>
> XML is also text-based. ;-)


I mean unstructured text. ;-)



> But more seriously, if we ever need to make changes that would completely
> break backwards compatibility we should just use a new format rather than
> fit it into an existing one.



That's exactly the argument I am using for why WebSRT should be a new format
and not take over the SRT space. They are different enough to not just be
versions of each other. That's actually what I care about a lot more than a
version field.



> 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. 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.



> Might be worth reading through some of:
> http://www.w3.org/2002/09/wbs/40318/issues-4-84-objection-poll/results


I guess you mostly wanted me to read
http://berjon.com/blog/2009/12/xmlbp-naive-versioning.html . :-)
It's a nice discussion with some good experiences. Interesting that we need
quirks mode to deal with versioning issues.

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.

But let's get this resolved. I don't care enough about this to make a fuss.

So ... if we do everything possible to make WebSRT flexible for future
changes (which is what Philip proposed) and agree that if we cannot extend
WebSRT in a backwards compatible manner, we will create a new format, I can
live without a version attribute.

I am only a little weary of this, because already we are trying to make SRT
and WebSRT the same format when there is no compatibility (see below).



>  On Tue, Aug 10, 2010 at 7:49 PM, Philip Jägenstedt <philipj at opera.com
>> >wrote:
>>
>>> That would make text/srt and text/websrt synonymous, which is kind of
>>> pointless.
>>>
>>
>> No, it's only pointless if you are a browser vendor. For everyone else it
>> is a huge advantage to be able to choose between a guaranteed simple format
>> and a complex format with all the bells and whistles.
>>
>
> 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".

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).

Cheers,
Silvia.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100811/38297c62/attachment-0002.htm>