Re: Netscape 4.0 press release at their server

   From: "David Perrell" <davidp@earthlink.net>
 
| BUT, aren't there alternatives to a central database? File types have
| become much less proprietary since the days of .PCX (the worst
| compression scheme ever invented a 'standard'?! -- damn good thing the
| PC side stayed chaotic!) and some (Tag Image File Format being
| especially notable) are structured such that applications can recognize
| and deal with even enhanced versions of the format, no matter what
| system the file was created on. Can't universal file types evolve such
| that a central database is simply not necessary? Why should
| standardization revolve around a numerical code with no inherent
| meaning?
---

I guess I don't understand your argument - TIFF has an embedded file
type code (the same kind of thing I was talking about).  And no, you
don't need new codes for new versions if the format is self-describing
and the new versions stay within the same self-description standard.
You only need a new type (or to use a type+version coding) if the
types are incompatible between versions.  TIFF isn't (at least at one
level), though in terms of vectoring a double-clicked icon to the
appropriate application, TIFF is of limited help, since the application
may need to do substantial parsing before it can decide whether it can
handle the file or not, which is why I suggested the utility of having
version numbers.

---
| Version numbers of such file types do _not_ need to be part of a
| filename extension. As an 'open' file type evolves, programming-related
| information would be readily accessible.
---

Well, maybe.  In any case, you *do* need version numbers for many other
kinds of file types that haven't (or won't in the future) evolve so
openly.  I'm not sure you're better off in TIFF for not having a simple
way to judge compatibility from the outside (without a lot of
processing).

Remember, there are two uses for the typing - one is to let an
application decide whether it can handle the file, the other is to
determine, from the type, what application to hand it to.  Parsing works
OK for the first use, though somewhat more slowly and with ambiguity
issues if the application can support different versions in different
ways and a particular file has some attributes of one case and some of
another; it works less well for the latter (though you could still
handle it by offering the file to all the potentially accepting tools
and letting them decide individually whether to say they can handle it,
then let the user decide which of the candidates to use).

scott

--
scott preece
motorola/mcg urbana design center	1101 e. university, urbana, il   61801
phone:	217-384-8589			  fax:	217-384-8550
internet mail:	preece@urbana.mcd.mot.com

Received on Thursday, 24 October 1996 17:53:19 UTC