Guy raised a good point that there's a distinction between a 2D slice, and a table.
Tables are ordered and assign dimensions explicitly to rows/columns.
If we support N dimensional slices, then 2D slices would be useful as they generalise the N dimensional slice case.
This makes me think we might want different accept headers; or more likely routes; e.g. /slice /table.
What would a slice view look like? Obviously we could return something like json-stat; but perhaps we should focus on slice summaries? e.g. specifying response keys for things like:locked-dimensions, :free-dimensions, the presence of or number of observations if you walk that way, etc.
Guy raised a good point that there's a distinction between a 2D slice, and a table.
Tables are ordered and assign dimensions explicitly to rows/columns.
If we support N dimensional slices, then 2D slices would be useful as they generalise the N dimensional slice case.
This makes me think we might want different accept headers; or more likely routes; e.g.
/slice/table.What would a slice view look like? Obviously we could return something like json-stat; but perhaps we should focus on slice summaries? e.g. specifying response keys for things like
:locked-dimensions,:free-dimensions, the presence of or number of observations if you walk that way, etc.