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.