For the first one, about email, I have a few comments: - For newsletters and forum/blog posts), I think NNTP can help. - For invoices, a multipart message mig

For the first one, about email, I have a few comments: - For newsletters and forum/blog posts), I think NNTP can help. - For invoices, a multipart message might help. This might also be used for having some format for delivery info, and for purchases. - For replies to customer service tickets, you could use a part of the message ID. For "Elements Represent Themselves", note that different users may use a different desktop environment and some none at all (I do not use a desktop environment on my computer). X selections could be used. For example, if the user clicks on a filename in another program, it could take the FILE_MANAGEMENT selection; if a file manager is running, it will notice that it has lost ownership of that selection and can use that to trigger a menu or something. In many cases, even the PRIMARY selection is good enough; the user selects the text and then enters some global key command which causes it to execute another program to do something with the selected text, whether it is converting a unit of measurement, ping a IP address, etc. You could also have a similar idea for HTML documents; this is another use of the <widget> element I have described before that I think would be a good idea. For example, you could use <widget> to mark some text as representing a measurement. Since <widget> normally acts like <span>, the text is visible and you can still use document JavaScripts to provide this functionality too (just like any other <span>), although if the user has their own implementation, then it might provide more units to convert to (even if document scripts are disabled). And if neither <widget> nor scripts are implemented, it still works as static text! Standard format for defining keybindings seems like it could work, although some programs may need their own extensions to the format due to various things, but even then, many common commands will be able to be copied without a problem, so it may still be helpful anyways. I agree about 66 "Wizards and Forms Request Data". Furthermore, it should be possible to write the file locally and send it using a command-line interface, or even automatically convert data entered together with an uploaded file, for this purpose. (A scriptable interface makes this possible to do.) For "Right Click Outsource", that may be good for a desktop environment; for people such as myself who use command-line interface, in some cases it can work. You could have one command which outsources audio, one which outsources directories, etc. (You could also have a FUSE to represent these things and then use a single interface with all of them, including a GUI if you want to.) Mounting email attachments seems a good idea. A program could be made which allows mounting a mbox file in this way. For 90 "Views of Data", SQLite has a virtual table mechanism, and also supports in-memory databases. These features could be used to do some of this stuff (and SQLite includes an extension to access JSON data in this way, actually; the command-line interface also supports importing CSV, too). But sometimes I want to be able to access remote data in this way and (and even make a join query between multiple remote data sources, such as movie times and weather, or any other combination that you might want). However, there are some deficiencies in the virtual table mechanism, such as the inability to have indexes on expressions (including nondeterministic expressions, which in the case of virtual tables, is sometimes useful), partial indexes, consuming LIMIT/OFFSET clauses, etc. (If it supports these things, the client could then understand such a thing as "ORDER BY RANDOM() LIMIT 1" and have it automatically convert into the request to access a random record.)