| 01:29 | <MikeSmith> | as an implementor of a conformance-checking tool, my point of view on “must” language for the class of requirements discussed here earlier is that ideally they should be stated a requirement on *documents* (not authors) |
| 01:30 | <MikeSmith> | because a document must conform to the requirements in isolation from the author or system that created it |
| 01:31 | <MikeSmith> | and many to web documents aren’t really created directly but authors anyway, but instead generated in out of CMS or whatever |
| 01:33 | <MikeSmith> | see https://html.spec.whatwg.org/multipage/infrastructure.html#conforming-documents |
| 01:34 | <MikeSmith> | > For readability, some of these conformance requirements are phrased as conformance requirements on authors; such requirements are implicitly requirements on documents |
| 22:43 | <jyasskin> | MikeSmith: I'd missed that HTML specifically describes its conformance classes. That's great. WebIDL does the same: https://heycam.github.io/webidl/#conformance claims that it only 'must's IDL fragments. I bet we've drifted from that over time though, and if we want to keep 'must'ing other specs, we should say that in #conformance. |
| 22:50 | <jyasskin> | Domenic: I don't know of any documents describing how to write specifications. Fundamentally, I think we're in charge of making it up as we go along. |
| 22:50 | <jyasskin> | I think my axiom here is that we need to make sure our requirements for each conformance class are "complete", meaning they cover what happens when other conformance classes fail to live up to their requirements. Then what guidelines for specs make it most likely that we'll remember to do that? |
| 22:55 | <jyasskin> | "Don't must documents" is one of those, since it's much easier to forget to constrain the implementation when you've said that a situation must never happen. But we do break that one and just rely on spec writers to be careful. |
| 22:55 | <jyasskin> | I think that care is then somewhat undermined by having another conformance class (specs) where we *can* forget to handle the "must never happen" cases. https://infra.spec.whatwg.org/#assertions is great for this, since it's an entirely new word for the new kind of situation. |
| 23:26 | <MikeSmith> | jyasskin: yeah, Hixie has the details about conformance classes in the HTML spec from the beginning. It’s just not something we’ve otherwise done a good job of socializing to other spec authors |
| 23:27 | <MikeSmith> | we definitely ought to have better documents describeing how to write specifications |
| 23:27 | <MikeSmith> | a lot of W3C basically don ' |
| 23:27 | <jyasskin> | At the moment, that's Infra. |
| 23:27 | <MikeSmith> | yeah |
| 23:29 | <jyasskin> | I don't know if I'll have time to send a patch for this any time soon. |
| 23:30 | <MikeSmith> | yeah that’t the problem: This never stays up high enough in anybody’s priority stack to get done |
| 23:32 | <MikeSmith> | but maybe I can make a patch for Infra myself |