I think the user assumes two programs that access the same scope are guaranteed to share data. If all programs store their data in multiple formats, that assumption is fulfilled, but in the end nobody enforces that clients actually do this. As said, all of this inconsistency can lead to a scope which contains two datasets instead of one, and make the user wonder where the data from app A went when looking at it from app B. Therefore I think it’s much safer to just make different formats/mime-types use different scopes, make no implicit guarantees about interopability at all, and be done with it.
However, I think I have an idea that allows a proper format standardization in the future: Just reserve some generic scope names such as contacts and calendar for future use. If, sometime, some data format turns out to be the best for general usage, we can standardize it later on.
Also because @raucao mentioned transforming existing standards into JSON: jCard and jCal exist, they’re basically just different syntaxes for the same thing.
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 -02 spec.)
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.
I think we’re having two different examples in mind. In the case of documents, the filesystem is usually directly exposed to the user (which creates a lot of different UI problems). However, contact apps usually don’t expose their storage internals to the user, and there are multiple popular formats to represent contacts on disk (most apps use a DB I suppose).
Lack of support for a file format is also differently handled:
A contacts app would ignore the unsupported mimetype. To the user this looks like the contact got lost.
A unsupported file couldn’t be opened. To the user this is rather inconvenient, but the data doesn’t get actually lost.
Because of this, I strongly recommend to avoid the “shotgun approach” to format compatibility and save data as multiple mimetypes, because this means apps have to ignore unsupported files instead of explicitly pointing out potential problems in their UI. Apart from that it makes third-party implementations incredibly hard.
Hmm, I read this again and you didn’t actually address any of my arguments refuting your assertions on the matter. Not sure what more to write, because these points are all addressed in my previous comment.
