Compute_from and feature scope

[tidoust]

When compute_from is used (>200 features with a compute_from property right now), there no longer seems to be an easy way to understand the scope of the underlying feature for which a "Baseline High" or "Baseline Low" flag is set because:

1. The compute_from property seems set in a coarse way (it's not about listing all BCD keys except a few ones, it's more about selecting one or two keys that are representative of the status of the overall feature).
2. The compute_from info does not appear in the web-features package in any case, all users see is a full list of BCD keys which includes more than the currently supported scope.

For example, looking at fetch:

• The compute_from property is set to api.fetch.
• The list of BCD keys includes api.fetch.init_attributionReporting_parameter, which is defined in a spec under incubation that monkey-patches Fetch and is not supported across browsers. It also includes api.Request.targetAddressSpace, defined in another WICG spec. While that does not change much in this case, the fetch feature that is Baseline High does not (yet) include these keys.

Another Baseline high example is drag and drop:

• The compute_from property is set to api.DataTransfer.
• The list of BCD keys includes api.DataTransferItem.getAsFileSystemHandle, defined in File System Access, a WICG spec not yet supported across browsers.

I can compute the individual status of BCD keys through the compute-baseline package and consider that keys that have a Baseline status lower than that of the feature are out of scope for the current claim. Is that the intented logic?

FWIW, the background for this issue is that I tried to update my exploration of web-features signals for the standardization process. To get meaningful results, I need to associate features with specs... which I can through the spec_url property of the individual BCD keys that compose the feature.

If I take all BCD keys of the feature into account, the code will report a number of false positives, including "Fetch is baseline high and yet part of it is defined in the Attribution Reporting API. That spec should be a standard already!". If I only take the keys in compute_from, well, first I cannot do that because that info does not exist in the web-features package, and then no doubt I would miss a few interesting specs. Ideally, I'd be able to start from something in between: a list of BCD keys that faithfully represent what the feature encompasses.