Review of ontology.rst Task PackageBuild

I'm abusing a salsa issue here for a discussion and hope this is ok. The origin of this discussion is https://lists.debian.org/YLSBYNUGFd3zoAYX@alf.mars. My goal for this issue would be to form consensus on changes to be performed on the PackageBuild task and on https://git.subdivi.de/?p=~helmut/mdbp.git;a=blob;f=mdbp/build_schema.json such that they become compatible. If you disagree, please tell. Here goes a list of questions:

1. mdbp uses nested objects (e.g. .input.dscuri instead of .source_package_url) to group related fields. Is there a general preference on using or avoiding such nesting? The PackageTask seems to already do nesting in .extra_repositories.
2. When an .extra_repositories entry specifies a key, does the key have to be restricted to that particular .sources_list (e.g. using [signed-by=...]) or can an implementation generally accept that key for all configures repositories as a compatible implementation? At least sbuild and pbuilder would be difficult to convince of the stronger requirement.
3. Why do you make .host_architecture mandatory? If all you want to do is a QA build, maybe you do not care about the architecture and can leave it unspecified? Unless building architecture-independent packages only, one does want to specify it most of the time.
4. .build_component allows for specifying source. In what kind of situation would I want debusine to build a source package for me when I have to give a source package as input?
5. The .build_component part may cause ambiguity with our archive nomenclature. How about reusing the naming from dpkg-buildpackage here?
6. Why are .build_options and .build_profiles represented as strings instead of lists?
7. Is there a reason that the .build_components default is any? Both sbuild and pbuilder default to all any and that seems most natural to me as well.

When you reply, please consider also reviewing my schema linked above and raising your suggestions for changing my schema. At present, it misses out on .build_component value source (see question 4) and on specifying keys for extra repositories (see question 2). I'm mostly convinced already that repository keys are a good thing. I intend to create a debusine branch on mdbp for drafting the schema changes.