Re: In the absence of files...
From the first message, I was having a hard time understanding just what problem this is trying to solve.
Now you have given two use-cases, neither of which seem to warrant such a complicated scheme:
1) " if you uninstall an application you can lose access to data without realising it."
Is that something that happens a lot and is a real killer, so much so it needs this complexity? The file is still there, you can see it is still there; presumably you recall what application you uninstalled and can just re-install it? Or just look the name and type of the file and install anything that claims to be able to read it (if you have no idea what was uninstalled, this may require a bit of searching, or just asking your friendly IT guy) but is it something that occurs ofen)? Indeed, if you are as totally application-oriented as this whole idea suggests, your thoughts would more likely be "Ah, I need this data that I usually access via SuperApp, oh dear, SuperApp is not installed, let's just install it then".
2) an idea that apparently "improves security because it prevents applications from opening data objects willy-nilly"
> An attempt to open secret_db.sql with - say - a hex editor will be impossible because you can't navigate to it.
Security for whom? We already have (unless you are suggesting throwing them away) mechanisms for providing security for the data based on the access rights granted to the User (many such mechanisms, of varying strengths); e.g. if your User does not have read-access to a directory containing secret_db.sql then you can't even see it exists, let alone navigate to it.
If an application is able to prevent data being opened then the only thing you are going to protect is the implementation details of that application's data files! That is adding a lot of complexity to the User's system to add a feature that is doing absolutely nothing for the User.
I'd also add that those two ideas can clash, badly. If you have uninstalled an application that can read a particular file - or never installed one in the first place - then methods to decide what type the file is include running the 'file' command and having a look inside with a hex dump. If the file is prevented from being opened because the correct application is missing and you can't identify the file type (no, file extensions are not always reliable) then - ooops. You really *have* lost access to that data!
> or as now when you try to open the file in your mail client the operating system suggests a compatible application
Once you have made your choice from the list of all the compatible applications that the OS has suggested (your OS only suggests one?), that isn't making the selected application "responsible" for the data; the email client just wants to let you view the data it can't render. In fact, if it is anything like my email client, the attachment as received is still in the email store, all you have is a temp file: if you want to keep that as a separate file, save it somewhere sensible now, as otherwise it'll get cleaned up along with the rest of the temp files at some arbitray time after you've stopped viewing it.
> you open a compatible application and import it
Ugh, I absolutely loathe applications that "import" your data: either they just mean they'll open it for you (in which, just say "open") or are making a note of its location for future reference (in which case, just say "noted") *or* they are moving the file, renaming it, trying to take it over completely and prevent you from ever daring to make use of it in any other program. I keep as far away from that kind of program as I possibly can. For example, having tried it, twice, I'll manage all my ebooks (of which I have many - thanks to Humble Bundle) in a simple dir tree rather than *ever* install Calibre again (unless they stop "importing" and just start "taking note")!
If that "import" behaviour is the sort of thing that you like then I can see why I'm having a hard time with this concept.
> The browser would talk to Inkscape to render the SVG
Doing things like providing a rendering service for SVG to any program that wants it is a reasonable thing to do - and, as you mentioned, there are and have been ways of doing that (OLE being one such attempt). But they are totally divorced from any idea of "being responsible" for the data.
Clearly I am not understanding what this concept is supposed to provide to the User and how it warrants such complexity - and, as far as I can see, such ambiguity over "what application is responsible for the data" and the potential for duplicating data with clones for no good reason. Ah well. If it is a good idea that I'm just not understanding then I'm sure it'll appear somewhere and, seing it in action, the penny will drop.