How about,
1, A component belongs to one and only one sub system.
E.g, a render component does belong to render sub system.
...
If "belonging" means that the mentioned sub-system is responsible for the kind of component, e.g. its update process, then okay. But particular components need to be used by more than a single sub-system for sure.
...
2, The sub system updates all components.
3, The component itself doesn't know how to update. That's to say, no update logic in it.
Then the component can be data only or not, but it doesn't contain any complex update logic.
Yes, but only if the behavior (and all belonging additional data) is at least stored as data inside components and interpreted by a sub-system. I'm thinking of the sub-system SpatialServices which is responsible to manage the placement (essentially a co-ordinate frame, in the end nothing more than the world matrices if you want so), bboxes and the like. Updating the placement is not the same for each and every model. The placement of static geometry isn't updated at all. Parented placements are updated due to updates of the parental frame or changes to the local frame. Notice that the local frame is additional data necessary to run the update process of parented placements. I have a dozen or so types of other update kinds, up to the grabbing of utensils utilizing a Grab frame (i.e. the hand that holds the utensil) and a Grip (i.e. the handle where and how the utensil is hold). These examples should make clear that the supporting data may be very different, and the overall structure is hence not so homogeneous.
This can be managed by differing between data components and behavior components, similar to variables and code. In such a configuration the sub-system is responsible for the update process as a whole, but
may let the behaviors do the actual work. This would mean that behavior components supplement the sub-system's update process by providing a virtual function. It is also possible that the behaviors are just instructions (as a special kind of data) which would be interpreted by the sub-system.
How does a HealthComponent fit into this, or any other non-engine sub system related component? This is where it gets a bit confusing as the sub system approach works nicely when dealing with things like Physics, AI, and Rendering but for basic things like health, ammo, position/transform it seems not so nice.
I avoid having specific components like a HealthComponent if possible. The game mechanic may have an unforeseeable need for various components of such nature. Instead, I try to manage with general components like e.g. NumericStatComponent with a default value and limits and such. Binding such components is done by name. (Until now it is sufficient, but the tests so far weren't complex enough to guarantee that it will work in all cases.)