Perhaps one of the most requested features for developers building applications with Haystack data is full support for nested collections. There are essentially three collection types in Haystack:
Lists: linear sequence of values
Dict: tag/value pairs, essentially a JSON map but we restrict names
Grids: the core collection type which is essentially a list of dicts
We've supported nested grids in our Haystack implementation for several years now and it has worked out well. I don't personally think that using heavily nested collections is ideal for key public APIs such as the standardized Haystack ops. But for transferring complicated data to a user interface it can be extremely useful. Perhaps the canonical use for nested collections is a list of Ref values. Today this requires encoding the list of refs into a string with some separator such as a comma. With proper nested listed we can represent this as:
foo:"@id-a,@id-b,@id-c" // today must encode to string
foo:[@id-a, @id-b, @id-c] // with proposed nested list type
To fully support nested collection types only requires enhancing the serialize syntax to handle each of these cases:
Zinc
Informally the following tokens are used to indicate collections:
Lists: [item item item]
Dicts: {tag:value markerTag tag:value}
Grid: <<ver:"3.0" ... >>
The following are proposed changes to the BNF grammar, where we replace scalar with val:
JSON already provides built-in support for lists and maps which equate nicely to Haystack lists and dicts. The only tricky issue is how to handle nested grids. In that case, we say that any JSON map which contains the keys "meta", "cols", and "rows" must conform to a Grid.
Brian Frank Mon 11 Jan 2016
This is one component of Data Model 3.0 proposal.
Perhaps one of the most requested features for developers building applications with Haystack data is full support for nested collections. There are essentially three collection types in Haystack:
We've supported nested grids in our Haystack implementation for several years now and it has worked out well. I don't personally think that using heavily nested collections is ideal for key public APIs such as the standardized Haystack ops. But for transferring complicated data to a user interface it can be extremely useful. Perhaps the canonical use for nested collections is a list of Ref values. Today this requires encoding the list of refs into a string with some separator such as a comma. With proper nested listed we can represent this as:
To fully support nested collection types only requires enhancing the serialize syntax to handle each of these cases:
Zinc
Informally the following tokens are used to indicate collections:
[item item item]{tag:value markerTag tag:value}<<ver:"3.0" ... >>The following are proposed changes to the BNF grammar, where we replace scalar with val:
And enhance value to contain collection types
<val> := <scalar> | <list> | <dict> | <grid> <list> := "[" (val)* "]" <dict> := "{" <meta> "}" <grid> := "<<" <grid> ">>"Example:
ver:"3.0" name, value "list", ["a" 45 2016-01-13] "dict", {dis:"bob" age:40} "grid",<<ver:"3.0" colA,colB "a-0","b-0" "a-1","b-1">>JSON
JSON already provides built-in support for lists and maps which equate nicely to Haystack lists and dicts. The only tricky issue is how to handle nested grids. In that case, we say that any JSON map which contains the keys "meta", "cols", and "rows" must conform to a Grid.
Example using data from Zinc example above
{ "meta": {"ver":"3.0"}, "cols":[ {"name":"name"}, {"name":"value"} ], "rows":[ {"name":"list", "value":["a", 45, "d:2016-01-13"]}, {"name":"dict","value":{"dis":"bob" "age":40}}, {"name":"grid", "value": { "meta": {"ver":"3.0"}, "cols":[ {"name":"a"}, {"name":"b"} ], "rows":[ {"a":"a-0", "b":"b-0"}, {"a":"a-1", "b":"b-1"}, ] } } }Jason Briggs Mon 11 Jan 2016
+1 here, I like it