webref
webref copied to clipboard
w3c
Filter non-browser specs in curated extracts of IDL/CSS data
I think we had meant from that the beginning when we switched to web-specs, but this apparently fell through the cracks.
In particular, this will remove epub-rs.idl, and unblock the curation process which right now hits issues with the newly extracted JSON-LD IDL fragments.
I think we had meant from that the beginning when we switched to web-specs, but this apparently fell through the cracks.
We wanted to exclude them from released packages for sure. The prepare-packages script should already take care of that through: https://github.com/w3c/webref/blob/9530699d2fc38ff27f31c5d64f39e8dbb3a7e275/tools/prepare-packages.js#L60-L64
However, why exclude them from data curation? Why not rather try to fix the CSS/IDL these specs might specify? (For instance, JSON-LD 1.1 Framing should use partial to extend the base interfaces from the JSON-LD API. That seems worth fixing).
It's not so much about excluding them from being curated, but removing them as part of the curation :)
I guess I've been coming from the perspective that curated provide as clean data as what's in the packages, e.g. when using it in https://github.com/mdn/content/pull/11056 (although I'm guessing the expectation here would be instead to filter based on the spec categories rather than assume the data is filtered)
I also see how providing curation for extracts targeting non-browser could be useful - I'm not sure we have demand for it though, and I'm not sure we really want to add additional manual work for things were this is little or no demand.
I read the above as "go fix it yourself" so I went ahead and prepared a PR against the spec and a temporary patch in #715.
JSON-LD specs were added because there was a demand for cross-referencing purpose. Fixing the IDL is also useful to fix definitions extracts. Typically, the xref database currently has two definitions for JsonLd, JsonLdProcessor and JsonLdOptions. Once the spec is fixed, it will have only one.
JSON-LD specs were added because there was a demand for cross-referencing purpose
Right, I'm not objecting at all to have JSON-LD extracts in webref, it just doesn't like a good fit in what I think are the "browser extracts" in webref.
Fixing the IDL is also useful to fix definitions extracts. Typically, the xref database currently has two definitions for JsonLd, JsonLdProcessor and JsonLdOptions. Once the spec is fixed, it will have only one.
I'm all for fixing specs as a side-effect of curation, but I don't feel we need to rely on curation as an impulse to fix specs - strudy is where I would expect spec bugs to be handled and reported (eventually at least :)
I've r+ #715 to unblock our package releases, but it's probably worth discussing some more our expectations and commitments for the curated branch.
I'm all for fixing specs as a side-effect of curation, but I don't feel we need to rely on curation as an impulse to fix specs - strudy is where I would expect spec bugs to be handled and reported (eventually at least :)
The fact that Strudy hasn't made an inch of progress since we split it off Reffy seems a good illustration that we need something that stands in our way to provide the impulse to fix specs in practice ;) I wouldn't want to have to deal with gazillions of unofficial drafts that define clunky IDL but we're talking about specs published as W3C Recommendations here, that seems worth the extra burden even tough the specs are not our core target.
The fact that Strudy hasn't made an inch of progress since we split it off Reffy seems a good illustration that we need something that stands in our way to provide the impulse to fix specs in practice ;)
not disagreeing that fixing webref provides a good impetus, but I don't think that value trumps the cost of shipping unrelated data in curated, or delaying the shipping of packages to fix extracts that bring no or negative value :)
let's maybe take this as a nudge to revive our automation goals in strudy instead?
the code has rotten a bit, and no one else is asking for this, so closing for now; we can revisit if/when there is more demand