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.