Abstract spec refinement -- tracking issue

[bkmartinjr]

Tracking issue for tactical refinement of the abstract spec as we run up to an early pilot implementation.

---

• Version number API: current view is: use semver and have separate version numbers for SOMA API and package implementation.
  The open question: how should the API present the semver -- as a string (get_version->'1.3.2-rc1-test+buildlabel') or as a numeric/label tuple/list (get_version -> [1, 3, 2, ['rc1', 'test'], ['build-label']])
• dense nd array - should the read operator support incremental/chunked reads, or should we remove the batch_size parameter? (the end user can still do their own chunking, as they know the chunk/result size)
• dense nd array - when the user asks for the read operator to return results in the dense format (aka Tensor), what is the shape of the tensor? (eg, TileDB returns a 1D flattened array, always)
• shape and reshape - object shape is currently set at create-time. Some of the objects (eg, SOMA*NdArray) would benefit from a post-create reshape operation. Should we support this, and what are the implications on implementation?

[gspowley]

dense nd array - should the read operator support incremental/chunked reads, or should we remove the batch_size parameter? (the end user can still do their own chunking, as they know the chunk/result size)

We can support batching for dense arrays in the SOMA C++ API. This would remove the burden of batching from the user and provide a more symmetric API for dense and sparse arrays.

[bkmartinjr]

support batching for dense arrays in the SOMA C++ API.

Do you have a suggestion for what the interface would look like? I.e., a suggestion on how to return the coordinates of each chunk? I do think it would be useful