ID standardization (web-features/Devographics/MDN/CanIUse/etc.)

[SachaG]

As pointed out in https://github.com/web-platform-dx/web-features/issues/1624, the feature IDs used by Devographics can differ a bit from those used by web-features.

It's a bit hard for us to change these IDs because they are used in thousands of database documents… and there's also practical concerns related to formatting (for example I think em dashes are not allowed in GraphQL field names).

So I guess the best thing we can do for now is store the web-feature ID as a separate field?

If we do that I will probably make it so that you can also query our API using the web-feature ID – this way you won't need to know what our internal Devographics ID is in order to pull in our data.

[captainbrosset]

This is very similar to caniuse IDs by the way. They're almost like web-features IDs, but not quite. We have a caniuse field in our YAML feature files to establish the link. We could do the same for Devographics surveys too.

[atopal]

I like the idea Sacha! Even if it's not possible to do this retroactively for all existing features, maybe it's an option to do that moving forward (and find a solution for cases like the em-dash)?

@captainbrosset the caniuse field was early in our work on web-features, but I think it's becoming more and more clear that it's better for places that have the data to use web-features identifiers to tag their data, otherwise we'll end up with a lot of data in web-features that will likely go out of sync over time. The container queries case in #1624 is an example for that.

[SachaG]

I like the idea Sacha! Even if it's not possible to do this retroactively for all existing features, maybe it's an option to do that moving forward (and find a solution for cases like the em-dash)?

The problem is that if we change the ids then we lose the ability to generate historical charts comparing past years. But anyway yeah, first step in any case is to store web-feature ids on our side I think.

[SachaG]

By the way, I'm not sure how relevant this is, but one reason why we often add underscores to our IDs is that our system uses them as placeholders for `,-,_, etc. in order to catch different spellings within freeform answers. So for exampleedit_contextwould generate a regex that would then matchedit context,edit-context,EditContext`, etc.

[ddbeck]

it's better for places that have the data to use web-features identifiers to tag their data

I want to second Kadir on this. It will be difficult for web-features to keep up with all of the various places where web-features might be referred to (and impossible to bring uniformity to all of them), so it'd be better if those places referred back to web-features instead.

Is there something we can do to make that easier? Or is this issue more of a statement of aspiration, to explicitly recommend this approach to web-features consumers?

[atopal]

I've also added this question to the agenda of the next WebDX CG call.

[SachaG]

I don't mind storing the web-features ID personally. But it would be nice if that ID could also somehow give me access to CanIUse and MDN data. For example, if we assumed that the web features ID for CSS Grid was e.g. cssgrid, you could imagine that https://caniuse.com/cssgrid would redirect to https://caniuse.com/css-grid and show you the proper page.