I feel like the string representation of the dshape is the best serialization format. Maybe what we need is a javascript implementation of the datashape parser.
That would be one direction to go in here; when I floated it with our Client-side JS team, there was resistance to having to develop and maintain another parser.
Since datashape objects are intrinsically nested, my desire would be to serialize datashapes in a way that's consistent with that nesting, to remove the need to implement multiple datashape parsers and keep them in sync, etc. The string form of datashapes are great for human consumption, but they're intrinsically flat, and we run into issues with conflating representation with serialization.
My vote is for a serialization format that encodes the nesting, so that we can do datashape parsing in one and only one place. The DataShape.__str__ implementation can handle the human-readable part of the problem.
Quoting from blaze/blaze#1361:
That would be one direction to go in here; when I floated it with our Client-side JS team, there was resistance to having to develop and maintain another parser.
Since datashape objects are intrinsically nested, my desire would be to serialize datashapes in a way that's consistent with that nesting, to remove the need to implement multiple datashape parsers and keep them in sync, etc. The string form of datashapes are great for human consumption, but they're intrinsically flat, and we run into issues with conflating representation with serialization.
My vote is for a serialization format that encodes the nesting, so that we can do datashape parsing in one and only one place. The
DataShape.__str__implementation can handle the human-readable part of the problem.@llllllllll thoughts?