Clearer definition for m.asset and edge cases.

Author: stefanceriu

proposals/3488-location.md

@@ -42,7 +42,7 @@ would be the client's reponsibility to map them to values a particular library
 uses, if different. The client is also free to completely ignore it and decide
 the zoom level through other means.
 
-```json
+```json5
         "m.location": {
             "uri": "geo:51.5008,0.1247;u=35",
             "description": "Our destination",
@@ -51,7 +51,23 @@ the zoom level through other means.
 ```
 
 In order to differentiate between user tracking and other objects we also
-introduce another subtype called `m.asset` to give the object a type and ID.
+introduce a new subtype called `m.asset` to give the object a type and ID.
+
+`m.asset` defines a generic asset that can be used for location tracking 
+but also in other places like inventories, geofencing, check-ing-checkout etc.
+It should contain a mandatory namespaced `type` key defining what particular 
+asset is being referred to. 
+For the purposes of user location tracking `m.self` should be used in order to
+avoid duplicating the mxid.
+
+If `m.asset` is missing from the location's content the client should render it 
+as `m.self` as that will be the most common use case. 
+Otherwise, if it's not missing but the type is invalid or unkown the client 
+should attempt to render it as a generic location. 
+Clients should be able to distinguish between `m.self` and explicit assets for
+this feature to be correctly implemented as interpreting everything as `m.self`
+is unwanted.
+
 
 If sharing time-sensitive data, one would add another subtype (e.g. a
 hypothetical `m.ts` type) to spell out the exact time that the data in the
@@ -62,7 +78,7 @@ static location, suitable for "drop a pin on a map" style use cases.
 
 Example for sharing a static location:
 
-```json
+```json5
 {
     "type": "m.location",
     "content": {
@@ -71,7 +87,7 @@ Example for sharing a static location:
             "description": "Matthew's whereabouts",
         },
         "m.asset": {
-            "type": "user" // the type of asset being tracked
+            "type": "m.self" // the type of asset being tracked
         },
         "m.ts": 1636829458432,
         "m.text": "Matthew was at geo:51.5008,0.1247;u=35 as of Sat Nov 13 18:50:58 2021"
@@ -89,7 +105,7 @@ in the `m.location` extensible event type from this MSC into the old-style
 relevant data.  If both fields are present, clients that speak MSC3488 should
 favour the contents of the MSC3488 fields over the legacy `geo_uri` field.
 
-```json
+```json5
 {
     "type": "m.room.message",
     "content": {
@@ -101,7 +117,7 @@ favour the contents of the MSC3488 fields over the legacy `geo_uri` field.
             "description": "Matthew's whereabouts",
         },
         "m.asset": {
-            "type": "user" // the type of asset being tracked
+            "type": "m.self" // the type of asset being tracked
         },
         "m.text": "Matthew was at geo:51.5008,0.1247;u=35 as of Sat Nov 13 18:50:58 2021",
         "m.ts": 1636829458432,
@@ -124,7 +140,7 @@ support the concept of uncertainty, and is designed more for sharing map
 annotations than location sharing. It would look something like this if we
 used it:
 
-```json
+```json5
         "m.geo": {
             "type": "Point", 
             "coordinates": [30.0, 10.0]