Declare advisement level keywords for non-normative content in Conformance

[csarven]

This is a correction class 2 change updating the #conformance section to declare the use of #advisement-levels terms for non-normative content.

This proposal is based on the suggestion in #181 (comment) to better distinguish the terminology used in normative and non-normative content. That is, continue to reserve RFC keywords in uppercase for normative content, and only use advisement level terms in lowercase for non-normative content.

---

Preview | Diff

[pfps]

The point of using UPPER CASE and calling out wording as normative is to distinguish between normative and non-normative wording. This seems to me to be adequate for the purpose.

Adding a paragraph on what is non-normative does not seem to me to be helpful. On the contrary, I view it as diluting the message about normative wording.

Unless there is direction from W3C I think that this change should not be applied.

[csarven]

The addition does not dilute the existing terms for normative content in any way. In fact, the proposal is about clarifying the language used for non-normative content. This approach promotes uniformity and minimizes potential misunderstandings.

Moreover, screen readers do not inherently distinguish between uppercase and lowercase words when reading text aloud. For example, "SHOULD" and "should" are typically read the same way. This raises accessibility concerns, making the distinction between uppercase SHOULD for normative content and lowercase should for non-normative content less straightforward.

It is more effective to encourage the use of distinct terms for normative and non-normative content—both for authors and editors, in terms of how content is articulated, and for readers, in terms of how content is interpreted while minimizing oversight.

(Sorry, I don't have hard data, surveys, or studies to back this up if necessary, but I see it as an obvious point. Additionally, as mentioned in the comment, some of these terms are already used in existing reports.)

[hartig]

Just two typos to be fixed.

Other than that, I don't see any harm in adding this paragraph. (The real task will then be do go over the doc and replace the non-normative uses of words like "may", "must", etc.

[pfps]

The wording about normative wording is formulaic. Any changes can blunt the message. If the wording is changed here is should be changed in all of the WG's documents. If it is changed in all this WG's documents then it should be changed in all W3C documents.

As I said above, I am against this change unless there is a directive from W3C or the standards body that is referenced.

[afs]

Other than that, I don't see any harm in adding this paragraph. (The real task will then be do go over the doc and replace the non-normative uses of words like "may", "must", etc.

Yes, the impact needs to be assessed, noting that sometimes "should" may be the right wording. Revising existing text is not trivial - the words as they are currently are the agreement. It is different to writing new material.

The suggested words are sometimes opinionated in ways that current text isn't. "could not” reads as implying a logical impossibility.

Presumably, the next request will be to do this across all RDF documents.

[csarven]

Peter, I'm not quite following your argument. Can you point to specific lines or directly quote the proposed addition that conflicts with anything?

Again, this proposal does not modify normative wording - it only clarifies the language for non-normative content. Since the normative language remains unchanged, the argument about requiring a broader W3C directive doesn't apply. As far as I know, there's no directive mandating a uniform Conformance section across all W3C reports. There's no need to update all W3C documents simultaneously. What matters is that each specification's Conformance section is meaningful, useful, and internally consistent. This proposal aims to improve that, specifically for non-normative content.

You're also overlooking the accessibility issue, which is a concrete concern. Writing "SHOULD" and "should" in different cases is not a good practice no matter how you slice it. If anything, even the existence of RFC 8174 argues for making that distinction.

---

Olaf, Andy, re going through the rest of this document as well as the other RDF documents to ensure consistency, I fully agree (I forgot to suggest that in my initial comment but glad it is caught and can be followed up).

[afs]

We have significant resource constraints.

re going through the rest of this document as well as the other RDF documents to ensure consistency, I fully agree (I forgot to suggest that in my initial comment but glad it is caught and can be followed up).

I can not support this PR until there is a roadmap of the work.

[pfps]

Peter, I'm not quite following your argument. Can you point to specific lines or directly quote the proposed addition that conflicts with anything?

Again, this proposal does not modify normative wording - it only clarifies the language for non-normative content. Since the normative language remains unchanged, the argument about requiring a broader W3C directive doesn't apply. As far as I know, there's no directive mandating a uniform Conformance section across all W3C reports. There's no need to update all W3C documents simultaneously. What matters is that each specification's Conformance section is meaningful, useful, and internally consistent. This proposal aims to improve that, specifically for non-normative content.

You're also overlooking the accessibility issue, which is a concrete concern. Writing "SHOULD" and "should" in different cases is not a good practice no matter how you slice it. If anything, even the existence of RFC 8174 argues for making that distinction.

Whether SHOULD vs should is a good way of signalling normative content is a separate matter. You should take that up with W3C and IETF.

But anything adjacent to the referencing of BCP 14 on the same subject has the possibility (and often the probability) of diluting the message. The wording from BCP 14 on when the meaning from it is to be read into a phrase is very explicit and does not need clarification.

[csarven]

This PR doesn't modify BCP 14 or its applicability. It is entirely separate. RFC 8174 clarifies that lowercase terms are not for normative content and leaves them for normal English usage. This PR focuses on clarifying non-normative language and doesn't restrict the use of lowercase terms. Rejecting it just because it deals with conformance language overlooks the proposed improvement without showing any real issue.

If there is anything further I can clarify, happy to do so. Am content to leave it up to the group to evaluate it and go from there. If there is rough consensus to (eventually) introduce this into the document along with further clarifications on the non-normative content, I can follow up on that.

[w3cbot]

This was discussed during the #rdf-star meeting on 17 April 2025.

View the transcript

PR w3c/rdf-concepts#182

<gb> Pull Request 182 Declare advisement level keywords for non-normative content in Conformance (by csarven) [spec:editorial]

ktk: 182 should be closed? because we(?) decided not to include that wording?

AndyS: conceptually, this idea is fine, but in practice, doing exactly what's there would be a huge effort across all the documents, especially where wording was inherited from long-previous WGs

<niklasl> +1 to AndyS

TallTed: do we have a tag for future-work?
… wont-fix seems like closing a door.

pfps: I think we should NOT make this change because of potential to miss some instances, leading to some middle ground problem

niklasl: seems to be about accessibility concerns

<pfps> I also think that we should close this with no action because it is really asking for a change in how BCP 14 is signalled in W3C documents.

ora: maybe we leave this to be after REC, if someone feels strongly at that point

enrico: Semantics TF has little to do at this point, so that meeting timeslot is available for some other TF -- EXISTS, ad-hoc, or otherwise

---

[csarven]

I find this part of the meeting quite baffling:

It is really asking for a change in how BCP 14 is signalled in W3C documents.

This is despite having asked multiple times in this PR for a direct quote, either from the proposed text or from this conversation, that actually supports this claim. Yet I still haven't seen a single shred of evidence.

I do appreciate that some of you have acknowledged the suggestion as useful, with some understandable concerns about its practical implications. That's quite fair but I would ask than what constitutes a legitimate, or any, change from earlier work?

That said, I'd just like to clarify that the suggestion here was specifically and only for rdf-concepts, not to all of this group's documents. If the group later chooses to adopt it in other documents as well, that's great, and that bridge could be crossed later.

Finally, as I've mentioned in the referenced issue, FWIW, https://infra.spec.whatwg.org/ is one of the specifications that uses the terminology that's proposed in this PR, and it is also the same specifications that's referenced from rdf-concepts - so it is not a completely random or strange thing that's out there using these terms, and I'd presume that the contributors to INFRA have also thought this through, i.e., the interplay between normative (BCP 14) and non-normative content!

... okie dokie.

[pfps]

I find this part of the meeting quite baffling:

It is really asking for a change in how BCP 14 is signalled in W3C documents.

This is despite having asked multiple times in this PR for a direct quote, either from the proposed text or from this conversation, that actually supports this claim. Yet I still haven't seen a single shred of evidence.

You are asking for a change in the section of the document that describes how the keywords in BCP 14 are to interpreted. This is precisely a change in how BCP 14 is to be signalled in this W3C document.

I do appreciate that some of you have acknowledged the suggestion as useful, with some understandable concerns about its practical implications. That's quite fair but I would ask than what constitutes a legitimate, or any, change from earlier work?

That said, I'd just like to clarify that the suggestion here was specifically and only for rdf-concepts, not to all of this group's documents. If the group later chooses to adopt it in other documents as well, that's great, and that bridge could be crossed later.

If this document has different wording concerning BCP 14 then it would be different from the other WG documents, which is not something that should be done. So in effect you are asking for a change in all the WG documents. But then the WG documents would be different from other W3C documents, which is not something that should be done.

Finally, as I've mentioned in the referenced issue, FWIW, https://infra.spec.whatwg.org/ is one of the specifications that uses the terminology that's proposed in this PR, and it is also the same specifications that's referenced from rdf-concepts - so it is not a completely random or strange thing that's out there using these terms, and I'd presume that the contributors to INFRA have also thought this through, i.e., the interplay between normative (BCP 14) and non-normative content!

That spec says "This is a willful violation of RFC 8174, motivated by legibility and a desire to preserve long-standing practice in many non-IETF-published pre-RFC 8174 documents. [RFC8174]". I see this as a bad thing.

Now it may be that BCP 14 or how to use BCP 14 should be updated because the use of case is a bad idea. Feel free to make this argument to IETF or W3C.

[csarven]

Can you please explain what of the proposed text:

The key words “strongly encouraged”, “strongly discouraged”, “encouraged”, “discouraged”, “can”, “cannot”, “could”, “could not”, “might”, and “might not” are used for non-normative content.

have anything to do with the current text in the Conformance section:

The key words MAY, MUST, MUST NOT, RECOMMENDED, SHOULD, and SHOULD NOT in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Are any of the terms in proposed text also in the current text, and if so, which ones?

What is your interpretation of the proposed text that makes you conclude that it changes the interpretation of the current text?

The current text is for normative content and the latter is for non-normative content, and they use different key words. There is nothing in common.

[pfps]

Can you please explain what of the proposed text:

The key words “strongly encouraged”, “strongly discouraged”, “encouraged”, “discouraged”, “can”, “cannot”, “could”, “could not”, “might”, and “might not” are used for non-normative content.

have anything to do with the current text in the Conformance section:

The key words MAY, MUST, MUST NOT, RECOMMENDED, SHOULD, and SHOULD NOT in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

The text in the current document says that upper case keywords are to be interpreted as in BCP 14, implicitly saying that all other ways of including these keywords do not. The added text explicitly calls out some of these other ways as not being BCP 14. This turns an easy two-way decision into a much harder three-way decision. So the two statements are indeed related.

[csarven]

The claim of introducing a "three-way decision" is based on a misunderstanding.

RFC 8174:

When these words are not capitalized, they have their normal
English meanings and are not affected by this document.

The proposal doesn't restrict non-normative language but brings clarity and consistency.