At a first glance it seems to me that it uses DFS instead of BFS, because it doesn't distinguish what is it actually following.
So maybe the strategy could be to follow BFS and use subinstances of Collection as references.

Peter

On Thu, May 26, 2016 at 9:20 PM, Offray Vladimir Luna C��rdenas <offray.luna@mutabit.com> wrote:
Hi,

I didn't find that strategy and finally created a #flatten method before serializing my grafoscopio trees, with just what I wanted. At [1] you can find the last version of the notebook show at this screenshot:



[1] http://mutabit.com/repos.fossil/panama-papers/artifact/cbfe8929edf64212

I know is this doesn't solve in anyway your problem... but may be it could inspire you in some way. I was asking also for a flatter STON and the idea of a method to flatten the tree wrote by myself was not evident at the beginning, but was a very good solution.

Cheers,

Offray


On 26/05/16 13:52, Peter Uhn��k wrote:
Hi,

is it possible to configure STON to generate more flat output?

Imagine a scenario where an element can have children and the children have reference to their parent


���
Now the problem is that the output of STON will depend on the order of the items,
so if I have "nice" ordering for the following, I will get a flat output


���
If however the ordering is different, the output will be more nested


���
As the ordering is not stable, I often end up with results like this (zoomed out)


���
The image above has depth of about fourteen, even though it could be represented with just depth of four.

In the current state I cannot actually look at the generated output because it's impossible to find anything, which is problematic when an error occurs.

So the question is if it is possible to push the actual objects as far up as possible, and use references "@12" only on the deeper levels.

Thanks,
Peter