JSON rendering & Extension
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
Warren Smith [mailto:wsmith@tacc.utexas.edu] said:
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.
The LocalID can't be the same as the key because the key doesn't need to be unique, you can have several extensions with the same key, effectively a multivalued attribute. You could however do something like an alpha sort on the key+value and use the ordering number as a LocalID. The LocalID is opaque and should not be referenced by anything, it just needs to be some string which is different for each Extension for a given object, so you can use it as a key to iterate through the objects. If the technology preserves the object ordering the LocalID could just be the sequence number.
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),
If a string happens to be interpretable as a number or Boolean that's fine, and indeed it would be possible to define that in a particular case it should be of that form. It would only be a problem for more complex data types where a conversion to and from a string is unobvious. Stephen -- Scanned by iCritical.
participants (2)
-
stephen.burke＠stfc.ac.uk -
Warren Smith