Make it easy to validate data about specs

[dontcallmedom]

The W3C community has built over time a series of tools and APIs that enable to determine a number of MDN-relevant information about specs (including title, editors and TR URLs, statuses, github repos, test suites).

To make it easier to use these tools to verify and update the data currently used in MDN (and currently hosted in kumascript macros https://github.com/mdn/kumascript/blob/master/macros/spec2.ejs & https://github.com/mdn/kumascript/blob/master/macros/SpecName.ejs, it would be much easier if the data was kept separated from the template themselves.

I have provided pull requests to that effect: https://github.com/mdn/data/pull/157 and https://github.com/mdn/kumascript/pull/557

This issue is raised to discuss the goals and approaches as requested.

[jwhitlock]

I agree with the goal.

I think it is a mistake to split the specification names from the rest of the specification data, and is just a side effect of how the KumaScript macro was used. We can fix that with this transition.

Here's how I would do it:

1. Combine the data from spec2.ejs and SpecName.ejs into SpecData.json, inside the KumaScript repo. This would be similar to how ListGroups loads GroupData.json. A utility function should be written to abstract how the data is loaded.
2. Merge and deploy that one PR, updating how KumaScript processes this data.
3. Duplicate SpecData.json to this repo, merge PR, deploy
4. Update the utility function to load from the data package instead of SpecData.json

The benefit to this method is that you don't have to coordinate KumaScript and data releases, but instead deal with a little data duplication between repos while things are shaking out.

[dontcallmedom]

given the update to https://github.com/mdn/kumascript/pull/557 maybe we're better off closing this pull request for now?

[Rumyra]

Spring cleaning this repo & am closing due to age and archiving of kumascript.