We were discussing on the call that the way that extensions are defined in the JSON schema (in Entity https://github.com/OGF-GLUE/JSON/blob/master/schema/Entity.json) doesn't exactly match the GLUE 2 spec. We've got them defined as a JSON object (key/value pairs) in Entity. One issue was that there isn't a LocalID in the JSON schema, but there is in the spec. After the call, I thought that one approach to address this is that in the JSON rendering, the LocalID is implicit - it is the same as the key. This makes it straightforward to map to a different rendering (create a LocalID that is the same as the key in the JSON document) and map from a different rendering to JSON (just drop the LocalID). Another issue was that the JSON schema doesn't define a separate Extension object. I think this is fine since it follows the same pattern we used for enumerations - embed them directly into the object definitions where they are used for readability. A final issue we discussed was that the spec specifies that the Value of the Extension is a String. I would like to allow the value to be any simple type (string, number, or boolean), since this fits the JSON style and makes the JSON documents easier to use. To convert a JSON GLUE2 document to a different rendering, it is easy enough to turn a number or boolean into a string and to convert from a different rendering, it is also easy to try to parse the value as a number or boolean before defaulting to string. To me, this is within the bounds of rendering the abstract GLUE 2 spec into a specific representation. Warren