I don’t think that’s entirely true from my usage so far. I’d certainly expected that they might do, and surely that apps don’t break due to data from other apps interfering.
One thing to keep in mind is that a scope is not constrained to single data formats. We have multiple schemas in many existing modules right now. Also, if you’d store calendar data in two different scopes and the only difference would be JSON vs. iCal, we’re back to the usability problem of how to explain the scopes to a non-technical user and make them manage format scopes afterwards. As a user, I’d expect any and all calendar data to go in “calendar” or “events” or something (which I hope we can standardize somehow, so it’s translatable and all).
Following this logic, it doesn’t matter much if one calendar stores things in one folder and another one in another, and they use different formats. In fact, wouldn’t it create incentive and competition for and between app developers to make their apps compatible with all of a user’s data? (We actually have this problem in desktop programs today. Sunbird doesn’t use the same data as GNOME/Evolution Data Server, and it’s killing me.)
Furthermore, try to remember the good old times or have a look at your computer’s
~/Documents/ folder right now. Would you expect all documents in there to be
.odt and would you expect a PDF reader to be able to read and/or open
.docx? After all, the idea of remoteStorage is to bring back a personal-cloud version of your hard drive, where both user and app developer have the complete freedom to share as much or as little data as they want between programs. (IIRC it’s also one of the reasons why content types in directory listings were introduced in the
True. The thing is that you can have an arbitrary number of transformations for the same format/vocabulary. Linked Data people e.g. like Turtle a lot. Some approaches go so far as to not dictate formats at all and take/deliver whatever the app wants to store/retrieve, tranforming it on the fly on the server side. Personally I find that to be overkill, though.