I suppose that’s fine, but I think the main issue is that I think these two formats are the ones we’re most likely to adopt as extensions in the future, and it would be good if tools written today could do something reasonable with them even in the future. I think we already know what that reasonable thing to do is, too: consider the field
dynamic and throw it to the backend to parse it (which will fail if it’s not implemented correctly).
I think it’s reasonable to call these out as valid possible future forms as compared (especially the second one) to, say:
dependencies = 3
I’m also on board with getting rid of the first reserved format (table of key/vaue pairs) and just saying that the list can contain tables, but the meaning of such tables are undefined — backends must not use them without a change to the spec, parsers that don’t know what to do with them should mark the field as
dynamic. That would give us the freedom to implement something like this in the future:
dependencies = [
But also the freedom to do stuff like this:
dependencies = [
I don’t really want either of these things, but allowing for the possibility would make the thing more extensible without breaking the entire ecosystem. The “exploded table” format does have the advantage that it’s easy to add additional keys in future specs in such a way that wouldn’t require updates to all existing parsers. If we reserve this format in the original spec and specify that parsers should fall back to “dynamic” in the event that they encounter this format that they don’t understand, we’ll also have that extensibility benefit.
Another possibility would be to add explicit versioning to the spec from the outset, and say that parsers should fall back to
dynamic if this format is encountered and the spec version is higher than the highest version they understand.
I don’t feel terribly strongly about this — I don’t think it adds a huge amount of complexity to the parsing code, but I also understand the YAGNI concerns.