- From: Bert Bos <bert@w3.org>
- Date: Sat, 26 Mar 2011 13:21:34 +0100
- To: www-font@w3.org
On Mar 16, 2011, at 18:49, Chris Lilley wrote: > On Wednesday, January 12, 2011, 4:16:26 PM, Bert wrote: > > BB> 9) The specification is called "1.0" but the actual format contains > BB> neither a version number, nor a way to define extensions. It is > BB> probably a good thing that there is only one WOFF format. It means > BB> that a correct implementations cannot be incompatible with another > BB> correct implementation, just because one was written later than the > BB> other. But why then is there that "1.0" in the title of the spec? > > BB> (The optional metadata has a version. Is that what the "1.0" > BB> corresponds to? Although that part of the file can be ignored by many > BB> kinds of implementations, it is still a pity that there can, in the > BB> future, be different formats that are all called WOFF, with the same > BB> file extension, the same magic string, and, probably, the same MIME > BB> type.) > > Hello Bert. > > It is true that many specifications forget to add a version number for the first one. Only when it comes time to make a revised version do they remember and create a 1.1 or 2.0 or whatever. > > So this specification follows the recommendation in 'Architecture of the World Wide Web, Volume One' as follows: > > "Good practice: Version information > A data format specification SHOULD provide for version information." > > http://www.w3.org/TR/webarch/#versioning > > thus, the specification has a version number. I agree that the *specification* should have a version number. All W3C specs carry a date to serve that purpose. I don't agree that the format defined by the spec should have a version number. If you have two formats called XHTFG and ERGB, it is clear that they are different formats and if you try to parse both with a single program, you know what you're doing. But if you have two formats called ERGB 1.0 and ERGB 2.0, things aren't so clear. You may have software that generates one and software that reads the other and you think they understand each other, but almost certainly there are obscure incompatibilities. In practice most software will support neither full 1.0 nor full 2.0, so if something doesn't work, finding the reason can become quite difficult: is it a documented limitation of the software, an undocumented bug, an incompatible change between the versions that is documented, or an incompatible change that the spec authors forgot to document (or did't even notice)? My advice if you ever need to change WOFF: don't change the version number but change the name instead. > You are correct that the WOFF header does not have a version number; we hope to be able to extend it in a backwards-compatible way. > > You are also correct that the metadata *does* have a version number. it is possible that we would introduce new, backwards-incompatible metadata in the future. We don't plan to know, as the WG is chartered to avoid breaking backwards compatibility so is documenting current deployed practice. But we leave tat open, hence a version number in the metadata instance. This is safe, because the metadata need not be read by font-using programs. > > Please let us know if this response does not answer your comment. I know how tempting it is to "just" add some nice feature to a format and call it version 2. E.g., the GNU extensions to the C compiler or to AWK are very handy (and I can't help using them). Their usefulness is only exceeded by the frustration when you switch to a different OS and find that nothing works... I'm hoping that at some point people will see reason and stop creating versions of formats. But I know it is common practice and I can't blame you for doing what everybody else does. Bert -- Bert Bos ( W 3 C ) http://www.w3.org/ http://www.w3.org/people/bos W3C/ERCIM bert@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
Received on Saturday, 26 March 2011 12:22:03 UTC