On Wed, Aug 11, 2010 at 7:31 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 10:30:23 +0200, Silvia Pfeiffer <<a href="mailto:silviapfeiffer1@gmail.com" target="_blank">silviapfeiffer1@gmail.com</a>> wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Wed, Aug 11, 2010 at 5:04 PM, Anne van Kesteren <<a href="mailto:annevk@opera.com" target="_blank">annevk@opera.com</a>> wrote:</div></blockquote><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, I can see that structured formats with a<br>
clear path for how extensions would be included may not need such a version<br>
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<br>


SVG and CSS inline in future.<br>
</blockquote>
<br></div>
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.</blockquote><div><br></div><div>That goes down the path that Philip suggested. It's a bit artificial and trying to introduce structure in a basically unstructured document.</div>

<div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> While players are transitioning to WebSRT they will ensure that they do not break with future versions of the format.</blockquote>

<div><br></div><div>That's impossible, since we do not know what future versions will look like and what features we may need.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

 There might be enough extensibility in the current WebSRT parsing rules for this, I have not checked.</blockquote><div><br></div><div>Maybe. I guess we can think hard about all the potential things that we might want the format to be extended with in the future and then introduce spaceholders for this. Then we may be ok. But we will never really know until the future tells us. </div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But it is not complex at all and everyone else supports most of the<br>
extensions the WebSRT format has.<br>
</blockquote>
<br>
All of the WebSRT extensions that do not exist in {basic SRT , <b> , <i>}<br>
are not supported by anyone yet.<br>
Existing SRT authoring tools, media players, transcoding tools, etc. do not<br>
support the cue settings (see<br>
<a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt-cue-settings" target="_blank">http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt-cue-settings</a>),<br>
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".<br>
</blockquote>
<br></div>
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.</blockquote>

<div><br></div><div><br></div><div>I'm pretty sure that several will break. We cannot just test a handful of available applications and if they don't break assume none will. In fact, all existing applications that get loaded with a WebSRT file with extended features will display text with stuff that is not expected - in particular if the "metadata" case is used. And wrong rendering is bad, e.g. if it's part of a production process, burnt onto the video, and shipped to hearing-impaired customers. Or stored in an archive.</div>

<div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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"<br>


(maybe rather: rich? capable?) format (i.e. WebSRT).<br>
</blockquote>
<br></div>
I don't think so. It just makes things more complex for authors (learn two formats,</blockquote><div><br></div><div>I see that as an advantage: I can learn the simple format and be off to a running start immediately. Then, when I find out that I need more features, I can build on top of already existing knowledge for the richer format and can convert my old files through a simple renaming of the resources.</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> 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)</blockquote>

<div><br></div><div>If I know from the start that I need these features, I will immediately learn WebSRT.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

, 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.</blockquote>

<div><br></div><div>That's already part of Ian's proposal: it already supports multiple different approaches of parsing cues. No extra complexity here.</div><div><br></div><div>My theory is: we only implement support for WebSRT in the browser - that it happens to also support SRT is a positive side effect. It works for the Web - and it works for the existing SRT communities and platforms. They know they have to move to WebSRT in the long run, but right now they can get away with simple SRT support and still deliver for the Web. And they have a growth path into a new file format that provides richer features.</div>

<div><br></div><div>Cheers,</div><div>Silvia.</div></div>