-
Notifications
You must be signed in to change notification settings - Fork 28
Conformance section necessity #354
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Personally I think we should keep the conformance section. We should be able to use the RFC terms like MAY, MUST and SHOULD to make clear "what" is required for a conformant implementation. Moreover, this section also describes the different classes like
|
Yes, I agree we should keep it. |
Scripting Call 2021-11-29 |
FYI: I found other examples that are a "note" and still have a conformance section and normative statements like MUST. see for example https://www.w3.org/TR/did-spec-registries/#conformance |
I think it's worth mentioning that the WoT Scripting API was retracted from the REC track because no browser implementation intents were on the horizon. One can implement the API as a polyfill, using the Fetch API. Also, the main implementation is in Node.js (node-wot). However, the reason to keep the spec in W3C API spec style was to guide such in-browser and other implementations on the API contract. I think there is value in keeping the spec like that. Since there is no immediate threat of the API being implemented in browsers, it is kind of irrelevant whether does it have a Conformance section or not. All concepts in the API spec have to be translated from browser-specific context (e.g. Web IDL + Web Platform conventions and rules) to Node.js specific implementation context. We could have just have a documentation page for node-wot, but the intent with the Scripting API spec was to consider and treat that browser-specific context as well. I think W3C should figure out a way to say that
Note that even though a Note uses normative language, the big switch kills it by default, so from the W3C perspective it is irrelevant whether does it contain a Conformance section or not. But it could contain an editor's note about this convention issue. |
I'v got clarification from @plehegar and the conclusion was:
|
It seems the WoT Scripting API as a Note is free of W3C patent policy, and its content is not normative by default, whatever it contains. That is the "big switch" I was talking about above. However, IMHO it makes sense to keep a Conformance section and normative language in the spec, whether it's a Note or on the REC track. Why to keep the normative language?
|
By the way, it seems that a Note is not the good category for our spec, as a Note is meant for different things, according to the definition: https://www.w3.org/2021/Process-20211102/#note-track |
Scripting API 2022-01-31
|
Another argument is that we have 3 conformance classes (produce, consume, discovery) that would be hard to express in other ways. |
see discussion in main call |
Note: in the main call we discussed how to proceed best. If we do a dedicated AC approval in the end we might just be some month earlier. Anyone having a strong opinion to do the change SOONER ? |
Hmm, did we already make the transition to a Note Track document? If so, then I suppose we could consider this issue resolved, right? |
It seems like the group supports using the normative language, and we are awaiting feedback from AC reps. |
@ashimura mentioned in the scripting call that a "Conformance" section is not strictly necessary for group notes.
Note: a W3C note is informative.
Opinions?
The text was updated successfully, but these errors were encountered: