Few comments on the devfile spec #864

/area api

The problem, as I see it

I'm a developer working on a team that's creating a tooling on top of devfile. I don't consider myself to be an expert at devfile, rather far from it. But I find a few things unusual in the devfile, which I felt like bringing up:

1. A command has id attribute, but a component has a name attribute. Wouldn't naming these consistently make more sense from a user's perspective?
2. AFAIU, deployByDefault should be used to start the component when the tooling is spinning up resources for inner loop mode. To start the same component in outer loop mode, we rely on it being a part of the composite command with group-kind deploy. Isn't that separate ways to segregate the same item between inner and outer loops?
3. Also, why are we using a boolean with "deploy" in its name when it's meant to indicate that such a component should be start in the inner loop? I know it's not a crime to do so, but it's unintuitive, IMO.
4. For autoBuild, my understanding is that a command with that boolean set to true will trigger docker build and then the resulting image is used to start the Deployment in inner loop mode. But to use it in outer loop mode, one must add the same command to composite commands for the command group-kind deploy. So, essentially, we require only one boolean for inner loop mode, and explicitly putting it in composite commands for outer loop mode. I feel there could be more consistent way of doing things for the two modes.
5. For outer loop mode, we only consider things which are marked with group-kind deploy. And everything that's not marked as group-kind deploy is implicitly a part of inner loop. As a result, reusing things in both modes requires additional flags like autoBuild, deployByDefault, etc., right? Is that by design?
6. This one's probably stretching things too far, but why does devfile have separate ways to do things for the two modes it supports, instead of having a straightforward way to do it in both modes? What if there was a need to add support for a third mode in devfile at some point?

Describe the solution you'd like

Simpler and consistent devfile spec. Explicit rather than implicit approach.