On Aug 19, 2013, at 11:08, Tony Finch <dot@xxxxxxxx> wrote:
> sharing
CBOR and JSON have in common that their data model is based on trees.
A number of other data representation formats generalize this model to (directed, usually connected) graphs.
E.g., as you say YAML has ways to explicitly reference a part of the structure (which previously has to have been assigned a label).
(With other formats such as Python's pickle, I'm not even sure the resulting graph is always connected...)
With the data formats that provide sharing, there almost always is a semantic ambiguity:
Is the sharing just being used for more efficient transport of what semantically is a tree, or is the sharing actually part of the semantics (i.e., the format does express a graph for use by the application)?
An earlier version of what has become CBOR actually had both versions of sharing (it's easy to write them up in the spec, no? :-).
We decided to go back to a plain tree based on implementer feedback*).
We also weren't too happy about the security implications of implementation bugs in this space.
> equality.
The tree model should make it clear that the model of equality is what is called structural comparison in programming languages; reference comparison would be vacuous (always unequal).
Yes, both (tree model, structural comparison) should be said explicitly.
Grüße, Carsten
*) CBOR is extensible, though. If an application really needs (semantic) sharing, it can still use CBOR after defining two tags: def and ref.
def([5, {"foo": "bar"}]) defines a label 5 for the data item given as the second element of the array, which is also included in the graph at the point where it occurs.
ref(5) adds an edge to that data item at the point where it occurs.
(Yes, you could even allow def([5, {"foo": "bar", "cycle": ref(5)}]) -- depending on where in the sequence of decoding the effect of the "def" occurs. No, you don't actually have to include the label in the def — that could be assigned in sequence, and you could use relative references to enable painless nesting. Etc., etc.)
We don't think we can generalize tags like these enough so they belong in the CBOR spec.
There are several ways to do them and an application that needs them, if any, should decide on the details based on its needs.