Thanks @ustulation for the information.
I am clearly missing some information here: for the information the API is provided does end up with one specific (XOR)-Resource-Location in the network, correct? So, how is the information present (App-ID, resource-id, DataIdentifier etc) combined to create that location?
My (maybe wrong) assumption was that without app-sandboxing, two apps referring to the same resource ID (in the example named userProfile) would try to read and write the same exact resource in the network. I wasn’t too concerned with those failing to read (or write) but more with the problem that they pollute each others GLOBAL space and thus creating unexpected side-effects upon one another (even only be overwriting the others apps content). Similarly like any variable not prefixed with the var attribute in javascript pollutes the global namespace of all other functions – and thus creating terrible side-effects on one another. Something I’d really try to avoid.
You added DataIdentifier into that group of things now – something that at least on the LOW LEVEL API with the launcher, I have not provided (and no idea how I would to). Either way, if those act as globals, I’d find it rather problematic to just define general terms there, too. For the same clashing reasons. Is that identifier documentation somewhere I could understand its meaning and how it is used as part of the XOR location? It follow along the lines of why apple’s appstore and googles play store insinst on having app-ids in at .-notation with at least three entities (in all lowercase): otherwise Who gets to claim to be the global “email”-app?