Dotted Prefix Extensions

Dotted Prefix Extensions

The addition of prefix extensions to a file extension or other name to enable its use via appropriate Software or to mark events or states of artifacts, particularly what I have called HyperArtifacts.

Because of ongoing issues with the way various servers and systems handle the dot extensions, and possiblility of malforming file names, and the introduction of which causing mishandling of the files so named, the following, while interesting, may not be found by some users as a practical way of handling the problem it is supposed to fix. See the bottom of the page for links which illustrate this. -- DonaldNoyes 200809221509.m06

One Example: A file that contains flat file information in a text only format can have an extension of .txt, but might exist in other extensions such as .cpp .c .bas .wik .h .for .cob - etc. There are a number of programs available to view and edit these text files. While some of these such as .c .cpp .h, might preferably be handled in an IDE, there are occasions when features present in another text processing program might present advantages. The double-click provision found in file-managers allows the selection of but one processing program per extension. The addition of a second (prefixed) extension could enable an interface to allow the selection of a particular compatible program to view/edit/execute the file. The interface could show all programs capable of interaction with the file and can allow indexing and grouping of files into related packages.

Supposing the prefix-extension for a flat text file might be .ftx, a .cpp file could be named main.ftx.cpp.

In some cases the .ftx file might also be executable, as in a perl or python script, in which case the interface would include viewing, editing, or execution in the selection list{s).

Also, the same file might be part of a package

It also aids in versioning Implementations:

Are there implementations which exist or that are planned that would provide these option or similar options?

Discussion:

Um, those are suffixes, not prefixes. A prefix would the txt.<filename>

They are prefixes to the operating system extension <filename><dpe3><dpe2><dpe1><opsysExtension>

This proposal conflicts with the existing usage, where multiple extensions mean the program has been processed by multipe filter programs. For example 

  mydir.tar.gz
means the file is a tar archive compressed by gzip, not that it is applicable to either tar or gzip.

It is not a conflict as I see it, more a confirmation that such extensioning can be enabled: I work in WindowsXP however and my archives are of the .zip type. But my WinZip? program knows about other types and and handles them without gzip. I do not have Linux, Unix at the present time.

This is true, though winzip is a special case because it handles both tar and gzip files. When I open a .tar.gz file it prompts: Archive contains one file <filename>.tar Should WinZip? decompress it to a temporary file and open it?" Responding yes opens the "tar" archive, but a "no" response simply extracts the .tar file. Winzip is clearly processing the file types right to left. To prove that it isn't that the ".tar" and ".gz" extensions are equally applicable, rename the file to ".tar" and WinZip? will fail to open it.

Another example would be a file 

   mydir.tar.gz.crypt
The expectation would be that you would have to decrypt it, decompress it then unarchive it, in that order, not that the tar, gzip or crypt utilities could all process the file. No, merely that the tar, gz and crypt processes are applicable to the file.

Under my vision of a DottedPrefixExtension?, a rendering of the name allows that the system extension would be following the last dot, if a processing order exists, it might be indicated as: 

 myfile1.processOrder.crypt.tar.gz

This seems like an incredibly weak mechanism to me. Names being used to indicate the type of a thing is a wart that we've carried over from the bad old days of DOS's 8.3 naming scheme. [No, it goes back to Unix and perhaps earlier.] [that doesn't make it not bad old days...] Why should I need to rename something in order to use it? An alternate system:

An alternate system is just what I propose, you need not rename any files or use extensions or DottedPrefixExtensions, since I do not advocate Operating System changes to accomplish this mechanism. I named and saved this file IdontLikeShortNamesTheyLimitMe?.ok.Iagree.HowaboutExtensions?.txt When I double-click on the file in the file manager it ignores everything but the .txt for execution purposes and brings up Textpad (My present default program for .txt files. And under windows this naming convention is not a problem it can be a 30.2.6.18.3 Naming scheme if you want it. That provides a lot of user options, not just what the OperatingSystem gurus give you. What I am hinting at is that intelligence can be built into both data and executables including but not limited to a file name. That is what is meant by DataRecognitionSoftware. (It doesn't exist or isn't applied to a great extent, but it is now in progress!) Related to this is the work are efforts in IntentionalProgramming and HyperArtifactProcessing.

Identify a single type for a file (the most specific type) using a 'pluggable' FileTypingSystem. (e.g., Apache uses the ChainOfResponsibility pattern to allow you to use file names, file magic, or any other scheme you can think of).

Each type can 'inherit' actions from a list of explicitly named other types. (like multiple inheritance, but only one level). So, for example, an 'Ant build file' is-a xml file and 'is-a' text file, and you may inherit multiple alternate 'edit' actions from each of these types.

Each action is associated with a list of types and a single program. Both associations can be navigated so that, e.g. I can ask 'what actions can emacs perform?'. 'What programs offer the 'edit' action for text files?'

This last bit is crucial. I think windows is deficient in not having the actions as first class entries in the registry - it 'forgets' how to open a file with emacs if you change its association to open with vim. It means that every time I try to set up the 'open' action on a file I see every possible program instead of just those programs which are registered as offering the 'open' action on that file type.

(not meaning this to start a windows flamewar. I would like so see something like this in unix too - it would be pleasant to be able to type 'print xxx' and have the print command figure out what program to execute to perform that action.) -- BrianEwins

Actually, the standard setup of most Linux distributions does pretty much what you describe: lpr xxx will use "file" magic to find out what xxx is and select an appropriate filter. The filters are user configurable; typically filters for printing plain text, Postscript, DVI and some bitmap formats are pre-installed. -- StephanHouben

Yes - but it's not pervasive. Consider a few other commands, like 'edit', 'compile', 'compress'. Emacs switches modes for different file types, fair enough - but that means you have to load emacs to decide whether you want to use emacs to edit a file.... 'compile' is there (as 'make' - which types using file extensions) but it works in terms of a target object type not the source. 'compress' - well unix does have a compress command (or more usually gzip these days). But it doesn't switch based on the type of things it's compressing, e.g. to mp3 encoding for audio, xmill (http://www.research.att.com/sw/tools/xmill/) for xml; which would actually improve compression ratios! Also, again you lose information about what alternatives to the current version of an operation is available (though I am aware that debian's package system does have a lot of that info!) -- BrianEwins

This seems unbearably complex to me. It seems like a file system should simply manage files, and users can determine how they want to operate on the files. Some files really do nicely map to one application for execution purposes, so I see a use for the shebang mechanism. When it comes to editing files, it seems like all the sophistication for recognizing file types should be built into the editor, not the file system. Open the editor once, and then edit files to your heart's content.

If you have files that could potentially be operated on my four or five applications, then I still see no reason to add complexity to the file system. In that case, the user is clearly having to decide what application to run, so simply make them launch the application from the shell.

Perhaps I'm just not getting something here, but can some one give me a concrete example of how simple file paradigms inhibit usability of systems?

See also: YouCanSolveAnyProblemWithAnotherLevelOfIndirection. For example, let's say you have a whole bunch of applications that can operate on XML files, but you want a data-centric feel, where you pick the file to work on first, then you pick what application to use. Write a launching program in Perl, Python, etc. Instead of complex registry mechanisms, the user builds his own intelligence in managing files.

Thanks. -- SteveHowell

The main problem with this proposal is just that it would confuse most users, to solve a problem that bothers hardly any users.

Okay, okay. It bothers me though, every time I click on a file called 'readme' in windows (and get asked again what program I want to use), or every time I install a piece of software which discards the associations I'd set up with other software, and so on. I think the proposal could be made less confusing to users than the current mess (don't confuse mechanism with UI!). I don't lie awake worrying about it though. My comments on this page began as an argument against the insanity of DottedPrefixExtensions, which mix the concerns of name and type, a HungarianNotation for files. I guess if I want something different from a launcher I should take Steve's advice and write it myself; I won't argue the point here again. -- BrianEwins

"it would confuse most users, to solve a problem that bothers hardly any users" -- Since it would not be a systems device, but a user defined/chosen device, Users would need not utilize/confuse themselves with it. [Hardly any users] could define/choose to utilize/not be confused with it.

It also answers the need to be able to find where you put something, which is a problem with which many struggle today, not least of which is BillGates and therefore his organization.

I HaveThisPattern with XML documents (sometimes). The thing about XML is that every document has a specific type based on its DTD (e.g., it might be XMI, or a deployment descriptor, or SVG, or a word-processor document), but also has the more generic type of 'XML document'. The key thing here is that although I have windows-friendly generic XML tools, I don't have windows-friendly tools for editing more specific file types (well, maybe except SVG); thus, the only useful action that double-clicking could accomplish is opening a generic XML editor. Since I don't want to have to associate millions of file extensions with the XML editor, I give XML files the ending .xml. However, to mark their specific type, I use a DottedPrefixExtension?, leading to filenames like my-diagram.svg.xml.

Of course, the real answer is to have a smarter typing system in the OS: files should have types (which should form a hierarchy), and applications should publish the set of types they can handle. Thus, the contextual menu on a file should display a list of the possible operations. If there were multiple possible applications, then double-clicking a file would pop up a dialogue box asking which to use, and the choice would be recorded and reused in future.

Win2k and {WindowsXp) does all this to a certain extent, via 'Open With' in the contextual menu, but it's not really smart enough. I think MacOs has had some behaviour like this for quite some time.

-- TomAnderson

See FileTypingSystems (FilenameExtension SheBang MimeType?)

Developments and Related

Comments

This proposal is fatally flawed for none of the reasons listed below. Yes, it would conflict with the current usage where .tar.gz means a file has been processed multiple times. However, what really kills the proposal is that it's strictly inferior than a much better design.

I don't think that this page is a "proposal" as such; rather it's a description of current practice.

What the proposer of dotted prefix extensions wants is to specify that one type of object is a subtype of another. Seem familiar to anyone? Yup, we're just reinventing inheritance here. And the right place to put inheritance is in the ObjectBrowser's (or window manager, or web browser's) specification of what handler to call to handle what type of object.

That handles 99% of cases.

At that point, it's clear that complaints about filename extensions being a weak typing mechanism are just those of programmers used to StaticTyping in BondageAndDisciplineLanguages.

The only complication in the scheme is what do you do to alternate between multiple different views of an object. And that's only a problem for advanced user interfaces, it's meaningless in the WimpInterface. For the record, the proper solution is to give the object multiple names. A smart object browser will detect it's the same object and won't display duplicates but merely offer you the option of changing views.

what really kills the proposal is that it's strictly inferior than a much better design

What superior design? What is this design, where is it exposed?

20070425 -- Microsoft DotNet supports what it calls a "MultiDottedExtension?".

What the proposer of dotted prefix extensions wants is to specify that one type of object is a subtype of another

Not so. Each of the several possible prefix extensions are to become definitions or classifiers, not just a form of hierarchy. Hierarchy can be maintained in this scheme, but other ways including the File system of directories and subdirectories can be used for that. Remember we are talking about files as containers, accumulators, aggregators, algorithmic and presentation mechanisms.

External Links Issues and problems in using the above scheme

File Extension lists

Addition and Extension Various Systems handling Security Issues GoogleQuery? (for more)

Since I first posted this some years ago, I have switched to delimiting with the underscore in names to allow additional separation in the naming convention. The term that I might use now is Concept_UnderscoreCharacterAsSeparator_ArtifactNames

See PrefixedWords CompoundWikiWords SuffixedWords, as appearing in a WikiWordExpression? 

 -- DonaldNoyes

CategoryInterface

EditText of this page (last edited April 22, 2011) or FindPage with title or text search