Conformance section necessity

[danielpeintner]

@ashimura mentioned in the scripting call that a "Conformance" section is not strictly necessary for group notes.
Note: a W3C note is informative.

Opinions?

[danielpeintner]

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

• WoT Consumer
• WoT Producer
• WoT Discovery

[zolkis]

Yes, I agree we should keep it.

[danielpeintner]

Scripting Call 2021-11-29
@ashimura will check with PLH

[danielpeintner]

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

[zolkis]

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

• a Note has a big switch for NOT being normative
• within that context, the spec MAY use normative language, meaning that IF someone chose to implement it (i.e. moves the big switch), then the implementation has to play by the specified conformance classes and algorithms.

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.

[ashimura]

I'v got clarification from @plehegar and the conclusion was:

• As I also mentioned, the latest W3C Process defines the Registry Track and the Note Track.
• Notes define the method for registries (like the DID Registry) should use the Registry Track and Notes specifying implementable technology should use the Note Track.
• Please note that (1) a Note is not endorsed by W3C and (2) it's not under the W3C Patent Policy.
• So we should not request the "W3C Statement" status for Notes, per the following note within the Process document.
  • A Note specifying implementable technology should not be elevated to W3C Statement status; if it does, the request to publish as a Statement must include rationale for why it should be elevated, and why it is not on the Recommendation track.

[zolkis]

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?

1. To guide our thought process during the spec development and for concise English descriptions in line with other specs.
2. For the eventuality the spec gets back to REC track, we'd not have to rethink/reformulate almost all the spec with that in mind.

[zolkis]

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
We can think about that and discuss in the main call, eventually.

[danielpeintner]

Scripting API 2022-01-31

1. all should read the note track and agree

• task-force resolution by next week
• formal email to WG, ask for feedback.

2. group resolution in main call

[zolkis]

Another argument is that we have 3 conformance classes (produce, consume, discovery) that would be hard to express in other ways.

[danielpeintner]

see discussion in main call

[danielpeintner]

Note: in the main call we discussed how to proceed best.
The favored proposal seems to be to apply the change to "Note Track" with the next charter update (just one AC review and approval for the entire charter)

If we do a dedicated AC approval in the end we might just be some month earlier.
Hence, I don't think it is worth it.

Anyone having a strong opinion to do the change SOONER ?

[JKRhb]

Hmm, did we already make the transition to a Note Track document? If so, then I suppose we could consider this issue resolved, right?