Ability to check for inconsistent use of capitalization

[ajeanmahoney]

Just like #24, but the report captures inconsistent capitalization of terms within the text. For example:

6TiSCH-Aware (1)
6TiSCH-aware (17)
6top protocol (6)
6top Protocol (2)
Address Lookup (3)
address lookup (12)
Architecture (29)
architecture (22)
Backbone (4)
backbone (15)
backbone router (1)
Backbone router (2)
Backbone Router (27) 
ChannelOffset (1)
channelOffset (24)
Deterministic (3)
deterministic (12)
Distributed Routing (1) 
distributed routing (6)

Note that the RPC uses title case for section titles, so if a term is only capitalized in a heading, this would not be considered inconsistent and does not need to be highlighted.

[NGPixel]

Processing all words, then all two-words sequences would be quite intensive. Can, for example, backbone and router be handled as 2 different terms only? or do you expect backbone router to also be checked (this would lead to many duplicate results)?

It is safe to ignore terms shorter than 4 characters?

[rjsparks]

do you need to check more than two adjacent words?

[ajeanmahoney]

It is safe to ignore terms shorter than 4 characters?

For the most part. I would like "NUL" vs "Nul" or "null", and "ID", "Id", and "id" to be flagged. Three letters and shorter with interesting capitalization tend to be abbreviations.

Can, for example, backbone and router be handled as 2 different terms only?

do you need to check more than two adjacent words?

Field names and response codes can have more than two capitalized words (e.g., Destination Connection ID Length field, Proxy Authentication Required). It would be helpful if the variations like the following were flagged:

• Destination Connection ID Length field
• Destination Connection Id Length field
• Destination Connection ID length field

[rjsparks]

This is an interesting probem, and is probably solvable, but it's not currently solved in any code we have.
Not creating false positives at the end of sentences will be a corner to address: in the router backbone. Router backbones have
What about plural vs not plural forms?
I would scope this as a big ask - doable, I think still, but not a minor feature.

[ajeanmahoney]

I don't know if it would help to stop searching once an all-lowercase word is found. The example above would then be

• Destination Connection ID
• Destination Connection ID Length
• Destination Connection Id Length

What about plural vs not plural forms?

That doesn't matter.

Checking terms for caps consistency is something we do manually now. For example, if I see both "Id" and "ID" used, I use case-sensitive search (on singular constructions, which also finds plurals) to get counts and see how the terms are used. If there are a lot of "ID"s but only a couple of "Id"s, then I'll check if I can update those "Id"s to "ID". If the use is mixed (e.g., 22 "ID"s, 24 "Id"s), then I'll ask authors for guidance.

[rjsparks]

I think there is something to discuss on plurals that does matter.

If the entire document is Backbone routers are great. Let's talk about my backbone router. What should the report contain? Is it different if the document is Backbone routers are great. Let's talk about my backbone Router.?

[NGPixel]

An option would be to have a set list of common words to check for? rather than processing every possible word / term sequence in the document.

[ajeanmahoney]

What should the report contain?

It would be great to have this:

• Backbone router (1)
• backbone router (3)
• backbone Router (1)

It would still be helpful to have this

• Backbone (1) / backbone (4)
• Router (1) / router (4)

An option would be to have a set list of common words to check for?

RFC terminology is incredibly diverse, and there are WG 'dialects' where one working group may develop a capitalization style that may not be used in another working group. The RPC strives for consistency within a doc and within clusters, but it can be difficult to make documents consistent across time and areas.

We have working style sheets for documents that we edit, but we don't currently capture the final decisions, just the questions. So we don't have great data for building a checklist.

It would be awesome if we could save final style sheets and use them as checklists in the future. For instance, while editing a document that normatively references RFC NNNN, you could load the rfcNNNN style sheet (and the style sheets of all the RFCs that your doc normatively references) and check your document's capitalization against those.

[rjsparks]

It would be great to have this:

I think you answered what you would want if a document contained both of the example sentences I gave, but I don't understand the output numbers.

[ajeanmahoney]

I made up the counts in my example above.