Addressing Non-W3C use of W3C Respec and Bikeshed Templates

[ChristopherA]

When my organization was working on a did-onion spec, which is long-term intended for submission to the CCG, we used the Respec template.

It was pointed out to me this week that we should not use that template in the spec, as it is only for approved CCG items, and has W3C copyright & contributor license commitments that are improper until accepted.

Unfortunately it turns out you can't edit out those CCG text and details — they are inside that Respec template javascript, not in the spec repo itself. Thus each party using it would have to also fork the Respec repo and modify it separately if you want to change those detail for use in a pre-CCG specification.

Instead, what I did is just comment out the line in the did:onion spec that runs the Respec javascript on the content. Without the javascript, the early did:onion spec now isn't formatted very well, but it has the essential points. Unfortunately the result is unattractive as was commented on in https://github.com/w3c/did-spec-registries/pull/163#pullrequestreview-550191227

This is an example of the larger problem of the misuse of the CCG Respec template — many other did method proposals and other specs use it that shouldn't.

Maybe an answer is that the CCG publishes a fork of the respect template for non-CCG items such that anyone can use that forked javascript before submitting for approval, That fork would not mention W3C, CCG or W3C copyrights, but makes it trivial for someone to, once approved by the CCG, to update the format of the document by just changing the single line of javascript to point the update to the official CCG template.

If we had this, people that improperly use the CCG template can be cajoled into using the non-CCG version first, and in general not to accept any specs into registries that are not officially work items. A similar solution is probably needed for bikeshed, which I personally like better than respect.

I'd tackle this myself but I'm not a Javascript person.

/cc @msporny @kimdhamilton @iherman @OR13

[iherman]

@ChristopherA,

I am not sure it is necessary (and worth) forking the respec toolkit itself. A document using respec includes a specStatus configuration variable, which can be set to other values. If the value is unofficial then the resulting document does not refer to W3C, and is marked with a CCA 4.0 license. I just took the DID Core as an example, this is how it looks like with that value:

https://w3c.github.io/did-core/?specStatus=unofficial

It has that strange watermark in the background, but that can be taken out, I would think, by some CSS statement. A bit of CSS wizzardy can go a long way... :-)

[OR13]

I'd recommend resolving this by making it a work item :)

see https://github.com/w3c-ccg/traceability-vocab/blob/main/docs/index.html#L9

I would in general avoid respec for anything that is not meant to eventually be a work item / standards track.

[msporny]

Unfortunately it turns out you can't edit out those CCG text and details

You can, @iherman explains how in the ReSpec configuration at the top of the document:

   specStatus: "unofficial"

Does this address the issue, @ChristopherA ?

If not, there are other options for non-CG document types:

https://respec.org/docs/#specStatus

and other options for alternate copyright licenses, etc:

https://respec.org/docs/#copyrights-patents

[wyc]

Thanks for the great responses.

@ChristopherA does use of this specStatus flag address your concern? Please let us know if it doesn't, otherwise I will close this in a week.

[ChristopherA]

Due to holidays I’ve not been able to check this yet.

[wyc]

Hi Chris, given Orie's changes in the PR and elapsed time, I will be closing this issue. Please feel free to re-open if you feel that this isn't addressed.