Revisiting the tree serialization

[chrysn]

So far, we've always worked with CoRAL as a tree-ish CBOR thing. That's very convenient to write on paper, and works reasonably well with CBOR, but it brings with it two tricky points:

• The information model of the full tree is awkward to describe (see also https://cs.stackexchange.com/questions/144008/terminology-for-multiply-visiting-walks-of-directed-graphs)
• The reader needs to keep a (base, context) cursor for every depth level of the CBOR tree, even though no tree popping may ever come back there. These limit the explorable depth, and may not always be necessary (eg. when following a chain of links).

The latter can be optimized out (the consumer sees the number of entries in the array and can discard contexts and base URIs that can never be come back to), but given that optimization was never brought up AFAIR, I don't think it would be widely implemented.

If we, in the information model, forbade that, once a resource is reached that's already in the "stack", no more statements can be made about that resource any more, things might get a lot easier. Example:

[[2, 4711, cri'http://example.com', [
    [2, 4223, cri'http://example.com/page', [
        [2, 0815, cri'http://example.com' / here we *could* right now say more about example.com, /
                                          / but that may not be a good idea, just say it up there /]
    ]]
]]]

The two upsides of doing this would be:

• The structured information model can (probably, gotta take some more time to confirm) just be an ordered list with duplicates of edges.
• We might find out that it's more compact and easier to implement to use such a flat structure also for serialization.

The two downsides are:

• It's a big change and I don't know if the outcome is pretty.
• If there is confusion about the root node's identity ("Have you ever set up a WebDAV server behind a reverse proxy?"), the constraint may be violated. It's not as bad as it sounds -- the basic information content will still be the same, but the structured content will differ subtly. Worst about this aspect is probably that we'd need to keep consumers from screaming "fault" if they find this.