- From: Anne van Kesteren <annevk@opera.com>
- Date: Wed, 11 Aug 2010 09:04:27 +0200
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. ;-) 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 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. Might be worth reading through some of: http://www.w3.org/2002/09/wbs/40318/issues-4-84-objection-poll/results > 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. -- Anne van Kesteren http://annevankesteren.nl/
Received on Wednesday, 11 August 2010 00:04:27 UTC