[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Conforming OpenDocument Text Document, etc.
On Mon, 2009-03-16 at 00:10 -0400, firstname.lastname@example.org wrote: > Andreas J Guelzow <email@example.com> wrote on 03/15/2009 > 11:31:34 PM: > > > > > On Sun, 2009-03-15 at 22:39 -0400, firstname.lastname@example.org wrote: > > > To accomplish there we need to either ensure that producers write the > data > > > consistently, or that consumers use a more complicated heuristic to > > > determine document type. I'm inclined to believe that this will work > best > > > if we require both. > > > > I find it greatly disturbing that the standard would try to force an > > application to show certain latin letters in a file name just to have > > that file to be considered a conformant document. > > > > That's the way the dominant operating system on the planet does it. I > find it disturbing as well, but it is the least-bad approach that works > with all of the OS's is broad use today. This "dominant operating system" of course also hides those extensions, likely for the reason that the extension is really not intended for the user. > If you have a better idea, then > I'm all ears. But requiring an operating system to unzip a file and parse > the XML in order to determine whether to show a text icon versus a > spreadsheet icon for the file in a file explorer GUI -- that isn't going > to work well. If on my machine (running linux) I create an ods file and then rename the file by deleting the extension, the system still knows that this is an ods file. So things are not quite as black and white as you suggest. Of course, it isn't really the issue whether some OS requires an extension to determine the file type, or whether it chooses to unzip the file and parse the content or whether it keeps track of the file type in some other way, the issue at hand is whether a file without the ".ods. extension is still a conformant document or not. Your suggestion is that simply because of the absence of an extension it stops being a conformant file. I find that simply unacceptable. > > > Perhaps if you weren't used to writing in the latin alphabet it would be > > more obvious that having such cryptic (and in the user's language likely > > meaningless) letter combinations attached to a file name. > > > > End users don't necessarily need to see or deal with file extensions. For > example, Windows, since XP at least, hides extensions by default in the > GUI. It is still a hack and not as clean as other OS's. But I don't see > how to avoid dealing with it in ODF. This really should have nothing to do with ODF, which should be a filetype describing the content of files rather than a file naming scheme. > And remember, the file extensions are already part of our MIME content > type registration. So you'll see Apache servers set up to serve up ODF > documents with the correct MIME type based on looking up the file > extensions. Apache servers can easily be configured to serve up odf documents with other extensions or no extensions at all. > That breaks if documents are not saved with consistent file > extensions in the first place. how does it? I can configure my apache server to figure out mimetype differently. > It is all one giant hack, but a > well-understood one at least. I'm not sure there is much we can do about > it. Well, we can stay away from it! I se absolutely no reason why odf conformance must be linked to file naming. > > Sure, we could eliminate this from the conformance requirements. But if > someone takes a ODF presentation file and renames it with an .ods > extension, it will display with the wrong icon in Windows, how is this an ODF problem? > it will be > served up with wrong content type in Apache not necessarily > it will launch with the wrong > application if you receive it in an email attachment, that depends on your configuration > and it will do > strange things if you try to load it in Gnumeric or any other > ODF-supporting spreadsheet. Both Openoffice Calc and current gnumeric svn do not require an ods extension to open an ods file. > Personally I think this kind of inconsistency > is something we should try to discourage, and a conformance requirement in > favor of consistency is the way to do it. While I could see discouraging an ods file to have an odf, I really do not see an inconsistency in the case of files without extension. Andreas -- Andreas J. Guelzow Concordia University College of Alberta