Hannu Krosing wrote:
> Reflecting over the dual possible interpretation of what it does mean to
> convert between "text" and "json" data types it has dawned to me that
> the confusion may come mainly from wanting json to be two things at once:
>
> 1. - a serialisation of of a subset of javascript objects to a string.
>
> 2. - a dynamic type represented by the above serialisation.
>
> case 1
> ------
>
> If we stick with interpretation 1. then json datatype is really no more
> than a domain based on "text" type and having a CHECK is_valid_json()
> constraint.
<snip>
> case 2
> ------
>
> My suggestions on using typecasts for convert-to-json were result of
> this interpretation of json-as-dynamic-type.
>
> Having thought more of this I now think that we probably should leave
> JSON alone and develop an separate dynamic type here.
<snip>
I think it would be best to have 2 main JSON-concerning data types:
1. A proper subset of "text" consisting of every value meeting some
is_valid_json() constraint, as a DOMAIN; every value of this type is a "text".
2. A type that is disjoint from "text", that is, no value of this type would
compare as equal to any "text" value. It would be considered a collection type,
similarly to how an array or tuple or relation is, but having arbitrary depth
and that is heterogeneous in the general case.
You could say that #1 is to textual source code what #2 is to a parsed syntax
tree of that code. Or that #1 is to textual XML what #2 is to an XML DOM.
It would be type #2 above that is the primary JSON type, which has all the
special operators for working with JSON, while type #1 would be opaque, just a
character string, and must be cast as type #2 in order to use any special
operators on it. Similarly, all the converting operators between other types
and JSON would be with #2 only, and producing #1 must go through #2.
So call #1 say JSON_source and #2 say JSON_model, or JSON_text and JSON
respectively.
That's how I think it should work.
-- Darren Duncan
