Skip to content

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

Open
danielpeintner opened this issue Nov 22, 2021 · 15 comments
Open

Conformance section necessity #354

danielpeintner opened this issue Nov 22, 2021 · 15 comments
Labels
Waiting for feedback Issues and PRs that are awaiting feedback from another group or institution.

Comments

@danielpeintner
Copy link
Contributor

@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
Copy link
Contributor Author

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
Copy link
Contributor

zolkis commented Nov 23, 2021

Yes, I agree we should keep it.

@danielpeintner
Copy link
Contributor Author

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

@danielpeintner
Copy link
Contributor Author

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
Copy link
Contributor

zolkis commented Dec 14, 2021

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
Copy link
Contributor

ashimura commented Jan 24, 2022

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
Copy link
Contributor

zolkis commented Jan 24, 2022

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
Copy link
Contributor

zolkis commented Jan 24, 2022

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
Copy link
Contributor Author

danielpeintner commented Jan 31, 2022

Scripting API 2022-01-31

  1. all should read the note track and agree
  1. group resolution in main call

@zolkis
Copy link
Contributor

zolkis commented Feb 21, 2022

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

@danielpeintner
Copy link
Contributor Author

see discussion in main call

@danielpeintner
Copy link
Contributor Author

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
Copy link
Member

JKRhb commented Dec 11, 2023

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

@danielpeintner
Copy link
Contributor Author

The charter is not very explicit about it. It still speaks about "W3C Note".

@ashimura can you comment...

@zolkis
Copy link
Contributor

zolkis commented Dec 11, 2023

It seems like the group supports using the normative language, and we are awaiting feedback from AC reps.

@JKRhb JKRhb added the Waiting for feedback Issues and PRs that are awaiting feedback from another group or institution. label Dec 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Waiting for feedback Issues and PRs that are awaiting feedback from another group or institution.
Projects
None yet
Development

No branches or pull requests

4 participants