On Wed, Aug 11, 2010 at 5:04 PM, Anne van Kesteren <span dir="ltr"><<a href="mailto:annevk@opera.com">annevk@opera.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Wed, 11 Aug 2010 01:43:01 +0200, Silvia Pfeiffer <<a href="mailto:silviapfeiffer1@gmail.com" target="_blank">silviapfeiffer1@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That's a good approach and will reduce the need for breaking<br>
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<br>
better so. But I'd much rather we have it now and can identify what<br>
specification a file adheres to than not being able to do so later.<br>
</blockquote>
<br></div>
XML is also text-based. ;-)</blockquote><div><br></div><div>I mean unstructured text. ;-)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.</blockquote><div><br></div><div><br></div>
<div>
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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> 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.<br>
</blockquote><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Might be worth reading through some of: <a href="http://www.w3.org/2002/09/wbs/40318/issues-4-84-objection-poll/results" target="_blank">http://www.w3.org/2002/09/wbs/40318/issues-4-84-objection-poll/results</a></blockquote>
<div><br></div><div>I guess you mostly wanted me to read <a href="http://berjon.com/blog/2009/12/xmlbp-naive-versioning.html">http://berjon.com/blog/2009/12/xmlbp-naive-versioning.html</a> . :-)</div><div>It's a nice discussion with some good experiences. Interesting that we need quirks mode to deal with versioning issues.</div>
<div><br></div><div>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.</div>
<div><br></div><div>But let's get this resolved. I don't care enough about this to make a fuss.</div><div><br></div><div>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. </div>
<div><br></div><div>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).</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Tue, Aug 10, 2010 at 7:49 PM, Philip Jägenstedt <<a href="mailto:philipj@opera.com" target="_blank">philipj@opera.com</a>>wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That would make text/srt and text/websrt synonymous, which is kind of<br>
pointless.<br>
</blockquote><div class="im">
<br>
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.<br>
</div></blockquote>
<br>
But it is not complex at all and everyone else supports most of the extensions the WebSRT format has.</blockquote><div><br></div><div><br></div><div>All of the WebSRT extensions that do not exist in {basic SRT , <b> , <i>} are not supported by anyone yet. </div>
<div>Existing SRT authoring tools, media players, transcoding tools, etc. do not support the cue settings (see <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt-cue-settings">http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt-cue-settings</a>), 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".</div>
<div><br></div><div>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).</div>
<div><br></div><div>Cheers,</div><div>Silvia.</div><div><br></div></div>