[Doc-SIG] Re: DPS file extensions

[Tony J Ibbs (Tibs)]

I said:
> > Could I suggest that we coin a standard extension for
> > DPS/reST files?

David replied:
> I suppose that's possible, but I'd rather not. The reason I gave the
> files .txt extensions in the first place was for cross-platform
> compatibility. I don't need extensions on my home machine at all.

I assume on a Mac one doesn't use extensions, and adds them when
transferring to other systems (or interfacing with them).

But I wasn't addressing files on Macs - I was thinking about the systems
*I* use, since that's what I'm familiar with.

> The Mac treats metadata sensibly;

I've never used Mac (well, not to count), but have used RiscOS, VMS and
NeXTStep, as well as Unixes and (early on) a mainframe operating system
at Cambridge which didn't *really* have a directory structure as such -
files and libraries. So I have to be agnostic on how one should treat
metadata (there are obvious problems in having two "files" for every
file, but then VMS had problems with having many files not actually
start at the start of file, so to speak - but then, I *liked* the VMS
approach (about many things, in fact)).

On the other hand, I (me, speaking for myself) would indeed want a
different icon for reST text files on a Mac - and I *do* want such on my
other systems, which means that a different extension is a useful tool.

>  metadata embedded in the filename is a crude hack that MacOS
> avoids (or avoided; reportedly, MacOS X seems to have caved in
> to peer pressure).

Hmm - as I understand it it's following on from NeXT in many ways (which
means that applications are rather neat - a whole directory to stuff
things in!), which means that it's (in some sense) a "Unix". So it
presumably either has to use extensions, or "guess" the file type by
looking inside it.

Having owned a NeXTStation (the Bang and Olufsen approach to computers -
seriously neat - it was also *very* impressive how it assembled out of
the box and, well, just worked when switched on!) I must admit to
hankering after MacOS X a bit.

> But I work on different platforms and I'd much rather I
> (and you!) get a nice text file icon than a blank one.

I thought that nowadays this was seriously not a problem. On Debian the
installer can introduce something, but Unixes are dodgy on this sort of
thing (it's very dependent on how one is *looking* at the desktop and
icons - with KDE, fvwm2, TkDesk, whatever). On Windows it's a simple
(well, ish) matter of telling the system to use an icon and an
application - so yes, that may involve the registry, but so does
everything else!

> We'd all have to teach our systems that '.rest' means '.txt'. Most
> people won't, and I don't want to add Windows registry fiddling to the
> distutils scripts.

Hmm - I bet it happens for some purpose at some time. Anyway, I would
actually hope that docutils will become part of the standard library,
and then the Python installer can do it...

> reStructuredText is a *form* of plaintext, so the .txt extension is
> appropriate.

XML is a form of plaintext, config files are a form of plaintext, *lots*
of things are forms of plaintext. OK, I know I'm being awkward there,
but I seriously *do* want a way of telling, from outside the text file,
that the author intended that it be processable with DPS. And the
standard (as in "historical, on many platforms, over much time" - yes, I
know Macs and RiscOS are different) way of doing that is with an
extension.

Of course, I'm also used to working with various different transfer
formats, many of which are "sort of" text files - so I don't
particularly expect that I will always have icons or registered
applications for .sif, .iff, .ntf, .citf, and so on and so on - but the
use of an extension to indicate what the file *is* is still of absolute
priority. On extension-using filesystems like VMS and Unix (and
relatives) the extensions are for the *users* convenience in
discriminating amongst files. Who cares if the system knows what they
mean - it's another bit of convenience for the user.

I think that's the gist of what I'm trying to convey - on a Unix or NT
system, the extension conveys truly useful information, whether the
*system* recognises it or not. Discriminations like .latex, .tex, .log,
.toc, .config, .notes, .xml, .xsd, .dat, .err, .faq (some of those may
be familiar!). It's quite clear that *some* of those may be just text
files with a slightly special content. Some of them are also variations
on each other. But the extension lets you *know* that. Otherwise one is
reduced to putting that information in the filename itself, and that's
naff and also fails to establish a convention (it has to be something as
strictly regimented as a PEP for it to work).

I also think that if (although I doubt it) we ever have alternatives to
reST, it would be very awkward if you couldn't tell which file was done
with which system from outside (imagine if someone is maintaining STNG,
STClassic and reST documents! They're close enough at a quick glance at
the text to cause confusion.)

Sorry - this has gone on long enough. And I've probably overstated my
case.

Tibs

--
Tony J Ibbs (Tibs)      http://www.tibsnjoan.co.uk/
Give a pedant an inch and they'll take 25.4mm
(once they've established you're talking a post-1959 inch, of course)
My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.)