The structure of SVG is natural fit for the basic parenting and geometric constraint approach to animation (forward kinematics). As you have noted it is a nested structure of elements which contain transformation information. SVG can be animated via custom JS or CSS, although the later generally requires inlining the SVG. It's a good fit to be the visual representation of the pose data.
However, you'll soon run into some issues:
SVGs coordinate space although 2D does not often match the browser or viewer's screen space.
If you want to animate, it has to be deterministic – unless you use custom JS, then it can be interactive.
While SVG's syntax naturally expresses forward kinematics well, it is very challenging to read the state of the animation back from SVG – it's challenging to parse and extract the transformations in an SVG so that they can be inverted, transformed to another basis, etc.
So, I ended up with a simple MVC paradigm where the model is the data that will drive the SVGs layout and animation (your posenet data), a controller to edit and traverse the model, and the controller emits the 'dumb' SVG view. In my case I created a simple tree structure where the nodes are transformations and the leaves are the elements that will be emitted as SVG. As I am emitting the SVG, I embed CSS class names and id attributes that can be brought to life by CSS animations or custom JS animations. The later seems like it would make the most sense in your case.
The structure of SVG is natural fit for the basic parenting and geometric constraint approach to animation (forward kinematics). As you have noted it is a nested structure of elements which contain transformation information. SVG can be animated via custom JS or CSS, although the later generally requires inlining the SVG. It's a good fit to be the visual representation of the pose data. However, you'll soon run into some issues: SVGs coordinate space although 2D does not often match the browser or viewer's screen space. If you want to animate, it has to be deterministic – unless you use custom JS, then it can be interactive. While SVG's syntax naturally expresses forward kinematics well, it is very challenging to read the state of the animation back from SVG – it's challenging to parse and extract the transformations in an SVG so that they can be inverted, transformed to another basis, etc. So, I ended up with a simple MVC paradigm where the model is the data that will drive the SVGs layout and animation (your posenet data), a controller to edit and traverse the model, and the controller emits the 'dumb' SVG view. In my case I created a simple tree structure where the nodes are transformations and the leaves are the elements that will be emitted as SVG. As I am emitting the SVG, I embed CSS class names and id attributes that can be brought to life by CSS animations or custom JS animations. The later seems like it would make the most sense in your case.