> [Pete] Yep, that is understood, but what I'm getting at is that for RPC,
>; the current JSON encoding is not really robust enough and extension need
>; to be defined.
I insist JSON is robust enough ... no extension to JSON is needed.
> [Pete] True, but for interoperability, you need more than a statement
> that it is possible. You need to define a single, standard to do this. I
> was hoping that there were efforts on this list to achieve this.
Arrrrright! Conventions are everything 
What you'd like is something like this :
5. Type System
[...]
6. JSON References
In order to be able to encode a wider range of data topologies, especially for
non acyclic structures, JSON-RPC 1.1 WD proposes the following semantics for
specifying a blob-local reference :
"ref_attribute":{"__jsonref__":";path.from.root.to.target"}
Where "__jsonref__" instructs a json post-processor to evaluate the associated
string as the path from the root object (unnamed first brackets) to the
referenced data, and where identifiers between points in that same string can be
properties names or tables indices.
So that the following example represents a cyclic 3 vertices graph.
{
"vertices": {
"A":{
...
},
"B":{
...
},
"C":{
...
}
},
"edges": [
{
"left":{"__jsonref__":"vertices.A";},
"right":{"__jsonref__";:"vertices.B"}
},
{
"left":{"__jsonref__":"vertices.B";},
"right":{"__jsonref__";:"vertices.C"}
},
{
"left":{"__jsonref__":"vertices.C";},
"right":{"__jsonref__";:"vertices.A"}
}
]
}
7. Procedure Call (Request)
[...]
.
yahoogroup